JP7709750B2 - Management server, learning device, ride-sharing support system, ride-sharing support method, and ride-sharing support program - Google Patents

Description

The present invention relates to a management server, a learning device, a ride-sharing support system, a ride-sharing support method, and a ride-sharing support program.

When elderly people go to the hospital, go shopping, etc., if they are unable to drive themselves, they will have to use trains or buses. However, if the nearest station or bus stop is far from their home, they will have to walk a considerable distance, making it difficult for them to go out alone, especially in the hot sun of summer or snowy winter. They could also use taxis when going out, but taxi fares are more expensive than public transportation, and frequent use of taxis would be a burden on the household budget. There was also the problem that asking family members or neighbors to pick them up or drop them off is troubling, making it difficult to do so frequently. To solve these problems, technology has been disclosed that allows multiple people to share a single vehicle (see Patent Document 1).

JP 2019-175392 A

However, the technology described in the above-mentioned Patent Document 1 involves registering boarding and disembarking locations in advance, and confirming ride-sharing reservations by notifying those who wish to ride-share if there is even a partial overlap in the route used. This technology has the problem that matching with those who wish to ride-share is almost never achieved in areas other than densely populated urban areas. In addition, for users who are not familiar with smartphones, the operation is cumbersome, making it difficult to use the system without stress.

The present invention has been made in consideration of the above, and aims to provide a management server, a learning device, a ride-sharing support system, a synergy support method, and a synergy support program that allow users to easily take advantage of ride-sharing regardless of the number of users.

To solve the above-mentioned problems, the present invention is characterized by receiving a carpooling destination, sending carpooling invitation information including the received destination to a contact associated with a member ID, generating a group of members who will ride together in a vehicle based on the response for each member ID to the carpooling invitation information received from the contact, and storing the group ID that identifies the generated group in association with the member IDs that indicate the members who belong to the group in a group information storage unit.

As described above, the present invention has the effect of making it easy to share rides regardless of the number of users.

FIG. 1 is an explanatory diagram showing the relationship between the ride-sharing support system 10 according to the first embodiment and users. FIG. 1 is a block diagram showing a configuration of a ride-sharing support system 10 according to a first embodiment. 2 is an explanatory diagram showing an example of the data configuration of a member information storage unit 110, a group information storage unit 120, and a selection condition storage unit 130. 13 is a flowchart showing a member registration process executed by the management server 100 and the information terminal device 200. 13 is a flowchart showing a procedure of a ride-sharing solicitation process executed by the management server 100 and the information terminal device 200. FIG. 11 is an explanatory diagram showing an example of the relationship between a member address, a destination, and selection conditions. FIG. 13 is an explanatory diagram showing an example of a ride-sharing invitation notification screen. 13 is a flowchart showing a vehicle dispatch processing procedure executed by the management server 100 and the information terminal device 200. 13 is a flowchart showing a procedure of operation and settlement processing executed by the management server 100, the information terminal device 200, and the operation server 300. FIG. 11 is a block diagram showing a configuration of a ride-sharing support system 20 according to a second embodiment. 10 is an explanatory diagram showing an example of the data configuration of a facility information storage unit 540. FIG. 13 is a flowchart showing a procedure for a ride-pooling request process executed by the management server 500 and the information terminal device 200 of the ride-pooling support system 20. 11 is an explanatory diagram showing an example of a screen displayed on the information terminal device 200 of the recruiter and the applicant. FIG. 13 is an explanatory diagram showing an example of a ride-sharing schedule adjustment request screen displayed on the information terminal device 200 of the recruiter and the applicant. FIG. 13 is a flowchart showing the procedure of a candidate ride-pooling schedule generation process executed by the candidate ride-pooling schedule generation unit 508 of the management server 100. FIG. 13 is an explanatory diagram showing an example of a carpooling schedule adjustment request screen that displays candidate carpooling dates for the second time. FIG. 6 is a block diagram showing the configuration of a learning server 600. 13 is a flowchart showing a learning process procedure executed by the learning server 600.

Below, examples of the present invention will be described with reference to the attached drawings. Note that the following description is an example of an embodiment, and the present invention is not limited to these examples.

Example 1
FIG. 1 is an explanatory diagram showing the relationship between a ride-sharing support system 10 according to the first embodiment and users. As shown in FIG. 1, the ride-sharing support system 10 includes a management server 100 and information terminal devices 200-1 to n (hereinafter, referred to as information terminal devices 200). The management server 100, the information terminal devices 200, the operation server 300, and the settlement server 400 are communicatively connected to each other via a network N, and transmit and receive data to each other. The network N is any communication network such as the Internet, an intranet, a LAN (Local Area Network), a VPN (Virtual Private Network), or a mobile communication network, or a combination thereof, and a part or all of the network may be wired or wireless.

The management server 100 is a server that supports vehicle sharing. The management server 100 transmits and receives information related to ride-sharing with the information terminal device 200. The management server 100 transmits and receives information related to the operation of the vehicle being shared with the operation server 300. The management server 100 transmits and receives information related to payment with the payment server 400.

The information terminal device 200 is a general computer such as a smartphone terminal, tablet terminal, personal computer, or wearable computer operated by a user who will share a ride, or by a supporter who will support the user if the user is unable or unfamiliar with operating the information terminal device 200. FIG. 1 shows a case in which the users H1-1 to n (hereinafter referred to as user H1) who will actually share a ride do not operate the information terminal device 200, but a supporter H2-1 to n (hereinafter referred to as supporter H2) operates the information terminal device 200. The user H1 realizes the ride-sharing by conveying his/her request for a ride-sharing to the supporter H2 by telephone or orally. If the user H1 can operate the information terminal device 200, the user H1 himself/herself may operate the information terminal device 200. Even if the supporter H2 is in a remote location, the user H1 can support the ride-sharing of the user H1 by conveying his/her request for a ride-sharing to the supporter H2 by telephone or the like.

The operation server 300 is a server managed by an operation company that operates the ride-sharing vehicles, receives data transmitted from an information terminal device installed in the vehicle or an information terminal device carried by the vehicle driver (hereinafter referred to as a vehicle terminal device), and transmits the received data to the management server 100. The operation company is, for example, a taxi company.

The payment server 400 is a server on which the payment system runs, and settles the ride-sharing fare sent from the operation server 300 with the operation company. The payment server 400 also settles the usage fee for each user calculated by the management server 100 with the users.

Figure 2 is a block diagram showing the configuration of the ride-sharing support system 10 according to the first embodiment. First, the management server 100 constituting the ride-sharing support system 10 will be described.

The management server 100 includes a transmission/reception unit 101, a member selection unit 102, a group generation unit 103, a reservation confirmation unit 104, a vehicle dispatch arrangement unit 105, an operation management unit 106, a usage fee calculation unit 107, a member information storage unit 110, a group information storage unit 120, and a selection condition storage unit 130.

