Information processing device and information processing method
The information processing device manages ride-sharing in vehicle dispatch services by identifying approved users and presenting notifications for approver user approval, addressing the risk of unintended vehicle sharing and improving safety and security.
Patent Information
- Application Number
- PCT/JP2024/014099
- Authority / Receiving Office
- WO · WO
- Patent Type
- Applications
- Current Assignee / Owner
- Filing Date
- 2024-04-05
- Publication Date
- 2025-10-09
AI Technical Summary
There is a risk that a user requiring protection or care may ride in a service vehicle with a third party in a vehicle dispatch service, as existing systems do not adequately restrict vehicle sharing with unintended users.
An information processing device and method that identifies approved users, determines if they need approval from an approver user, and presents a notification to the approver user for approval of sharing the service vehicle with another user, using a controller to manage ride-sharing decisions based on user identities and trustworthiness scores.
This solution effectively restricts approved users from sharing vehicles with unintended users, enhancing safety and security in vehicle dispatch services by allowing approver users to control ride-sharing arrangements.
Smart Images

Figure JP2024014099_09102025_PF_FP_ABST
Abstract
Description
Information processing device and information processing method
[0001] The present invention relates to an information processing device and an information processing method.
[0002] The following Patent Document 1 describes a vehicle monitoring system that allows guardians to check the riding status of a person being monitored in real time.
[0003] Japanese Patent Application Laid-Open No. 2022-069033
[0004] In a vehicle dispatch service that transports multiple passengers simultaneously, there is a risk that a user who requires protection or care for another person may ride in a service vehicle with a third party. The present invention aims to restrict an approved user, who requires approval from an approver user to use the vehicle dispatch service, from sharing a service vehicle with another user not intended by the approver user.
[0005] An information processing device of one embodiment of the present invention includes a controller that performs the following processes: identifying a user who will use a service vehicle provided for a ride-hailing service; determining whether the identified user is an approved user who requires approval from an approver user who is a user other than the identified user for using the ride-hailing service; and presenting a first notification to the approver user of the first user, who is the approved user, of the first and second users, which includes a choice as to whether to approve the first user and the second user sharing the service vehicle.
[0006] According to the present invention, an approved user who requires approval from an approver user to use a ride-hailing service can be restricted from sharing a service vehicle with other users not intended by the approver user. The objects and advantages of the present invention are realized and achieved by using the elements and combinations set forth in the claims. It should be understood that both the foregoing general description and the following detailed description are merely exemplary and explanatory and are not intended to limit the invention as defined by the claims.
[0007] FIG. 1 is a schematic configuration diagram of an example of a vehicle dispatch service providing system according to an embodiment. FIG. 2 is a sequence diagram of an example of processing in the vehicle dispatch service providing system of FIG. 1. FIG. 3 is a diagram of an example of a passenger input screen. (a) and (b) are diagrams of a first example and a second example of a ride-sharing notification screen. FIG. 4 is a diagram of an example of a blacklist setting pop-up screen. FIG. 5 is a flowchart of an example of an information processing method according to a first embodiment. (a) is a diagram of an example of a ride-sharing setting screen, and (b) is a diagram of a third example of a ride-sharing notification screen. FIG. 6 is a flowchart of an example of an information processing method according to a second embodiment.
[0008] (First embodiment) (Configuration) FIG. 1 is a schematic configuration diagram of an example of a vehicle dispatch service providing system according to an embodiment. The vehicle dispatch service providing system 1 is a system that provides a vehicle dispatch service (passenger transportation service) that transports users by operating vehicles Va, Vb, etc. In this specification, the vehicles Va, Vb, etc. that are provided for the vehicle dispatch service by the vehicle dispatch service providing system 1 are referred to as "service vehicles," and the vehicle dispatch service provided by the vehicle dispatch service providing system 1 is referred to as "vehicle dispatch service." The vehicle dispatch service providing system 1 includes a server device S, service vehicles Va, Vb, etc., and terminal devices T1, T2, Ta, Tb, etc. In the following description, the service vehicles Va, Vb, etc. may be collectively referred to as "service vehicle V."
[0009] Terminal devices T1, T2, Ta, Tb... are terminal devices operated by users U1, U2, Ua, Ub... who use the vehicle dispatch service, respectively. In the following description, terminal devices T1, T2, Ta, Tb... may be collectively referred to as "terminal device T." Dedicated application software for using the vehicle dispatch service (hereinafter sometimes referred to as "vehicle dispatch software") is installed on terminal device T. User U1 is a user who requires approval from user Ua to use the vehicle dispatch service. In the following description, user U1 may be referred to as the "approved user," and user Ua may be referred to as the "approver user." For example, approved user U1 may be a protected person such as a minor (e.g., a child) under a certain age or a person receiving care such as an elderly person. For example, approver user Ua may be a guardian, including the parents of a minor, of approved user U1, or a caregiver who cares for an elderly person. In the following description, users of the vehicle dispatch service, including users U1, U2, Ua, Ub, . . . , may be collectively referred to as "user U."
[0010] The terminal device T is, for example, a portable information terminal that can be carried by the user U, or a small, portable computer. If the approved user U1 does not own such a device, the terminal device T1 may be a terminal device (for example, a tablet terminal or a small computer) located in a facility (for example, a public facility) used by the approved user U1. The user U can reserve a vehicle dispatch service using vehicle dispatch software executed on the terminal device T. In addition, the approver user Ua uses vehicle dispatch software executed on the terminal device Ta to approve whether the approved user U1 may share a ride (ride) in the service vehicle V with another user (for example, user U2).
[0011] The terminal device T1 includes a communication device 30, a human-machine interface (HMI) 31, and a controller 32. The terminal devices T2, Ta, Tb, etc. have the same configuration as the terminal device T1. The communication device 30 provides a communication function between the terminal device T and the server device S. The HMI 31 is an interface device that exchanges information between the terminal device T and the user U. The HMI 31 includes a display device that can be seen by the user U, and a speaker and buzzer that output auditory information. The HMI 31 also includes operators (e.g., buttons, switches, levers, dials, keyboards, touch panels, etc.) and a voice input device that accept operational inputs to the terminal device T by the user U.
[0012] The controller 32 is an electronic control unit (ECU) that controls the operation of the terminal device T. The controller 32 includes a processor 33 and peripheral components such as a storage device 34. The processor 33 may be, for example, a central processing unit (CPU) or a micro-processing unit (MPU). The storage device 34 may include a non-transitory tangible storage medium such as a register, a cache memory, a read-only memory (ROM), or a random access memory (RAM). The functions of the terminal device T described below are realized, for example, by the processor 33 executing a computer program stored in the storage device 34.
[0013] The server device S is an information processing device that receives reservation information from the terminal device T and arranges for a service vehicle V to be provided for use by the user U in accordance with the reservation information. The server device S is an example of an "information processing device" as defined in the claims. The server device S includes a communication device 10, a database 11, and a controller 12. The communication device 10 provides communication functions between the server device S, the service vehicle V, and the terminal device T. The database 11 stores various information used to provide the vehicle dispatch service. For example, the database 11 stores information such as information about the user U of the vehicle dispatch service (hereinafter referred to as "user information"), a map database of the business area in which the vehicle dispatch service providing system 1 provides the vehicle dispatch service, reservation information for the service vehicle V received from the user U, a vehicle dispatch plan that records the dispatch status of the service vehicle V for the user U, and driving plan information for the service vehicle V dispatched to the user U.
[0014] The controller 12 includes a processor 13 and peripheral components such as a storage device 14. The processor 13 may be, for example, a CPU or an MPU. The storage device 14 may include a register, a cache memory, or a non-transitory tangible storage medium such as a ROM or RAM. The functions of the server device S described below are realized by the processor 13 executing a computer program stored in the storage device 14, for example.
[0015] The service vehicle V is a vehicle that operates in response to a request from a user U (a so-called demand-based transportation vehicle), and may be, for example, a shared taxi or a robot taxi. For example, the service vehicle V may be an autonomous vehicle that is automatically driven by the controller 24 according to route information transmitted from the server device S without the involvement of a driver. When the service vehicle V receives trip plan information from the server device S, it drives to the boarding location so as to arrive by the boarding date and time included in the trip plan information. When the user U boards the service vehicle V at the boarding location, it drives to the drop-off location included in the trip plan information. In the following description, a case will be described in which the service vehicle V is an autonomous vehicle, but the present invention is not limited to this, and the service vehicle V may also be a manually driven vehicle driven by a driver (human). In this case, the service vehicle V may present the route information transmitted from the server device S to the driver to assist the driver in driving the service vehicle V according to the route information.
[0016] The service vehicle V1 includes a sensor 20, a positioning device 21, a map database (map DB) 22, a communication device 23, a controller 24, and an actuator 25. The service vehicles V2... have the same configuration as the service vehicle V1. The sensor 20 includes an object sensor that detects objects around the service vehicle V and a vehicle sensor that detects various information (vehicle status) obtained from the service vehicle V. For example, the object sensor may include a distance measuring device such as a laser range finder (LRF), radar, or LiDAR (Light Detection and Ranging) laser radar. The object sensor outputs surrounding environment information, which is information about the detected surrounding environment of the service vehicle V, to the controller 24. For example, the vehicle sensor may include a vehicle speed sensor, a wheel speed sensor, a three-axis acceleration sensor, a steering angle sensor, a gyro sensor, and a yaw rate sensor. The vehicle sensor outputs vehicle status information regarding the vehicle status of the service vehicle V to the controller 24.
[0017] The positioning device 21 measures the current position and attitude of the service vehicle V. The positioning device 21 may include, for example, a GNSS receiver. The GNSS receiver may be, for example, a GPS receiver. The positioning device 21 outputs current position information of the measured current position to the controller 24. The map DB 22 stores map information. The map information may include map data for navigation and high-precision map data suitable as a map for autonomous driving. The communication device 23 provides a communication function between the service vehicle V and the server device S.
[0018] The controller 24 is an electronic control unit that controls the service vehicle V. For example, the controller 24 controls the autonomous driving of the service vehicle V. The controller 24 includes a processor 26 and peripheral components such as a storage device 27. The processor 26 may be, for example, a CPU or an MPU. The storage device 27 may include non-transitory tangible storage media such as a register, a cache memory, a ROM, or a RAM. The functions of the controller 24 are realized, for example, by the processor 26 executing a computer program stored in the storage device 27.
[0019] The controller 24 executes autonomous driving control to drive the service vehicle V in accordance with the driving plan information based on the surrounding environment information and vehicle state information from the sensor 20, the positioning results of the positioning device 21, and the map information in the map DB 22. For example, the controller 24 calculates a target driving trajectory for driving the service vehicle V based on the current position and attitude of the service vehicle V, the driving route included in the driving plan information, the map information, and the surrounding environment of the service vehicle V. For example, the controller 24 generates a route space map that represents the route around the service vehicle V and the presence or absence of objects, and a risk map that quantifies the risk of the driving area, and generates a target driving trajectory for driving the service vehicle V based on the motion characteristics of the service vehicle V, the vehicle state information, the route space map, and the risk map. The controller 24 drives the actuator 25 so that the service vehicle V drives along the generated target driving trajectory. The actuator 25 operates the steering device, drive device, and brake device of the service vehicle V in response to control signals from the controller 24 to generate vehicle behavior of the service vehicle V, thereby automatically driving the service vehicle V. The actuator 25 includes a steering actuator, an accelerator opening actuator, and a brake control actuator.
[0020] FIG. 2 is a sequence diagram of an example of processing in the vehicle dispatch service providing system 1. In step S1, the terminal device T2 accepts a login operation by the user U2. In step S2, the terminal device T2 transmits identification information of the user U2 to the server device S. In step S3, the server device S authenticates the user U2 based on the identification information. In step S4, the terminal device T2 generates reservation information including information on the boarding location, boarding date and time, and disembarking location based on the input operation of the user U2. The terminal device T2 transmits the reservation information to the server device S. In step S5, the server device S arranges for a service vehicle Va to be provided for use by the user U2 based on the reservation information. The server device S also generates driving plan information for the service vehicle Va to transport the user U2 from the boarding location to the disembarking location. For example, the driving plan information may include information on the boarding location and the disembarking location. Furthermore, for example, the driving plan information may include a driving route from the current location of the service vehicle Va to the boarding location and a driving route from the boarding location to the disembarking location. In step S6, the server device S transmits the driving plan information to the service vehicle Va. In step S7, the controller 24 of the service vehicle Va drives the service vehicle Va to the boarding location of the user U2 in accordance with the driving plan information received from the server device S, and when the user U2 gets on the service vehicle Va at the boarding location, the service vehicle Va drives towards the disembarking location.
[0021] In step S8, the terminal device T1 accepts a login operation by the approval-subject user U1. In step S9, the terminal device T1 transmits identification information of the approval-subject user U1 to the server device S. In step S10, the server device S authenticates the approval-subject user U1 based on the identification information. At this time, the server device S determines whether the approval-subject user U1 is a person who requires approval from another user to use the ride-hailing service based on the user information of the approval-subject user U1 registered in the database 11. For example, the database 11 may store information indicating whether the approval-subject user U1 is a person who is approved, in association with the identification information of the approval-subject user U1. In step S11, the terminal device T1 generates reservation information including information on the boarding location, boarding date and time, and disembarking location based on the input operation of the approval-subject user U1. The terminal device T1 transmits the reservation information to the server device S.
[0022] In step S12, the server device S selects a candidate service vehicle V to be used by the approved user U1 based on the reservation information. At this time, the server device S determines whether the selected candidate service vehicle V has already been assigned to another user U other than the approved user U1, and whether a reservation state occurs in which the approved user U1 and the other user U share the same service vehicle V. Here, it is assumed that the service vehicle Va already assigned to user U2 is selected as the candidate service vehicle V to be used by the approved user U1. In this case, the server device S provisionally reserves the service vehicle Va as the service vehicle V to be used by the approved user U1.
[0023] In step S13, the server device S generates a ride-sharing notification including a selection of whether to approve the ride-sharing of the service vehicle Va between the approved user U1 and user U2. The server device S transmits the generated ride-sharing notification to the terminal device Ta of the user Ua. The ride-sharing notification transmitted to the terminal device Ta is an example of a "first notification" described in the claims. The ride-sharing notification may include a message prompting the approver user Ua to select whether to approve the ride-sharing of the service vehicle Va between the approved user U1 and user U2. The ride-sharing notification may include alternative information that serves as an indicator of the trustworthiness of user U2 as a substitute for user U2's direct personal information. The approver user Ua can determine whether to approve the ride-sharing of the approved user U1 and user U2 based on the alternative information of user U2. In step S14, the terminal device Ta presents the ride-sharing notification received from the server device S to the approver user Ua by outputting it to the HMI 31. For example, the terminal device Ta displays a ride-sharing notification on the display device of the HMI 31. The terminal device Ta accepts an operation by the approver user Ua to approve or disapprove the ride-sharing between the approved user U1 and user U2. In step S15, the terminal device Ta transmits a response notification to the server device S notifying the approver user Ua of the approval or disapproval of the ride-sharing. Here, it is assumed that the approver user Ua does not approve the ride-sharing.
[0024] In step S16, the server device S searches for a service vehicle Vb other than the service vehicle Va and arranges it as a service vehicle V for use by the approved user U1. The server device S generates driving plan information for the service vehicle Vb to transport the approved user U1 from the boarding location to the disembarking location. In step S17, the server device S transmits the driving plan information to the service vehicle Vb. In step S18, the controller 24 of the service vehicle Vb drives the service vehicle Vb in accordance with the driving plan information received from the server device S to transport the approved user U1 from the boarding location to the disembarking location. In step S19, the server device S transmits a result notification to the terminal device T1 informing the approved user U1 of the vehicle allocation result (e.g., that the service vehicle Vb has been allocated and the estimated time of arrival at the boarding location). In step S20, the terminal device T1 presents the vehicle allocation result to the approved user U1.
[0025] On the other hand, if the approver user Ua approves the ride-sharing in step S14, the server device S corrects the dispatch plan of the service vehicle Va so that the approver user Ua and user U2 will ride-sharing. Specifically, the server device S corrects the driving plan information so that the service vehicle Va will drive to the boarding location of the approved user U1 to pick up the approved user U1 and then transport the approved user U1 and user U2 to the disembarking location, and resends the corrected driving plan information to the service vehicle Va.
[0026] While the above example describes a case where user U1 is an approved user, both user U1 and user U2 may be approved users. For example, user U2 may be an approved user who requires approval from approver user Ub to use a ride-hailing service. In this case, the server device S may also send a ride-sharing notification to the terminal device Tb of the approver user Ub, including a choice of whether to approve the approved users U1 and U2 sharing a service vehicle Va. The ride-sharing notification sent to the terminal device Tb may include alternative information that indicates the trustworthiness of the approved user U1. The ride-sharing notification sent to the terminal device Tb is an example of a "second notification" described in the claims. If both approver users Ua and Ub approve the ride-sharing, the server device S may arrange for the approved users U1 and U2 to share the same service vehicle Va. For example, the server device S may correct the driving plan information for the service vehicle Va so that the approved users U1 and U2 share a ride. On the other hand, if at least one of the approver users Ua and Ub does not approve the ride-sharing, the same service vehicle Va will not be arranged for the approved users U1 and U2. For example, a service vehicle Vb other than the service vehicle Va arranged for the approved user U2 may be arranged for the approved user U1.
[0027] In the above example, the timing of provisionally reserving a service vehicle Va for the approved user U1 (or transmitting a ride-sharing notification to the terminal device Ta) was described as occurring after user U2 boarded the service vehicle Va. However, this embodiment is not limited to this example. For example, the timing of provisionally reserving a service vehicle Va (or transmitting a ride-sharing notification) may occur after the service vehicle Va is arranged for user U2 and before user U2 boards the service vehicle Va. Furthermore, when reserving the service vehicle Va, the approved user U1 may input the name of user U2 who will board the service vehicle Va at the same time as the approved user U1 into the terminal device T1. FIG. 3 illustrates an example of a passenger input screen displayed on the terminal device T1 for entering passengers when creating reservation information for a ride-hailing service. For example, the passenger input screen 40 may include a passenger candidate list 40a, a passenger selection check box 40b, and a confirmation button 40c.
[0028] When the approval-request user U1 checks the checkbox for user U2 who will be riding with them and presses the OK button 40c, the terminal device T1 transmits reservation information including the selected user U2 as a passenger to the server device S. The server device S transmits a ride-sharing notification to the terminal device Ta of the approver user Ua, including a selection of whether to approve the ride-sharing between the approval-request user U1 and user U2 in the service vehicle Va. When the approver user Ua performs an operation on the terminal device Ta to approve the ride-sharing, the server device S dispatches the service vehicle Va with both the approval-request user U1 and user U2 as passengers. When the approver user Ua performs an operation to reject the ride-sharing, the server device S dispatches the service vehicle Va with only the approval-request user U1 as a passenger. The server device S may also transmit a ride-sharing notification to the terminal device Tb of the approver user Ub. In this case, when both approver users Ua and Ub perform an operation to approve the ride-sharing on the terminal device Ta, the server device S dispatches a service vehicle Va with both approved user U1 and user U2 as passengers. When at least one of approver users Ua or Ub performs an operation to reject the ride-sharing, the server device S dispatches a service vehicle Va with only approved user U1 as a passenger.
[0029] Next, we will explain the process by which the approver user Ua selects whether to approve a rideshare between the approved user U1 and user U2. FIGS. 4A and 4B show first and second examples of a rideshare notification screen displayed on the terminal device Ta of the approver user Ua. Upon receiving a rideshare notification from the server S, the terminal device Ta displays a rideshare notification screen 41 on the display device of the HMI 31. The rideshare notification screen 41 may include a user name display field 41a displaying the name of user U2, an icon display 41b for user U2, a rideshare score display field 41c, an approve button 41d, and a reject button 41e. The rideshare score display field 41c displays a rideshare score as alternative information that serves as an indicator of user U2's trustworthiness. For example, the rideshare score may be an evaluation value of user U2 as a user of the ride-hailing service. The server device S may calculate the rideshare score based on user information about user U2 registered in the database 11.
[0030] For example, the server device S may calculate the ride-along score based on the personal information of user U2 registered in the database 11 and the user's past use of the ride-hailing service. For example, the server device S may calculate the ride-along score based on personal information of user U2, such as whether or not the user's identity information is registered in the database 11, whether or not the user U2 has been authenticated by a third-party organization such as a school, and whether or not the user U2 has a criminal record. For example, the server device S may deduct points from the ride-along score when the user's identity information is not registered compared to when the user's identity information is registered. For example, the server device S may deduct points from the ride-along score when the user U2 has a criminal record compared to when the user U2 does not have a criminal record. For example, the ride-along score may be calculated based on whether or not the user U2's parent / guardian is connected to other parents in a parent / teacher association (PTA) or other organization, as certified by a third party (such as a school), and whether or not the parent / guardian is entered into the administrative agency's system based on an application from a third party (such as a school). For example, if user U2 has not been authenticated by a third-party organization, the server device S may prohibit the approved user U1 and user U2 from sharing the ride without sending a ride-sharing notification to the terminal device Ta of the approver user Ua.
[0031] For example, the administrator of the vehicle dispatch service system 1 may register a blacklist of vehicle dispatch service users in the database 11. For example, the vehicle dispatch service system 1 may register the blacklist based on criminal history data registered by a government agency or the like. For example, the approver user Ua of the approved user U1 may register a blacklist to restrict ridesharing with the approved user U1. See FIG. 5 . For example, when the approver user Ua touches (or clicks) the icon 41b of user U2 on the ridesharing notification screen 41, the terminal device Ta may display a blacklist setting pop-up screen 41g. When the approver user Ua presses the OK button, the server device S may register user U2 ("Hanako-chan" in the example of FIG. 5 ) on the blacklist. For example, when the approver user Ua does not approve the ridesharing between the approved user U1 and user U2 on the ridesharing notification screen 41 (for example, when the reject button 41e is not pressed), the server device S may register user U2 on the blacklist.
[0032] For example, the server device S may calculate the ride-sharing score based on whether or not user U2 is on the blacklist. Alternatively, if user U2 is on the blacklist, the server device S may prohibit the approved user U1 and user U2 from riding together without sending a ride-sharing notification to the terminal device Ta of the approver user Ua. Furthermore, for example, the server device S may send a ride-sharing notification to the terminal device Ta that includes information indicating whether user U2 is on the blacklist. If user U2 is on the blacklist, the terminal device Ta may display a warning on the ride-sharing notification screen 41.
[0033] For example, the server device S may calculate the ride-along score for user U2 based on review scores from other users who have previously shared a ride with user U2 as part of user U2's usage history. For example, the server device S may calculate the ride-along score based on user U2's past usage conditions (e.g., locational conditions such as travel route and boarding / disembarking locations, and time conditions such as time of day and day of the week) as part of user U2's usage history. For example, the server device S may calculate the ride-along score based on the usage conditions under which user U2 regularly uses the ride-along service. For example, if there is a large difference between user U2's current usage conditions for the ride-along service (i.e., the usage conditions under which user U2 regularly uses the ride-along service when a reservation for a ride-along between approved user U1 and user U2 occurs) and the user U2's past daily usage conditions, the server device S may deduct points from the ride-along score more than if the difference is small.
[0034] For example, the server device S may calculate a ride-sharing score as a weighted sum of user U2's personal information and usage history. For example, the terminal device Ta may display user U2's review scores 41f from other users separately from the ride-sharing score 41c, as shown on the ride-sharing notification screen 41 in FIG. 4(b). In this case, the server device S may calculate user U2's ride-sharing score based on usage history and personal information other than the review scores. The approver user Ua determines whether to approve the ride-sharing between the approved user U1 and user U2 based on the ride-sharing score 41c and review score 41f. The terminal device Ta accepts the approver user Ua's operation of pressing the approve button 41d as an operation to approve the ride-sharing. It also accepts the operation of pressing the reject button 41e as an operation to not approve the ride-sharing.
[0035] If neither the approval button 41d nor the rejection button 41e is operated even after a predetermined time has elapsed since the terminal device Ta started displaying the ride-sharing notification screen 41, the server device S may dispatch a service vehicle Va to the approver user Ua so that the approver user Ua and user U2 can ride together, even if the terminal device Ta does not accept the approver user Ua's approval operation. User U2 may set ride-sharing permission conditions that allow user U2 to ride-sharing with other users when reserving the ride-sharing service, or may register the conditions as user information of user U2 in the database 11. If neither the approval button 41d nor the rejection button 41e is operated even after a predetermined time has elapsed since the terminal device Ta started displaying the ride-sharing notification screen 41, and user U2 permits ride-sharing, the server device S may dispatch a service vehicle Va to the approver user Ua so that the approver user Ua and user U2 can ride-sharing.
[0036] (Operation) FIG. 6 is a flowchart of an example of an information processing method according to the first embodiment. In step S30, the user U1 to be approved inputs reservation information into the terminal device T1. The terminal device T1 transmits the reservation information to the server device S. In step S31, the server device S arranges for a service vehicle Va to be used by the user U1 to be approved. In step S32, the server device S determines whether the service vehicle Va has already been allocated to another user U2 and whether a reservation has been made for the user U1 to share the service vehicle Va with the user U2. If a reservation for sharing a ride has not been made (step S32: N), the process proceeds to step S41. If a reservation for sharing a ride has been made (step S32: Y), the process proceeds to step S33.
[0037] In step S33, the server device S provisionally reserves a service vehicle Va as a service vehicle V to be provided for use by the approved user U1. In step S34, the server device S determines whether the user U1 is an approved user. If the user U1 is not an approved user (step S34: N), the process proceeds to step S41. If the user U1 is an approved user (step S34: Y), the process proceeds to step S35. In step S35, the server device S extracts the user information of the user U2 from the database 11. In step S36, the server device S calculates the riding score of the user U2 based on the user information of the user U2. In step S37, the server device S transmits a ride-sharing notification including the riding score to the terminal device Ta of the approver user Ua. The terminal device Ta presents a ride-sharing notification screen 41 to the approver user Ua.
[0038] In step S38, the terminal device Ta accepts an operation by the approver user Ua to approve or reject the ride-sharing between the approved user U1 and user U2. If an operation to reject approval is accepted (step S38: N), the process proceeds to step S39. If an operation to approve is accepted (step S38: Y), the process proceeds to step S40. In step S39, the server device S searches for a service vehicle V other than the service vehicle Va and arranges for a candidate service vehicle V to be provided for use by the approved user U1. The process then returns to step S32.
[0039] In step S40, the server device S corrects the dispatch plan of the service vehicle Va so that the service vehicle Va will drive to the boarding location of the approved user U1 to pick up the approved user U1 and then transport the approved user U1 and user U2 to the drop-off location. In step S41, the terminal device T1 presents the dispatch result to the approved user U1. Then, the process ends.
[0040] Second Embodiment In the second embodiment of the vehicle dispatch service providing system 1, the approver user Ua pre-sets approval conditions for approving a rideshare between the approved user U1 and another user in a service vehicle Va and registers the conditions in the database 11. For example, the approver user Ua may set a minimum rideshare score, which is the lower limit of the rideshare scores of other users who are approved to rideshare with the approved user U1, as an approval condition. FIG. 7A is a diagram illustrating an example of a rideshare setting screen on which the terminal device Ta accepts the approval user Ua's input of the approval conditions. The rideshare setting screen 42 may include a minimum rideshare score input field 42a for inputting the minimum rideshare score, a blacklist display field 42b for displaying other users included in a blacklist, a cancel button 42c, and an OK button 42d.
[0041] The approver user Ua enters the minimum ride-along score in the minimum ride-along score input field 42a and presses the OK button 42d. The terminal device Ta transmits the entered minimum ride-along score to the server device S. The server device S registers the received minimum ride-along score in the database 11 as an approval condition. The server device S determines that user U2 meets the approval condition if user U2's ride-along score is equal to or greater than the minimum ride-along score, and determines that user U2 does not meet the approval condition if user U2's ride-along score is less than the minimum ride-along score. Note that when the ride-along score and review score are displayed separately, as in the ride-along notification screen 41 of FIG. 4(b), the approver user Ua may set both the minimum ride-along score and the minimum review score as approval conditions. In this case, the server device S may determine that user U2 meets the approval conditions if user U2's passenger score is equal to or greater than the minimum passenger score and the review score is equal to or greater than the minimum review score, and may determine that user U2 does not meet the approval conditions if user U2's passenger score is less than the minimum passenger score or the review score is less than the minimum review score.
[0042] If user U2 satisfies the approval conditions, the server device S automatically permits the approved user U1 and user U2 to share a service vehicle Va without obtaining approval from the approver user Ua (i.e., regardless of whether approval is granted). Specifically, the server device S dispatches a service vehicle Va to the approved user U1 so that the approved user U1 and user U2 can share a ride. In this case, the server device S may present the approver user Ua with a ride-sharing notification that omits the option to approve the ride-sharing between the approved user U1 and user U2. FIG. 7B illustrates an example of a ride-sharing notification screen in which the option to approve the ride-sharing between the approved user U1 and user U2 is omitted. Compared to the ride-sharing notification screen 41 in FIG. 4A, the ride-sharing notification screen 41 in FIG. 7B omits the approval button 41d for approving the ride-sharing and the rejection button 41e for rejecting the ride-sharing. Instead, a "close" button 41h for closing the ride-sharing notification screen 41 is provided. This eliminates the need for the approver user Ua to select whether or not to approve the ride-sharing between the approved user U1 and user U2, and the ride-sharing notification screen 41 is displayed to notify the approver user Ua that the approved user U1 and user U2 will be riding together.
[0043] If user U2 does not satisfy the approval conditions, the server device S transmits a ride-sharing notification similar to that in the first embodiment to the terminal device Ta of the approver user Ua. In this case, the terminal device Ta presents the ride-sharing notification screen 41 shown in FIG. 4(a) or 4(b) to the approver user Ua, and accepts an operation to approve or disapprove the ride-sharing. FIG. 8 is a flowchart of an example of an information processing method according to the second embodiment. The processing in steps S50 to S56 is the same as the processing in steps S30 to S36 in FIG. 6.
[0044] In step S57, the server device S determines whether user U2 satisfies the approval conditions. If user U2 does not satisfy the approval conditions (step S57: N), the process proceeds to step S59. If user U2 satisfies the approval conditions (step S57: Y), the process proceeds to step S58. In step S58, the server device S automatically approves the approval-request user U1 and user U2 to share the service vehicle Va. In addition, the server device S transmits a ride-sharing notification to the terminal device Ta of the approver user Ua, which omits the selection of whether to approve the ride-sharing with the approval-request user U1 and user U2. The terminal device Ta displays a ride-sharing notification screen 41 (see FIG. 7(b)) which omits the selection operation of whether to approve the ride-sharing. Then, the process proceeds to step S62. The processes of steps S59 to S63 are the same as the processes of steps S37 to S41 of FIG. 6.
[0045] (Effects of the Embodiment) (1) The information processing device includes a controller that executes the following processes: identifying a user who uses a service vehicle provided for a vehicle dispatch service; determining whether the identified user is an approved user who requires approval from an approver user other than the identified user to use the vehicle dispatch service; and presenting a first notification to the approver user of the first user, who is the approved user, of the first and second users, including a choice as to whether to approve the first user and the second user sharing the service vehicle. This allows the approver user of the first user to restrict the first user from sharing the service vehicle with unintended other users. As a result, safety can be improved when the approved user uses the vehicle dispatch service. Furthermore, this can foster a sense of security for users regarding the vehicle dispatch service.
[0046] (2) The controller may execute a process to present a second notification to the approver user of the second user, who is the approved user, including a choice as to whether to approve the ride-sharing. This allows the approver user of the second user to restrict the second user from sharing a service vehicle with unintended other users. (3) If both the approver user of the first user and the approver user of the second user approve the ride-sharing, the controller may arrange the same service vehicle for the first user and the second user. If at least one of the approver user of the first user and the approver user of the second user does not approve the ride-sharing, the controller may not arrange the same service vehicle for the first user and the second user. This allows restricting ride-sharing that is not agreed to by either the approver user of the first user or the approver user of the second user.
[0047] (4) The controller may determine whether the second user satisfies a first predetermined condition that proves the identity of the second user, and may determine whether to execute a process to present a first notification to the approver user of the first user, depending on whether the second user satisfies the first predetermined condition. For example, the first predetermined condition may include authentication of the second user by a third party. This allows automatic restriction of ridesharing without notifying the approver user of the first user if the second user does not satisfy the first predetermined condition. (5) The first notification may include a score based on the second user's past use of the ride-hailing service. This allows for the provision of criteria for determining whether to approve a ride between the first user and the second user without disclosing the second user's personal information.
[0048] (6) The controller may determine a score based on a comparison between the second user's current conditions for using the ride-hailing service and the second user's past conditions for using the ride-hailing service. This allows the approver user of the first user to be alerted if the second user's current use of the ride-hailing service, who is scheduled to ride-share with the first user, is unusual. (7) If the second user satisfies a second predetermined condition set in advance by the approver user of the first user, the controller may present the approver user of the first user with a first notification that omits the option of whether to approve the ride-hailing. This allows the approver user to omit the approval operation when the second user satisfies the second predetermined condition.
[0049] All examples and conditional terms described herein are intended for educational purposes to aid the reader in understanding the present invention and the concepts provided by the inventor for the advancement of technology, and should be construed without limitation to the specifically described examples and conditions above, and the configuration of examples herein for illustrating the advantages and disadvantages of the present invention. Although the embodiments of the present invention have been described in detail, it should be understood that various changes, substitutions, and alterations can be made thereto without departing from the spirit and scope of the present invention.
[0050] 1...Vehicle dispatch service providing system 1, 10, 23, 30...Communication device, 11...Database, 12, 24, 32...Controller, 13, 26, 33...Processor, 14, 27, 34...Storage device, 20...Sensor, 21...Positioning device, 22...Map database, 25...Actuator, 31...Human-machine interface, S...Server device, T1, T2, Ta, Tb...Terminal device, U1, U2...Approved user, Ua, Ub...Approving user, Va, Vb...Service vehicle
Claims
1. An information processing device comprising a controller that executes the following processes: a process of identifying a user who will use a service vehicle provided for a vehicle dispatch service; a process of determining whether the identified user is an approved user who requires approval from an approver user who is a user other than the identified user for using the vehicle dispatch service; and a process of presenting a first notification to the approver user of the first user, who is the approved user, of the users, a first user and a second user, including a choice as to whether to approve the first user and the second user sharing the service vehicle.
2. The information processing device according to claim 1, characterized in that the controller executes a process of presenting a second notification to the approver user of the second user who is the approved user, the second notification including a choice as to whether or not to approve the ride-sharing.
3. The information processing device described in claim 2, characterized in that if both the approver user of the first user and the approver user of the second user approve the carpooling, the same service vehicle is arranged for the first user and the second user, and if at least one of the approver user of the first user and the approver user of the second user does not approve the carpooling, arranging the same service vehicle for the first user and the second user is prohibited.
4. An information processing device as described in any one of claims 1 to 3, characterized in that the controller determines whether the second user satisfies a first predetermined condition that proves the identity of the second user, and determines whether to execute a process to present the first notification to the approver user of the first user depending on whether the second user satisfies the first predetermined condition.
5. The information processing device according to claim 4, wherein the first predetermined condition includes authentication of the second user by a third party.
6. An information processing device according to any one of claims 1 to 5, characterized in that the first notification includes a score based on the second user's past usage of the ride-hailing service.
7. The information processing device described in claim 6, characterized in that the controller determines the score based on the results of comparing the current conditions of use of the ride-hailing service by the second user with the past conditions of use of the ride-hailing service by the second user.
8. An information processing device as described in any one of claims 1 to 7, characterized in that, when the second user satisfies a second predetermined condition previously set by the approver user of the first user, the controller presents the first notification to the approver user of the first user, omitting the option of whether to approve the ride-sharing.
9. An information processing method characterized by having a controller perform the following processes: identifying a user who will use a service vehicle provided for a ride-hailing service; determining whether the identified user is an approved user who requires approval from an approver user who is a user other than the identified user to use the ride-hailing service; and presenting a first notification to the approver user of the first user, who is the approved user, of the first and second users, which includes a choice as to whether to approve the first user and the second user sharing the service vehicle.
Citation Information
Patent Citations
Vehicle allocation system and vehicle allocation method
JP2019220068A
Vehicle management device and program
JP2021149528A
Ride-sharing allocation device, elevator system, and ride-sharing allocation method
JP2023173031A