Figure 3 is an explanatory diagram showing an example of the data configuration of the member information storage unit 110, the group information storage unit 120, and the selection condition storage unit 130. Figure 3 (a) is an explanatory diagram showing an example of the data configuration of the member information storage unit 110. The member information storage unit 110 stores information about users who have registered as members in advance and who will be sharing a vehicle. The member information storage unit 110 stores a member ID, name, address, telephone number, supporter information, contact information, and other information in association with each other.

The member ID is information that uniquely identifies a member. The name stores the member's name, the address stores the member's address, and the phone number stores the member's phone number. The supporter information stores information about the supporter who operates the information terminal device 200 to exchange information about carpooling on behalf of the member. The supporter is, for example, the member's family member or a caregiver. The contact information is the destination (email address, messenger account, etc.) for sending various information from the management server 100, and stores the contact information of the supporter (and/or user). Other information about the member such as gender, age, hobbies, etc. (member attributes) may also be stored.

Figure 3 (b) is an explanatory diagram showing an example of the data configuration of the group information storage unit 120. The group information storage unit 120 stores information about groups, which are groups of members who share a ride. The group information storage unit 120 stores a group ID, a destination, a destination address, a member ID, a trip date and time, and other information in association with each other.

The group ID is information that uniquely identifies a group of members who will share a vehicle. The destination is the location where the members get off, and for example, the facility name such as XXX Clinic or XXX City Hall is stored. The destination address stores the address of the destination. The member ID stores the member IDs who will share a vehicle as one group. The operation date and time is the date and time when the vehicle travels to the destination, the date and time of arrival at the destination, and the date and time of arrival at each member's address. Other information may be stored, such as map information showing the operation route. In areas with a small number of taxis, the operation time is adjusted so that one taxi will make a piston transport every 15 minutes, such as three destinations for the destination "XXX Clinic". In areas with a large number of taxis, it is possible to accommodate multiple vehicles, such as three destinations for the destination "XXX City Hall", so adjustments are made to accept ride-sharing even if the operation date and time are the same.

Figure 3 (c) is an explanatory diagram showing an example of the data configuration of the selection condition storage unit 130. The selection condition storage unit 130 stores the selection conditions when selecting members to notify of ride-sharing information from all members. The selection condition storage unit 130 stores the selection conditions in association with other information. The selection conditions are conditions when selecting notification targets such as "within a radius of * km from the destination" or "within XXX city" as shown in Figure 3 (c), and if no conditions are stored, all members will be the notification targets. The selection conditions may be set for each type of destination or user attributes, or multiple selection conditions may be combined.

The transmission/reception unit 101 transmits and receives data between the information terminal device 200, the operation server 300, and the payment server 400. More specifically, the transmission/reception unit 101 receives information related to member registration, information related to the desired destination for carpooling, responses to carpooling invitation information, and the like transmitted from the information terminal device 200, and transmits the carpooling invitation information, and the like, to the information terminal device 200. The transmission/reception unit 101 receives the operation date and time from the information terminal device 200, and stores the received operation date and time in the group information storage unit 120.

The transmission/reception unit 101 transmits and receives information regarding the operation of the shared vehicle to and from the operation server 300. The transmission/reception unit 101 transmits and receives information regarding the settlement of fares with the operation company and information regarding the settlement of usage fees for each member to and from the settlement server 400.

The member selection unit 102 selects from among the members a member to whom to notify information about a ride-sharing invitation to a destination based on the selection conditions stored in the selection condition storage unit 130.

The group generation unit 103 generates groups, which are combinations of members who will ride together in one vehicle, from among the members who wish to ride together, based on responses to the ride-sharing invitation information sent by the members selected by the member selection unit 102, and stores information about each of the generated groups in the group information storage unit 120.

The reservation confirmation unit 104 checks whether there are any changes to the ride-sharing reservation for each member belonging to the group before the operation date and time. More specifically, the reservation confirmation unit 104 sends ride-sharing confirmation information, such as an email or message confirming the ride-sharing reservation, to each member belonging to the group stored in the group information storage unit 120 a predetermined period before the operation date and time stored in the group information storage unit 120, and receives a response to the ride-sharing confirmation information.

The vehicle dispatch arrangement unit 105 acquires the destination, member ID, operation date and time, etc. for each group stored in the group information storage unit 120, and the name, address, etc. associated with the member ID stored in the member information storage unit 110, and transmits vehicle dispatch arrangement information including the acquired destination, operation date and time, name, address, etc. to the operation server 300.

The operation management unit 106 receives a group ID from the operation server 300, and if the received group ID is stored as a group ID in the group information storage unit 120, it determines that the ride is being shared by a member. If it determines that the ride is being shared by a member, it transmits to the operation server 300 a message indicating that the fare will not be received at the vehicle. If the operation management unit 106 determines that the ride is being shared by a member and receives from the operation server 300 the group ID and fare indicating that the ride is being shared by a member, it determines that the ride is being ended.

The usage fee calculation unit 107 calculates the usage fee for each member based on information about the member stored in the member information storage unit 110, the destination stored in the group information storage unit 120, the member ID belonging to the group, etc.

The information terminal device 200 includes a transmission/reception unit 201 and an operation display unit 202. The transmission/reception unit 201 transmits and receives data between the management server 100 and the payment server 400. The operation display unit 202 accepts operations by an operator and displays the results of the operations and data transmitted from the management server 100 and the payment server 400.

The member registration process executed by the management server 100 and the information terminal device 200 of the ride-sharing support system 10 configured as described above will be described. Figure 4 is a flowchart showing the member registration process steps executed by the management server 100 and the information terminal device 200.

The operation display unit 202 of the information terminal device 200 displays a member information registration screen (step S401). The member information registration screen is displayed, for example, by pointing to a member information registration button on the ride-sharing support site or by selecting a menu from a downloaded application program.

The operation display unit 202 accepts the input of member information from the member information registration screen (step S402). The transmission/reception unit 201 transmits the member information accepted from the member information registration screen to the management server 100 (step S403).

The transmitting/receiving unit 101 of the management server 100 receives the member information transmitted from the information terminal device 200 and stores the received member information in the member information storage unit 110 (step S404). At that time, a member ID is assigned, and the member information is stored in the member information storage unit 110 in association with the assigned member ID.

Next, the ride-sharing request process executed by the management server 100 and the information terminal device 200 of the ride-sharing support system 10 will be described. Figure 5 is a flowchart showing the procedure of the ride-sharing request process executed by the management server 100 and the information terminal device 200.

The operation display unit 202 of the information terminal device 200 displays a ride-sharing request screen (step S501). The ride-sharing request screen is displayed by instructing a ride-sharing request button on the ride-sharing support site or by instructing a menu on an application program.

The operation display unit 202 accepts input of ride-sharing request information from the ride-sharing request screen (step S502). The ride-sharing request information includes at least the destination (and/or destination address). Note that the destination address may be automatically searched for from the input of the destination, and the destination may be automatically searched for from the input of the destination address. The transmission/reception unit 201 transmits the ride-sharing request information to the management server 100 (step S503).

The transmission/reception unit 101 of the management server 100 receives the ride-sharing request information sent from the information terminal device 200, and the member selection unit 102 selects a member to send a ride-sharing invitation notification based on the ride-sharing request information, the selection conditions stored in the selection condition storage unit 130, and the information about the member stored in the member information storage unit 110 (step S504).

Figure 6 is an explanatory diagram showing an example of the relationship between member addresses, destinations, and selection conditions. For example, if the destination of the carpool is "XXX Clinic" and the selection condition is "within a *km radius of the destination," as shown in Figure 6, members 63 (9 people) whose addresses are within an area 62 indicating a *km radius of the "XXX Clinic," which is the destination 61 of the carpool, are determined to be the members to be notified, and members 64 (3 people) whose addresses are outside the area 62 are determined to be notified. The transmitting/receiving unit 101 transmits a ridepool invitation notification to the information terminal device 200, which is the contact point of each of the members to be notified (step S505).

The transmission/reception unit 201 of the information terminal device 200 receives the ride-pooling invitation notification from the management server 100, and the operation display unit 202 displays a ride-pooling invitation notification screen based on the ride-pooling invitation notification (step S506). FIG. 7 is an explanatory diagram showing an example of a ride-pooling invitation notification screen. As shown in FIG. 7, the ride-pooling invitation notification screen 71 displays a "Destination" indicating the destination 72, an "Address" indicating the destination address 73, an "Application Deadline" which is a deadline 74 for responding to the ride-pooling invitation, and also displays "YES" or "NO" which is an answer 75 to whether or not the user wishes to ride-pool. The operation display unit 202 accepts the answer to the ride-pooling invitation notification (step S507). The transmission/reception unit 201 transmits the answer to the ride-pooling invitation notification to the management server 100 (step S508).

The transmitting/receiving unit 101 of the management server 100 receives responses to the ride-pooling invitation notification from the information terminal devices 200. Responses to the ride-pooling invitation notification are received from each of the information terminal devices 200 that are the contact points of the members who sent the ride-pooling invitation notification. The group generating unit 103 generates a group, which is a set of members who will ride-pool in one vehicle, by adding members who replied that they wish to ride-pool ("YES") by the invitation deadline, and the inviter who sent the ride-pooling invitation information if he or she is a member (for example, if a member ID was sent along with the ride-pooling invitation information) (step S509).

There are various methods for generating groups, but as an example, the shortest route from the address of each member wishing to share a ride to the destination address is found, and a pair of members with the longest sum of overlapping distances of the shortest routes is preferentially generated as one group. As another example, the shortest route from the address of a member wishing to share a ride to the address of another person wishing to share a ride is found, and a pair of members with the shortest sum of distances of the shortest routes is preferentially generated as one group. The example shown in Figure 6 shows three groups 65, each consisting of three members, generated by the group generation unit 103.

The transmitting/receiving unit 101 transmits information about the members belonging to the group and a request to adjust the operation date and time to the information terminal device 200, which is the contact point for each member belonging to the group (step S510). In this way, by requesting each member belonging to a group to adjust the operation date and time and having the members adjust it among themselves, it becomes possible to adjust the operation date and time taking into account the circumstances and tolerance of each member.

The transmitting/receiving unit 201 of the information terminal device 200 receives the group ID, information about the members belonging to the group, and the request to adjust the operation date and time, and the operation display unit 202 displays the information about the members belonging to the group and the request to adjust the operation date and time (step S511). The information about the members belonging to the group is, for example, the member's name and phone number, and the member can contact the other members by phone and adjust the operation date and time for the shared ride. Alternatively, the supporter may consult with the member and then contact the supporter of the other member by phone or email to adjust the shared ride operation date and time. The operation display unit 202 accepts the input of the operation date and time, which is the result of the adjustment of the ride-sharing date and time with the members belonging to the group (step S512). The transmitting/receiving unit 201 transmits the group ID and the operation date and time to the management server 100 (step S513). If the operation date and time is the arrival date and time at each member's address, the member ID, group ID, and operation date and time are transmitted.

The transmission/reception unit 101 of the management server 100 receives the operation date and time from the information terminal device 200 and stores the operation date and time in the group information storage unit 120 in association with the group ID (step S514).

In this way, by notifying many members of the carpool destination and inviting people to ride along, any location can be a carpool destination. Members can recruit people to ride along simply by sending the carpool destination, and as many people who want to ride along as possible are recruited and grouped, and then the operation date and time are adjusted, so that carpooling can be used even in areas with low population density or few users. In addition, not only carpoolers, but also people who want to use facilities, etc. can enter their destination on the carpool request screen and invite people to ride along, allowing many members to visit facilities, etc. safely and at low cost.

By grouping members who wish to share a ride, taking into consideration the travel route, members can use transportation efficiently and cheaply. In addition, by notifying members selected based on the selection conditions of a ride-sharing request, members who wish to share a ride can be found efficiently.

Next, the vehicle dispatch process executed by the management server 100 and the information terminal device 200 of the ride-sharing support system 10 will be described. Figure 8 is a flowchart showing the vehicle dispatch process steps executed by the management server 100 and the information terminal device 200.

The reservation confirmation unit 104 of the management server 100 determines whether it is a predetermined period (e.g., three days) before the operation date and time of each group stored in the group information storage unit 120 (step S801). If it is determined that it is not a predetermined period before the operation date and time (step S801: No), the process returns to step S801. If it is determined that it is a predetermined period before the operation date and time (step S801: Yes), the reservation confirmation unit 104 creates ride-sharing confirmation information (step S802). The transmission/reception unit 101 transmits the member ID and the ride-sharing confirmation information to the information terminal device 200, which is the contact point for each member belonging to the group (step S803).

The transmission/reception unit 201 of the information terminal device 200 receives the member ID and the ride-sharing confirmation information, and the operation display unit 202 displays the ride-sharing confirmation information (step S804). The operation display unit 202 accepts input of a response to the ride-sharing confirmation information (step S805). If the contact is a supporter, the supporter will respond after confirming with the member who will actually ride-sharing by phone or other means, and if the contact is a member, the member will respond themselves. The response to the ride-sharing confirmation information may be a simple response such as a YES/NO button, as when soliciting a ride-sharing request. The transmission/reception unit 201 transmits the member ID and the response to the management server 100 (step S806).

The transmission/reception unit 101 of the management server 100 receives the member ID and the answer, and stores the answer associated with the member ID in the group information storage unit 120 (step S807). The reservation confirmation unit 104 judges whether the operation has been confirmed (step S808). More specifically, the reservation confirmation unit 104 judges whether the operation has been confirmed based on whether or not it has received responses from all members belonging to the group that they will board as planned. Note that it is also possible to judge whether the operation has been confirmed based on whether or not it has received responses from a predetermined number of members, not all members belonging to the group, that they will board as planned. If it is judged that the operation has been confirmed (step S808: Yes), the vehicle dispatch unit 105 arranges the dispatch of a vehicle (step S809). More specifically, the vehicle dispatch unit 105 transmits operation information to the operation server 300 to arrange the dispatch of a shared vehicle. If it is judged that the operation has not been confirmed (step S808: No), it transmits a reservation cancellation message to the information terminal device 200 (step S810). In addition to sending a message canceling the reservation, you may also include the user in another group or replace members. You may also encourage new carpoolers.

In this way, before the ride-sharing vehicle actually operates, the ride-sharing information is confirmed with each member, and then the vehicle is dispatched from the operating company, which prevents unnecessary vehicle arrangements and loss of profit. It can also serve as a reminder for members who have booked a ride-sharing. Note that, instead of the above-mentioned process, the vehicle may be dispatched several days before the operation date and time without sending the ride-sharing confirmation information to the members.

The operation and payment processing executed by the management server 100, information terminal device 200, operation server 300, and payment server 400 of the ride-sharing support system 10 will be described. Figure 9 is a flowchart showing the operation and payment processing procedure executed by the management server 100, information terminal device 200, and operation server 300. The operation server 300 transmits and receives data to and from a vehicle terminal device operated by a driver who drives the ride-sharing vehicle, and transmits the transmitted and received data to the management server 100.

The operation server 300 receives the group ID that has been input by the vehicle terminal device from the vehicle terminal device (step S901) and transmits the group ID to the management server 100 (step S902).

The transmission/reception unit 101 of the management server 100 receives the group ID from the operation server 300, and the operation management unit 106 confirms that the group ID received from the operation server 300 is the group ID stored in the group information storage unit 120 (step S903). This determines whether the ride-sharing support system 10 has accepted the ride-sharing request. If the operation management unit 106 confirms that the group ID received from the operation server 300 is the group ID stored in the group information storage unit 120, it transmits to the operation server 300 a message indicating that the fare will not be received from the passenger (step S904), and the operation server 300 transmits a message indicating that the fare will not be received from the passenger to the vehicle terminal device.

The operation server 300 receives the group ID and the fare from the vehicle terminal device (step S905), and the operation server 300 transmits the group ID and the fare received from the vehicle terminal device to the management server 100 (step S906).

The transmitting/receiving unit 101 of the management server 100 receives the group ID and the fare from the operation server 300, and the usage fee calculation unit 107 calculates the usage fee for each member belonging to the group from the received fare (step S907). The usage fee is calculated based on a predetermined formula. For example, the amount may be determined based on the straight-line distance from the destination, such as 500 yen if the straight-line distance from the member's address to the destination is 2 km, 700 yen if the straight-line distance from the member's address to the destination is 3 km, and 900 yen if the straight-line distance from the member's address to the destination is 4 km. The transmitting/receiving unit 101 transmits the usage fee for each member to the information terminal device 200, which is the contact point for each member (step S908).

The information terminal device 200 receives the usage fee from the management server 100 and executes the payment process of the usage fee by the payment server 400 (step S909). When the payment of the usage fee is completed, a notification of the completion of the payment of the usage fee may be transmitted to the management server 100.

The transceiver 101 of the management server 100 executes the payment process of the fare transmitted from the operation server 300 by the payment server 400 (step S910). When the payment of the fare is completed, a notification of the completion of the payment of the fare may be transmitted to the operation server 300.

In this way, by having the vehicle operator operate a ride-sharing vehicle and travel to the addresses of members belonging to the ride-sharing group one after another to pick up the members, it is possible to efficiently transport many members to their destinations, and the members can travel for a cheaper fee than the fare for a regular taxi or the like. Since the fee is paid by the supporter using the information terminal device 200 after the ride-sharing, even members who are unable or unfamiliar with operating the information terminal device 200 can use the ride-sharing service without any confusion. It also reduces the hassle of receiving fares during travel for the vehicle operator.

In the above-mentioned embodiment, we have assumed that elderly people visit hospitals, government offices, retail stores, etc., but this is not limited to elderly people; anyone who wishes to ride-share can also use the service, such as elementary and junior high school students attending cram schools or sports clubs.

In the above-described embodiment, it is assumed that the operation date and time will be adjusted by the member or supporter who will be sharing the ride by phone, email, etc., but when requesting a ride, the desired ride-sharing date and time can also be input, so that groups can be created taking into account the ride-sharing date and time in addition to the destination, and the operation date and time can be determined in advance and notified to the members. Furthermore, groupings can be created taking into account the attributes of the members (e.g., gender, age, hobbies, etc.).

For places that are frequently visited, such as hospitals, in addition to soliciting carpoolers for each destination, members who have formed a group may secure a carpooling vehicle and operate it by adjusting the next operation date and time. Also, groups that have carpooled once or multiple times may be notified of information about re-carpooling when a specified period has passed since the last carpooling.

Example 2
Fig. 10 is a block diagram showing the configuration of the ride-sharing support system 20 according to the second embodiment. In the second embodiment, when a user (or a supporter) adjusts a travel schedule with another user, a process is executed to display candidate ride-sharing schedules on the information terminal device 200. The configuration of the ride-sharing support system 20 according to the second embodiment will be described below. Note that in the configuration of the second embodiment shown in Fig. 10, the same configurations and functions as those of the first embodiment are assigned the same numbers as those of the first embodiment. For the same functions and configurations as those of the first embodiment, refer to the description in the first embodiment, and the description here will be omitted.

The management server 500 includes a transmission/reception unit 101, a member selection unit 102, a group generation unit 103, a reservation confirmation unit 104, a vehicle dispatch arrangement unit 105, an operation management unit 106, a usage fee calculation unit 107, a candidate carpool schedule generation unit 508, an operation schedule management unit 509, a member information storage unit 110, a group information storage unit 120, a selection condition storage unit 130, and a facility information storage unit 540.

Figure 11 is an explanatory diagram showing an example of the data configuration of the facility information storage unit 540. The facility information storage unit 540 stores information about facilities that are the destinations of carpooling. More specifically, the usage time for each destination facility is stored in association with the day of the week, the start time, and the end time. Note that the usage time does not have to be limited to the start time and end time for each day of the week, and instead of the day of the week, the start time and end time for each date, month, and year, or a specified rule may be stored. Furthermore, the usage time may be stored in different items for each facility.

The candidate carpooling schedule generating unit 508 generates candidate carpooling schedules for users to select. Here, the candidate carpooling schedule indicates the candidate carpooling date and time and the usage interval, but may be only the candidate carpooling date and time. More specifically, in the first candidate carpooling schedule generation, the candidate carpooling schedule generating unit 508 sets all the dates desired by each user as the candidate carpooling schedules. If a schedule that all users agree on cannot be obtained in the first presentation of the candidate carpooling schedules, the candidate carpooling schedule generating unit 508 generates candidate carpooling schedules based on predetermined rules in the second and subsequent candidate carpooling schedule generation. Alternatively, in the second and subsequent candidate carpooling schedule generation, the candidate carpooling schedule generating unit 508 generates candidate carpooling schedules using a learning unit that has undergone reinforcement learning (not shown in FIG. 10) instead of the predetermined rules.

The operation schedule management unit 509 determines the operation schedule for each group based on the responses to the potential ride-sharing schedules received from the information terminal device 200. More specifically, the operation schedule management unit 509 determines the operation schedule for the group if there is a schedule for which all users have responded that they are willing to ride-sharing, based on the responses to the potential ride-sharing schedules sent from the information terminal device 200 for each group.

The following describes the ride-sharing request process executed by the ride-sharing support system 20 having the above-mentioned configuration. Figure 12 is a flowchart showing the ride-sharing request process steps executed by the management server 500 and the information terminal device 200 provided in the ride-sharing support system 20.

The operation display unit 202 of the information terminal device 200 displays a ride-pooling request screen for requesting ride-pooling with other users (step S1201). The operation display unit 202 accepts input of ride-pooling request information from the ride-pooling request screen (step S1202). FIG. 13 is an explanatory diagram showing an example of a screen displayed on the information terminal device 200 of the recruiter and the applicant. FIG. 13(a) shows an example of a ride-pooling request screen displayed on the information terminal device 200 of the recruiter. The ride-pooling request information includes the destination (or/and destination address) and the desired ride-pooling schedule (desired ride-pooling date and time, interval between uses). Note that it is not necessary to input all of the desired ride-pooling schedule. The transmission/reception unit 201 transmits the ride-pooling request information to the management server 100 (step S1203).

The transmitting/receiving unit 101 of the management server 500 receives the ride-pooling request information transmitted from the information terminal device 200, and the member selection unit 102 selects members to whom to send a ride-pooling invitation notification based on the ride-pooling request information, the selection conditions stored in the selection condition storage unit 130, and the information on the members stored in the member information storage unit 110 (step S1204). The transmitting/receiving unit 101 transmits the ride-pooling invitation notification to the information terminal device 200, which is the contact point for each of the members to be notified (step S1205).

The transmission/reception unit 201 of the information terminal device 200 receives the ride-sharing invitation notification from the management server 100, and the operation display unit 202 displays a ride-sharing invitation notification screen based on the ride-sharing invitation notification (step S1206). The information terminal device 200 of each of the members who have been notified displays the ride-sharing invitation notification screen shown in FIG. 7. The operation display unit 202 accepts a response to the ride-sharing invitation notification (step S1207). More specifically, the operation display unit 202 accepts input of "YES" or "NO" as a response to the ride-sharing invitation notification from the screen shown in FIG. 7, and if the response to the ride-sharing invitation notification is "YES", it accepts input of the desired ride-sharing date. The desired ride-sharing date may be input in its entirety, in part, or not at all. Figures 13(b) and 13(c) show examples of screen displays (after input) for applicant A and applicant B who have input "YES" as a response to the ride-sharing invitation notification. The transmission/reception unit 201 transmits a response to the ride-pooling invitation notice (and the desired ride-pooling schedule) to the management server 100 (step 1208).

The transmitting/receiving unit 101 of the management server 500 receives a response to the ride-pooling invitation notice (and the desired ride-pooling date) from the information terminal device 200. The group generating unit 103 generates a group, which is a set of members who will ride-pool in one vehicle, from among the members who responded by the invitation deadline that they wish to ride-pool ("YES") and the invitees who transmitted the desired ride-pooling date (step S1209).

The candidate ride-pooling schedule generating unit 508 generates candidate ride-pooling schedules for each group (step S1210). More specifically, the candidate ride-pooling schedule generating unit 508 generates a candidate ride-pooling schedule that includes all of the desired ride-pooling schedules of the recruiter and applicants as the first candidate ride-pooling schedule. The transmitting/receiving unit 101 transmits the candidate ride-pooling schedule to the information terminal device 200, which is the contact point for the applicants who belong to the group (step S1211). The transmitting/receiving unit 101 transmits the candidate ride-pooling schedule to the information terminal device 200, which is the contact point for the recruiter who belongs to the group (step S1212).

In the applicant's information terminal device 200, the transmission/reception unit 201 receives the candidate ride-sharing dates from the management server 500, and the operation display unit 202 displays the candidate ride-sharing dates (step S1213). FIG. 14 is an explanatory diagram showing an example of a ride-sharing date adjustment request screen displayed on the information terminal device 200 of the recruiter and the applicant. As shown in FIG. 14, the ride-sharing date adjustment request screen of the recruiter, applicant A, and applicant B displays the desired ride-sharing dates entered by the recruiter, applicant A, and applicant B in FIG. 13 as the desired ride-sharing dates. The operation display unit 202 accepts input of whether or not each user can ride-sharing from the candidate ride-sharing dates (step S1214). As shown in FIG. 14, applicant A and applicant B input whether or not they can ride-sharing by checking the checkbox for each date. Note that the operation display unit 202 may accept input of the desired ride-sharing dates in a free input field instead of or in addition to input of whether or not the candidate ride-sharing dates can be used. The transmission/reception unit 201 transmits the suitability of the proposed ride-sharing dates (including the desired ride-sharing dates if there is an entry in the free input field) to the management server 500 (step S1215).

As with the applicant's information terminal device 200, in the recruiter's information terminal device 200, the transmission/reception unit 201 receives the potential ride-pooling dates from the management server 500, and the operation display unit 202 displays the potential ride-pooling dates (step S1216). Figure 14 (a) is an example of a ride-pooling date adjustment request screen displayed on the recruiter's information terminal device 200. The operation display unit 202 accepts input of the suitability of the potential ride-pooling dates (step S1217). The transmission/reception unit 201 transmits the suitability of the potential ride-pooling dates (including the desired ride-pooling dates if there is an input in the free input field) to the management server 500 (step S1218).

The transmission/reception unit 101 of the management server 500 receives the availability of the candidate carpooling schedule from the information terminal device 200, and the operation schedule management unit 509 determines the operation schedule for each group based on whether there is a schedule that matches the availability of the candidate carpooling schedule for each member (step S1219). If the available schedules of all users do not match (step S1219: No), return to step S1210 and generate a new candidate carpooling schedule. The candidate carpooling schedule generation unit 508 generates candidate carpooling schedules for the second and subsequent times based on predetermined rules. Alternatively, the candidate carpooling schedule generation unit 508 generates candidate carpooling schedules using a machine learning learning unit instead of predetermined rules. Details will be described later. If there is a schedule that matches the availability of the candidate carpooling schedule, the operation schedule is determined (step S1219: Yes), and the operation schedule management unit 509 stores the operation schedule for each group in the group information storage unit 120 (step S1220). If there are multiple dates that match the availability of the proposed ride-sharing dates, the operation date will be determined according to rules such as selecting the earliest date.

In this way, the system adjusts the ride-pooling schedule by presenting each user's desired ride-pooling schedule as the first proposed ride-pooling schedule. If users are unable to agree on the first proposed ride-pooling schedule, new proposed ride-pooling schedules are generated and presented. This allows users (or supporters) to easily adjust the ride-pooling schedule without having to contact each other by phone, email, etc.

In the above-described embodiment, if the interval is not specified, the user can use carpooling on a one-off basis. If the user specifies the interval, the next operation date and time is stored in the storage unit after the first carpooling. After that, in the vehicle dispatch process shown in FIG. 8, if it is determined that the operation date and time is a predetermined period before (step S801: Yes), carpooling confirmation information is generated and transmitted to the information terminal device 200. The user is automatically asked by the carpooling support system 20 whether or not to carpool on the next operation date and time without having to solicit or apply for carpooling again, and by sending a response to the carpooling confirmation that the user will carpool, the user can use carpooling to a destination facility that is regularly visited.

Next, the process of generating candidate carpooling schedules for the second and subsequent times described in step S1210 will be described. The process of generating candidate carpooling schedules for the second and subsequent times includes (1) a process of generating candidate carpooling schedules according to predetermined rules, and (2) a process of generating candidate carpooling schedules using a learning unit that has undergone reinforcement learning.

First, (1) the process of generating candidate carpool schedules according to predetermined rules will be described. The candidate carpool schedule generation unit 508 generates schedules according to predetermined rules based on the schedules among the first candidate carpool schedules where at least one person agreed (hereinafter referred to as target schedules). Furthermore, a schedule with a high priority is selected as the candidate carpool schedule to be presented to the user using weighting. Note that if the destination facility specifies the dates, days of the week, times, etc. when the facility is available, dates outside of the hours of availability are excluded from the candidate carpool schedules generated based on the rules, and a candidate carpool schedule with a high priority is selected using weighting.

For example, if at least one of the carpoolers responds that he/she is available for the first ride-sharing candidate date "12/13 (Tue) 9:00", multiple dates with different dates and times are generated based on the target date "12/13 (Tue) 9:00". From the multiple dates generated based on the target date, the facility information storage unit 540 shown in FIG. 11 is referenced to delete dates that are outside the use hours of the destination facility. In addition, from the multiple dates generated based on the target date, dates that have already been presented as ride-sharing candidate dates and have not been agreed to by the user are deleted. The dates narrowed down in this way are further weighted, and selected in order of priority as the ride-sharing candidate dates. Conditions for increasing the weight include, for example, a large number of people agreeing to the target date, a date desired by a user who has not agreed to the target date (hereinafter referred to as a non-agreed user), a date close to the date desired by the non-agreed user, the same day of the week desired by the non-agreed user, the same time desired by the non-agreed user, or a time close to the time desired by the non-agreed user. As a result of evaluating each date, the date with the highest priority is selected. If there are other dates other than "12/13 (Tue) 9:00" that are answered as possible for carpooling, a schedule is generated using that date as a target date, and the priority is determined by weighting. From the generated schedules, the date with the highest priority is selected as the candidate date for the second carpooling.

If the second set of possible carpooling dates is not agreed upon by all users, a third set of possible carpooling dates is generated based on the second set of responses. From the third time onwards, the system repeats the process of generating possible carpooling dates and presents them to users.

In this way, the second and subsequent potential carpooling dates are generated based on the user's answers and in accordance with predefined rules, and then weighted to present high-priority potential carpooling dates, so that users are presented with potential carpooling dates that are more likely to be accepted. In addition, the dates are narrowed down based on the available hours of the destination facility, etc., so users can adjust their carpooling dates without having to check the facility's operating hours, etc., in advance.

Next, we will explain (2) the process of generating candidate ride-pooling schedules using a learning unit that has undergone reinforcement learning. Figure 15 is a flowchart showing the process of generating candidate ride-pooling schedules executed by the candidate ride-pooling schedule generating unit 508 of the management server 500.

The candidate carpooling schedule generation unit 508 inputs information related to the destination facility, information related to the user, and responses from the user to the learning unit (step S1501). For example, information related to the destination facility is the destination facility name, destination facility category, etc., information related to the user is the user's age, gender, etc., and responses from the user are responses by each user to candidate carpooling schedules, etc.

The learning unit included in the candidate carpooling schedule generation unit 508 is a learning unit that performs reinforcement learning so as to input information related to the destination facility, information related to the user, and responses from the user, and output candidate carpooling schedules that are likely to be agreed upon by all users in each group. The reinforcement learning performed by the learning unit will be described later. Note that the learning unit may be a learning unit that performs machine learning such as supervised learning and unsupervised learning in addition to reinforcement learning, and that inputs information related to the destination facility, information related to the user, and responses from the user, and outputs candidate carpooling schedules.

The candidate carpooling schedule generation unit 508 outputs the candidate carpooling schedule from the learning unit (step S1502). The candidate carpooling schedule generation unit 508 judges whether the candidate carpooling schedule output from the learning unit is within the operating hours of the destination facility (step S1503). If it is judged that the candidate carpooling schedule is within the operating hours of the destination facility (step S1503: Yes), the candidate carpooling schedule is stored in a memory unit (not shown) (step S1504). If it is judged that the candidate carpooling schedule is not within the operating hours of the destination facility (step S1503: No), the candidate carpooling schedule is not stored in the memory unit. Note that if multiple candidate carpooling schedules are output from the learning unit, it is judged whether each candidate carpooling schedule is within the operating hours of the destination facility.

The candidate carpooling schedule generating unit 508 judges whether a predetermined number of candidate carpooling schedules have been generated (step S1505). If it is judged that the predetermined number of candidate carpooling schedules have not been generated (step S1505: No), the process returns to step S1502 and executes processing on the next candidate carpooling schedule output from the learning unit. If it is judged that the predetermined number of candidate carpooling schedules have been generated (step S1505: Yes), the candidate carpooling schedule generating process ends, and the candidate carpooling schedules are sent to the information terminal device 200 in steps S1211 and S1212 of FIG. 12. FIG. 16 is an explanatory diagram showing an example of a carpooling schedule adjustment request screen that displays the candidate carpooling schedule for the second time. The example of FIG. 16 shows a screen after the candidate carpooling schedule for the second time is displayed and the approval or disapproval of the candidate carpooling schedule is input. In this example, there is no free input field, but a free input field may be added.

In this way, the second and subsequent potential carpooling dates are output by the learning unit, which uses reinforcement learning based on the user's responses, and therefore potential carpooling dates that are more agreeable to the user are presented. In addition, the potential carpooling dates are narrowed down based on the available hours of the destination facility, etc., so the user can adjust the carpooling time without having to check the facility's operating hours in advance.

Next, the learning process of the learning unit in the learning device 600 will be described. FIG. 17 is a block diagram showing the configuration of the learning device 600. The learning device 600 reads out state variables stored in the state storage unit 620 when determining potential carpooling dates, calculates rewards based on each user's response to the potential carpooling dates, and updates the action value function based on the calculated rewards. As shown in FIG. 17, the learning device 600 includes a learning unit 610, a state storage unit 620, and a potential carpooling date storage unit 630.

The state storage unit 620 stores state variables when users decide on a carpooling schedule. More specifically, the state storage unit 620 stores, as state variables, information about the destination facility, information about users belonging to the group, and each user's response to one or more candidate carpooling schedules when deciding on the carpooling schedule.

The behavior memory unit 630 stores the candidate carpooling dates and the like that are output by the learning unit using the state variables as input. If the learning unit generates multiple candidate carpooling dates, the behavior memory unit 630 stores multiple candidate carpooling dates.

The learning unit 610 includes a reward calculation unit 611 and a function update unit 612. The reward calculation unit 611 calculates a reward for the answer to the potential carpooling schedule presented to the user. More specifically, the reward calculation unit 611 calculates a reward for the answer to the potential carpooling schedule in accordance with a predetermined reward condition. As an example, the reward condition is set so that the greater the number of acceptable answers given by the user to the potential carpooling schedule presented to the user, the greater the reward. The function update unit 612 updates the action value function that generates the potential carpooling schedule based on the reward calculated by the reward calculation unit 611.

Figure 18 is a flowchart showing the learning process steps executed by the learning server 600.

The remuneration calculation unit 611 acquires information related to the destination facility from the state storage unit 620 (step S1801). Information related to the destination facility is the business type, type, category, etc., and examples include the business type "medical care", the type "general clinic", and the category "internal medicine". The remuneration calculation unit 611 acquires information related to the user from the state storage unit 620 (step S1802). The remuneration calculation unit 611 acquires the answer of each user to the candidate carpooling schedule from the state storage unit 620 (step S1803). The remuneration calculation unit 611 calculates the remuneration according to the answer of each user to the candidate carpooling schedule (step S1804).

The function update unit 612 updates the action value function based on the reward calculated by the reward calculation unit 611 (step S1805). In addition to having one action value function for the whole, it may have one for each destination facility, one for each group, or one for each destination facility and group. The function update unit 612 determines whether there is an answer for each user to the potential carpooling schedule (step S1806). If it is determined that there is an answer for each user to the potential carpooling schedule, the process returns to step S1803 and obtains the answer for each user to the potential carpooling schedule.

If it is determined that there is no response from each user to the candidate carpooling schedule (step S1806: No), it is determined whether learning has been completed (step S1807). If it is determined that learning has not been completed, i.e., learning has not been completed for all state variables stored in the state storage unit 620 (step S1807: No), the process returns to step S1801 and continues the learning process. If it is determined that learning has been completed (step S1807: Yes), the process ends.

In this way, the learning device 600 can perform reinforcement learning of the learning unit 610 by the above-mentioned processing. The ride-pooling support system 20 can operate the learning unit 610 of the learning server 600 and generate candidate ride-pooling schedules using the learning unit 610 by incorporating the learning unit 610 into the candidate ride-pooling schedule generation unit 508 or by issuing an instruction from the ride-pooling support system 20 via the network. This makes it possible to present candidate ride-pooling schedules that are easy for users to agree to. In addition, by using the information accumulated by the user through use of the ride-pooling support system 20 and performing further reinforcement learning, it is possible to present candidate ride-pooling schedules that are even easier for users to agree to.

The hardware configuration of the management server 100, information terminal device 200, operation server 300, payment server 400, management server 500, learning device 600, vehicle terminal device, etc. in the above-mentioned embodiments is a normal computer that includes one or more processors such as a CPU (Central Processing Unit), MPU (Micro-Processing Unit) or GPU (Graphics Processing Unit), and is equipped with external storage devices such as ROM (Read Only Memory), RAM (Random Access Memory), and HDD (Hard Disk Drive), communication control devices, etc., and the above-mentioned configurations and functions are realized by the CPU, etc. reading and running programs stored in the ROM, RAM, HDD, etc.

The programs that run on the management server 100, information terminal device 200, operation server 300, payment server 400, management server 500, learning device 600, vehicle terminal device, etc. may be stored on a computer connected to a network N such as the Internet and provided by downloading via the network N, or may be recorded in an installable or executable format on a computer-readable recording medium such as a CD-ROM, DVD, USB memory, or SD card and provided. In addition, the programs that realize the above-mentioned functions and processes may be provided in the form of an API (Application Programming Interface), SaaS (Software as a Service), or cloud computing.

The present invention is not limited to the above-described embodiments, and does not necessarily have to be physically configured as illustrated. The present invention can be configured by functionally or physically dividing, integrating, replacing, modifying, or deleting all or part of the components described in the embodiments in any unit according to various loads, usage conditions, etc.

N...network, 10, 20...ride-sharing support system, 100, 500...management server, 101...transmission/reception unit, 102...member selection unit, 103...group generation unit, 104...reservation confirmation unit, 105...vehicle dispatch arrangement unit, 106...operation management unit, 107...usage fee calculation unit, 110...member information storage unit, 120...group information storage unit, 130...selection condition storage unit, 200...information terminal device, 201...transmission/reception unit, 202...operation display unit, 300...operation server, 400...payment server, 508...ride-sharing candidate schedule generation unit, 509...operation schedule management unit, 540...facility information storage unit, 600...learning device, 610...learning unit, 611...reward calculation unit, 612...function update unit, 620...state storage unit, 630...behavior storage unit

Claims (13)

a member information storage unit that stores a member ID for identifying a member and contact information of the member in association with each other;
A destination receiving unit that receives a destination of the ride-sharing;
a recruitment information sending unit that sends ride-sharing recruitment information including the destination received by the destination receiving unit to the contact information associated with the member ID;
a group generation unit that generates a group, which is a set of members who will ride together in a vehicle, based on a response of each of the members to the ride-sharing invitation information received from the contact point;
a group information storage unit that stores a group ID for identifying the group generated by the group generation unit and a member ID indicating a member belonging to the group in a group information storage unit in association with each other;
an adjustment request sending unit that sends information about the members belonging to the group and an operation date and time adjustment request to the contact information of each of the members belonging to the group;
an operation date and time receiving unit that receives operation dates and times adjusted by members belonging to the group;
an operation date and time storage unit that stores the operation date and time received by the operation date and time receiving unit in the group information storage unit in association with the group ID;
A management server comprising: the member information storage unit stores information about the member in association with the member ID;
A member selection unit selects a member to which the ride-sharing invitation information is to be sent based on a predetermined selection condition and information about the member,
The management server according to claim 1 , wherein the recruitment information sending unit sends the ride-sharing recruitment information to contact information of the member selected by the member selection unit. a confirmation information sending unit that sends ride-sharing confirmation information to contact addresses of members belonging to the group before a predetermined time from the operation date and time;
A vehicle dispatching unit that transmits a request for arrangement of a vehicle to be used for sharing to an operation server based on a response to the ride-sharing confirmation information;
3. The management server according to claim 1, further comprising: a member information storage unit that stores a member ID for identifying a member and contact information of the member in association with each other;
A destination receiving unit that receives a destination of the ride-sharing;
a recruitment information sending unit that sends ride-sharing recruitment information including the destination received by the destination receiving unit to the contact information associated with the member ID;
a group generation unit that generates a group, which is a set of members who will ride together in a vehicle, based on a response of each of the members to the ride-sharing invitation information received from the contact point;
a group information storage unit that stores a group ID for identifying the group generated by the group generation unit and a member ID indicating a member belonging to the group in a group information storage unit in association with each other;
a desired ride-sharing schedule receiving unit that receives a desired ride-sharing schedule of each of the members belonging to the group;
a ride-sharing candidate schedule generating unit that generates a ride-sharing candidate schedule based on the desired ride-sharing schedule received by the desired ride-sharing schedule receiving unit;
a ride-sharing candidate schedule sending unit that sends the ride-sharing candidate schedules generated by the ride-sharing candidate schedule generating unit to the contact information;
a possible schedule receiving unit that receives whether or not ride-sharing is possible for the possible ride-sharing schedule transmitted by the possible ride-sharing schedule transmitting unit;
A management server characterized by comprising: an operation schedule management unit that determines an operation schedule for each group based on whether or not ride-sharing is possible for the candidate ride-sharing dates, and stores the determined operation schedule in the group information storage unit in association with the group ID . The management server according to claim 4 , wherein the ride-sharing candidate schedule generation unit generates a new ride-sharing candidate schedule based on predetermined conditions when the operation schedule management unit is unable to determine the operation schedule. The management server of claim 4, wherein when the operation schedule management unit is unable to determine the operation schedule, the candidate ride-pooling schedule generation unit generates a new candidate ride-pooling schedule using a learning unit that inputs whether or not the candidate ride-pooling schedule is available and outputs the candidate ride-pooling schedule . an operation start receiving unit that receives a group ID from the operation server;
an operation management unit that judges whether the group ID received by the operation start receiving unit is stored in the group information storage unit, and when it is judged that the group ID is stored, transmits to the operation server a message indicating that the fare will not be received;
a service end receiving unit for receiving the group ID and the fare from the service server;
a usage fee calculation unit that calculates a usage fee for each of the members based on the fare and information about the members belonging to the group;
a payment information sending unit that sends payment information including the usage fee for each member to the contact point;
7. The management server according to claim 1, further comprising: a state storage unit for storing information on the destination facility, information on the members belonging to the group, and responses of each member to the candidate carpooling schedule as state variables in determining the carpooling schedule;
a behavior memory unit that stores the candidate ride-sharing schedules output by the learning unit using the state variables as input;
a reward calculation unit for calculating a reward for the candidate ride-sharing schedule output based on the state variables;
a function update unit that updates an action value function based on the reward calculated by the reward calculation unit,
The function update unit repeatedly updates the action value function, thereby learning candidate carpooling schedules that result in a higher reward. A ride-sharing support system comprising one or more information terminal devices and a management server connected to the information terminal devices via a network,
The information terminal device
A destination transmission unit that transmits a destination of the ride-sharing;
The management server includes:
a member information storage unit that stores a member ID for identifying a member and contact information of the member in association with each other;
a destination receiving unit that receives the destination from the information terminal device;
a recruitment information sending unit that sends ride-sharing recruitment information including the destination received by the destination receiving unit to the contact information associated with the member ID;
a group generation unit that generates a group, which is a set of members who will ride together in a vehicle, based on a response of each of the members to the ride-sharing invitation information received from the contact point;
a group information storage unit that stores a group ID for identifying the group generated by the group generation unit and a member ID indicating a member belonging to the group in a group information storage unit in association with each other;
an adjustment request sending unit that sends information about the members belonging to the group and an operation date and time adjustment request to the contact information of each of the members belonging to the group;
an operation date and time receiving unit that receives operation dates and times adjusted by members belonging to the group;
an operation date and time storage unit that stores the operation date and time received by the operation date and time receiving unit in the group information storage unit in association with the group ID;
A ride-sharing support system comprising: A ride-sharing support system comprising one or more information terminal devices and a management server connected to the information terminal devices via a network,
The information terminal device
A destination transmission unit that transmits a destination of the ride-sharing;
The management server includes:
a member information storage unit that stores a member ID for identifying a member and contact information of the member in association with each other;
a destination receiving unit that receives the destination from the information terminal device;
a recruitment information sending unit that sends ride-sharing recruitment information including the destination received by the destination receiving unit to the contact information associated with the member ID;
a group generation unit that generates a group, which is a set of members who will ride together in a vehicle, based on a response of each of the members to the ride-sharing invitation information received from the contact point;
a group information storage unit that stores a group ID for identifying the group generated by the group generation unit and a member ID indicating a member belonging to the group in a group information storage unit in association with each other;
a desired ride-sharing schedule receiving unit that receives a desired ride-sharing schedule of each of the members belonging to the group;
a ride-sharing candidate schedule generating unit that generates a ride-sharing candidate schedule based on the desired ride-sharing schedule received by the desired ride-sharing schedule receiving unit;
a ride-sharing candidate schedule sending unit that sends the ride-sharing candidate schedules generated by the ride-sharing candidate schedule generating unit to the contact information;
a possible schedule receiving unit that receives whether or not ride-sharing is possible for the possible ride-sharing schedule transmitted by the possible ride-sharing schedule transmitting unit;
an operation schedule management unit that determines an operation schedule for each group based on whether or not the candidate ride-sharing schedule is available, and stores the determined operation schedule in the group information storage unit in association with the group ID;
A ride-sharing support system comprising: 1. A computer-implemented method for ride-sharing assistance, comprising:
A destination receiving step of receiving a destination of the ride-sharing;
a member information storage unit that stores ride-sharing invitation information including the destination received by the destination receiving step, and a member information sending step that sends the ride-sharing invitation information to a contact address associated with a member ID that identifies the member ;
a group generation step of generating a group, which is a set of members who will ride together in a vehicle, based on a response of each of the members to the ride-sharing invitation information received from the contact point;
a group information storage step of storing a group ID for identifying the group generated by the group generation step and a member ID indicating a member belonging to the group in a group information storage unit in association with each other;
an adjustment request sending step of sending information about the members belonging to the group and a request to adjust the operation date and time to contact information of each of the members belonging to the group;
a flight date and time receiving step of receiving the flight date and time adjusted by the members belonging to the group;
an operation date and time storage step of storing the operation date and time received in the operation date and time receiving step in the group information storage unit in association with the group ID;
A ride-sharing assistance method comprising: 1. A computer-implemented method for ride-sharing assistance, comprising:
A destination receiving step of receiving a destination of the ride-sharing;
a member information storage unit that stores ride-sharing invitation information including the destination received by the destination receiving step, and a member information sending step that sends the ride-sharing invitation information to a contact address associated with a member ID that identifies the member;
a group generation step of generating a group, which is a set of members who will ride together in a vehicle, based on a response of each of the members to the ride-sharing invitation information received from the contact point;
a group information storage step of storing a group ID for identifying the group generated by the group generation step and a member ID indicating a member belonging to the group in a group information storage unit in association with each other;
a desired ride-sharing schedule receiving step for receiving a desired ride-sharing schedule of each of the members belonging to the group;
a ride-sharing candidate schedule generating step for generating a ride-sharing candidate schedule based on the desired ride-sharing schedule received in the desired ride-sharing schedule receiving step;
a ride-sharing candidate schedule sending step of sending the ride-sharing candidate schedule generated by the ride-sharing candidate schedule generating step to the contact;
a possible schedule receiving step for receiving whether or not ride-sharing is possible for the possible ride-sharing schedule transmitted by the possible ride-sharing schedule transmitting step;
an operation schedule management step of determining an operation schedule for each group based on whether or not the candidate ride-sharing schedule is available, and storing the determined operation schedule in the group information storage unit in association with the group ID;
A ride-sharing assistance method comprising: A ride-pooling support program for causing a computer to execute the ride-pooling support method according to claim 11 or 12 .