Information processing device and information processing method

Abstract

An information processing device according to the present invention for providing vehicle dispatch service comprises: a registration unit configured to register a user subject to approval who needs approval from a registered approver user; a display unit configured to display, on an approver terminal of the approver user, an action plan including a registered destination of the user subject to approval; an authority setting unit configured to set an authority for a third-party user to at least partially view and edit the action plan; and a vehicle dispatch unit configured to receive a vehicle dispatch request for the user subject to approval to receive the vehicle dispatch service in response to a request from a third-party terminal of the third-party user with the authority set.

Description

Information Processing Apparatus and Information Processing Method

[0001] The present invention relates to an information processing apparatus and an information processing method.

[0002] Patent Document 1 describes a vehicle monitoring system that enables a guardian to confirm the riding state of a person under guardianship in real time.

[0003] Japanese Patent Application Laid-Open No. 2022-069033

[0004] By the way, when a person under guardianship such as a child uses a dispatch service such as a taxi, it is common for the guardian or the child to perform the dispatch procedure using a terminal such as a smartphone. However, for example, when the child does not have a terminal, there is a problem that a dispatch cannot be made. In addition, since the guardian may not be able to accurately grasp the situation of the child away from home, even if the guardian makes a dispatch, for example, if the child's schedule deviates from the scheduled boarding time, there is a possibility that the dispatch service cannot be received.

[0005] The present invention has been made to solve the above problems, and an object thereof is to provide an information processing apparatus and an information processing method for enabling a person under guardianship to appropriately receive a dispatch service.

[0006] The information processing apparatus according to the present invention is an information processing apparatus for providing a dispatch service, and includes a registration unit configured to register an approved user who requires approval of a registered approver user, and an approver terminal of the approver user. A display unit configured to display an action plan including the registered destination of the approved user, and a third-party user, and a permission setting unit configured to set at least part of the permission to view and edit the action plan, and the third-party user for whom the permission is set. And a dispatch unit configured to receive a dispatch request for the approved user to receive the dispatch service in response to a request from a third-party terminal of the user.

[0007] The information processing method according to the present invention is an information processing method performed by an information processing device for providing a ride-hailing service, comprising: a process for registering an approved user whose approval is required by a registered approver user; a process for displaying an action plan including the registered destination of the approved user on the approver's terminal of the approver user; a process for setting up a third-party user with the authority to view and edit at least part of the action plan; and a process for receiving a ride-hailing request from the third-party terminal of the third-party user who has been granted the authority, for the approved user to receive the ride-hailing service.

[0008] According to the present invention, the person being monitored can appropriately receive the ride-hailing service.

[0009] This is a schematic diagram of an example of a dispatch service provision system that includes the information processing device (server device) of the present invention. This is a block diagram of the hardware configuration of the terminal to be approved. This is a block diagram of the hardware configuration of the approval terminal. This is a block diagram of the hardware configuration of the server device. This is a block diagram of the hardware configuration of the service vehicle. This is a block diagram of the software configuration of the server device. This is a diagram showing an example of the screen of the approver terminal. This is a diagram showing an example of the screen of the approver terminal. This is a diagram showing an example of the screen of the approver terminal. This is a diagram showing an example of the screen of the approver terminal. This is a diagram showing an example of the screen of the approver terminal. This is a diagram showing an example of the screen of the approver terminal. This is a diagram showing an example of the screen of the approver terminal. This is a diagram showing an example of the screen of the approver terminal. This is a diagram showing an example of the screen of the approver terminal. This is a diagram showing an example of the screen of the approver terminal. This is a diagram showing an example of the screen of the approver terminal. This is a diagram showing an example of the screen of the approver terminal. This is a diagram showing an example of the screen of the approver terminal. There is a diagram showing an example of the screen on an approver's terminal. There is a diagram showing an example of the screen on a third-party terminal. This is a flowchart showing the processing by the dispatch department.

[0010] Hereinafter, an embodiment of a dispatch service system including an information processing device (server device) according to the present invention will be described with reference to the drawings.

[0011] <1. Overview of the Ride-Hailing Service System> Figure 1 is a schematic diagram of an example of the ride-hailing service provision system of this embodiment. As shown in Figure 1, this ride-hailing service provision system 1 is a system that provides a ride-hailing service (passenger transportation service) by operating a vehicle 3 to move users. In this specification, the vehicle 3 used for the ride-hailing service by the ride-hailing service provision system is referred to as a "service vehicle," and the ride-hailing service provided by the ride-hailing service provision system 1 is simply referred to as a "ride-hailing service." The ride-hailing service provision system 1 comprises a server device 2, a service vehicle 3, a ride-hailing server device 4, a terminal for approved users 5, a terminal for approvers 6, and a terminal for third parties 7, which are wirelessly connected via a network such as the Internet.

[0012] Terminal 5 for approved users, terminal 6 for approvers, and terminal 7 for third parties are terminal devices operated by users U1, U2, and U3, respectively, who use the ride-hailing service. These terminals 5 to 7 have dedicated application software (hereinafter sometimes referred to as "ride-hailing software") installed for using the ride-hailing service.

[0013] Here, User U1 is a user who requires approval from User U2 to use the ride-hailing service. User U3 is a third party to Users U1 and U2. In the following explanation, User U1 may be referred to as "Approved User U1," User U2 as "Approver User U2," and User U3 as "Third-Party User U3." For example, Approved User U1 may be a minor under a certain age (e.g., a child) or a person requiring supervision, such as an elderly person. Approver User U2 may be a guardian or legal representative of Approved User U1, including their parents. Third-Party User U3 may be at least one of the following: the organizer of an event at Approved User U1's destination, the manager of a facility at Approved User U1's destination, or someone related to the school Approved User U1 attends (e.g., a teacher or administrator). In addition to the above, a proxy approver User U4 may be set up as needed. The proxy approver user U4 may be, for example, another guardian of approved user U1 who may be acting together with approved user U1 (for example, a friend of approver user U2). In the following explanation, users of the ride-hailing service, including users U1, U2, U3, and U4, may be collectively referred to as "User U". Note that "event" includes, for example, extracurricular activities that approved user U1 attends.

[0014] <2. Terminal for Approved Users> The terminal for approved users 5 is, for example, a portable information terminal (smartphone, etc.) that approved user U1 can carry, or a small, easily portable computer. If approved user U1 does not own such a terminal device, it may be a terminal device (e.g., a tablet device or small computer) located at a facility used by approved user U1 (e.g., a public facility). Approved user U1 can reserve a ride-hailing service using the ride-hailing software running on the terminal for approved users 5.

[0015] As shown in Figure 2, the terminal 5 for the approved person comprises a communication device 50, a human-machine interface (HMI) 51, and a controller 52.

[0016] The communication device 50 provides communication functionality between the authorized user terminal 5 and the server device 2. The HMI 51 is an interface device that exchanges information between the authorized user terminal 5 and the authorized user U1. The HMI 51 is equipped with a display device visible to the authorized user U1, as well as a speaker and buzzer that output auditory information. The HMI 51 is also equipped with controls (e.g., buttons, switches, levers, dials, keyboards, touch panels, etc.) and an audio input device that accepts operation input from the authorized user U1 to the authorized user terminal 5.

[0017] The controller 52 is an electronic control unit (ECU) that controls the operation of the authorized user terminal 5. The controller 52 includes a processor 53 and peripheral components such as a storage device 54. The processor 53 may be, for example, a CPU (Central Processing Unit) or an MPU (Micro-Processing Unit). The storage device 54 may include registers, cache memory, and non-temporary tangible storage media such as ROM (Read Only Memory) and RAM (Random Access Memory). The functions of the authorized user terminal 5 described below are realized, for example, by the processor 53 executing a computer program stored in the storage device 54. That is, by executing the program, applications that perform the processing described later or display the screens described later are launched.

[0018] <3. Approver Terminal and Third-Party Terminal> The approver terminal 6 is, for example, a portable information terminal (smartphone, etc.) that approver user U2 can carry, or a small, easily portable computer. Approver user U2 reserves the ride-hailing service using the ride-hailing software running on the approver terminal 6. Approver user U2 also approves the locations where approved user U1 can use the ride-hailing service using the ride-hailing software running on the approver terminal 6.

[0019] The following description assumes that the location where the approved user U1 uses the ride-hailing service is the boarding and alighting point where the approved user U1 gets on and off the service vehicle 3. However, the location of use of the ride-hailing service in this invention is not limited to boarding and alighting points. The location of use of the ride-hailing service in this invention includes the travel route (linear space) in which the approved user U1 travels in the service vehicle 3, and the travel area (linear space) in which the approved user U1 travels in the service vehicle 3.

[0020] As shown in Figure 3, the approver terminal 6 comprises a positioning device 60, a communication device 61, an HMI 62, and a controller 63.

[0021] The positioning device 60 measures the current location of the approver terminal 6 (i.e., the current location of the approver user U2). The positioning device 60 may include, for example, a Global Positioning System (GNSS) receiver. The GNSS receiver may be, for example, a GPS receiver.

[0022] The communication device 61 provides communication functionality between the approver terminal 6 and the server device 2. The HMI 62 is an interface device that exchanges information between the approver terminal 6 and the approver user U2. The HMI 62 is equipped with a display device visible to the approver user U2, as well as a speaker and buzzer that output auditory information.

[0023] HMI62 is equipped with controls and a voice input device that accept operation input from approver user U2 to approver terminal 6.

[0024] The controller 63 is an ECU that controls the operation of the approver terminal 6. The controller 63 includes a processor 64 and peripheral components such as a storage device 65. The processor 64 may be, for example, a CPU or an MPU. The storage device 65 may include registers, cache memory, and non-temporary tangible storage media such as ROM or RAM. The functions of the approver terminal 6, which will be described later, are realized, for example, by the processor 64 executing a computer program stored in the storage device 65. That is, by executing the program, an application is launched that performs the processing described later or displays the various screens described later.

[0025] The third-party terminal 7 can have the same configuration as the approver terminal 6. Furthermore, the proxy approver terminal 8 owned by proxy approver user U4 can also have the same configuration as the approver terminal 6.

[0026] <4. Server Device> Server device 2 is an information processing device that receives reservation information from the terminal 5 for approved users and the terminal 6 for approvers, and arranges a service vehicle 3 for use by user U according to the reservation information. Furthermore, as will be described later, server device 2 also has functions for various registrations and setting predetermined permissions for third-party users U3. Server device 2 is an example of the "information processing device" of the present invention. As shown in Figure 4, server device 2 comprises a communication device 20, a database 21, and a controller 22.

[0027] The communication device 20 provides communication functions between the server device 2, the service vehicle 3, the dispatch server device 4, the terminal for approved persons 5, the terminal for approvers 6, the terminal for third parties 7, and the terminal for proxy approvers 8.

[0028] Database 21 is composed of auxiliary storage devices such as HDDs and SSDs. Database 21 stores various information used for providing the ride-hailing service. For example, Database 21 stores the action plan of approved user U1, event information, information about user U of the ride-hailing service, a map database of the service area where the ride-hailing service provision system 1 provides the ride-hailing service, information about pick-up and drop-off locations where user U can get on and off the service vehicle 3, and information about events held within the service area. The action plan of approved user U1 includes information about events that approved user U1 will participate in (event venue, event organizer, event date and time, event content, etc.), information about specific destinations registered other than events (frequently used destinations described later) (destination, date and time, etc.), and information about registered ride-hailing services (date and time of dispatch, pick-up and drop-off locations, etc.). This information is associated with a calendar for each approved user U1 and stored in Database 21. Event information refers to information about events held in the area where this ride-hailing service is provided. Events are organized by the organizers or venues registered with this ride-hailing service, and are updated sequentially, for example, by the administrator of server device 2.

[0029] The controller 22 includes a processor 23 and peripheral components such as a storage device 24. The processor 23 may be, for example, a CPU or an MPU. The storage device 24 may include registers, cache memory, and non-temporary tangible storage media such as ROM or RAM. The functions of the server device 2 described below are realized, for example, by the processor 23 executing a computer program stored in the storage device 24.

[0030] <5. Service Vehicles> Service vehicle 3 is a vehicle that operates in response to the request of user U (a so-called on-demand transport vehicle), and may be, for example, a shared taxi or a robot taxi. For example, service vehicle 3 may be an autonomous vehicle that is driven automatically by a controller 36 according to dispatch information (pickup and drop-off locations, pickup and drop-off times, passengers, etc.) transmitted from server device 2 or dispatch server device 4 without the involvement of a driver. When service vehicle 3 receives dispatch information from server device 2 via dispatch server device 4, it travels to the pickup location so as to arrive by the pickup date and time included in the dispatch information. When user U boards service vehicle 3 at the pickup location, it travels to the drop-off location included in the dispatch information.

[0031] The following description will focus on the case where the service vehicle 3 is an autonomous vehicle, but the present invention is not limited to this, and the service vehicle 3 may be a manually driven vehicle operated by a human driver. In this case, the service vehicle 3 may assist the driver in driving the service vehicle 3 according to the route information by presenting the dispatch information transmitted from the dispatch server device 4 to the driver.

[0032] As shown in Figure 5, the service vehicle 3 includes a sensor 30, a positioning device 31, a map database (map DB) 32, a communication device 33, a controller 36, and an actuator 37. The sensor 30 includes an object sensor that detects objects around the service vehicle 3 and a vehicle sensor that detects various information (vehicle status) obtained from the service vehicle 3. For example, the object sensor may include a distance measuring device such as a laser rangefinder (LRF), radar, or a LiDAR (Light Detection and Ranging) laser radar. The object sensor outputs ambient environment information, which is information about the surrounding environment of the service vehicle 3 that it has detected, to the controller 36. 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 3 to the controller 36.

[0033] The positioning device 31 measures the current position and attitude of the service vehicle 3. The positioning device 31 may include, for example, a GNSS receiver. The GNSS receiver may be, for example, a GPS receiver. The positioning device 31 outputs the measured current position information to the controller 36. The map DB 32 stores map information. The map information may include map data for navigation and high-precision map data suitable for autonomous driving. The communication device 33 provides communication functionality between the service vehicle 3 and the server device 2.

[0034] The controller 36 is an electronic control unit that controls the service vehicle 3. For example, the controller 36 performs autonomous driving control of the service vehicle 3. The controller 36 includes a processor 38 and peripheral components such as a storage device 39. The processor 38 may be, for example, a CPU or an MPU. The storage device 39 may include registers, cache memory, or tangible storage media that are not temporary, such as ROM or RAM. The functions of the controller 36 are realized, for example, by the processor 38 executing a computer program stored in the storage device 39.

[0035] The controller 36 performs autonomous driving control to drive the service vehicle 3 according to a driving plan based on ambient environment information and vehicle status information from the sensor 30, positioning results from the positioning device 31, and map information from the map DB 32. For example, the controller 36 calculates a target driving trajectory for the service vehicle 3 based on the current position and attitude of the service vehicle 3, the driving route included in the driving plan, the map information, and the surrounding environment of the service vehicle 3. For example, it generates a path space map that represents the paths and presence or absence of objects around the service vehicle 3, and a risk map that quantifies the degree of danger of the driving area, and generates a target driving trajectory for the service vehicle 3 based on the motion characteristics of the service vehicle 3, vehicle status information, path space map, and risk map. The controller 36 drives the actuator 37 so that the service vehicle 3 travels along the generated target driving trajectory.

[0036] The actuator 37 automatically drives the service vehicle 3 by operating the steering system, drive system, and braking system of the service vehicle 3 in response to control signals from the controller 36, thereby generating vehicle behavior for the service vehicle 3. The actuator 37 comprises a steering actuator, an accelerator opening actuator, and a brake control actuator.

[0037] Furthermore, when the service vehicle 3 detects that the approved user U1 has boarded or alighted, it transmits this as boarding / alighting information to the dispatch server device 4. The dispatch server device 4 transmits the boarding / alighting information to the server device 2. The server device 2 can transmit the boarding / alighting information to the approver terminal 6, the third-party terminal 7, etc. If the service vehicle 3 is a manually operated vehicle, the boarding / alighting information can be transmitted to the dispatch server device 4 by the driver.

[0038] <6. Dispatch Server Device> The dispatch server device 4 is a server that manages dispatch-related information, and like the server device 2, it can be configured using a known computer. When the dispatch server device 4 receives the dispatch information from the server device 2, the dispatch server device 4 transmits that dispatch information to the service vehicle 3. Note that communication regarding dispatch information, boarding and alighting information, etc., can also be conducted between the service vehicle 3 and the server device 2 without going through the dispatch server device 4.

[0039] <7. Software Configuration of Server Device> Next, the software configuration of the server device 2 will be described with reference to Figure 6. Figure 6 is a block diagram showing the software configuration of the server device 2. As shown in Figure 6, the controller 22 of the server device 2 loads the program stored in the storage device 24 into the storage device 24, interprets and executes the program using the processor 23, and functions as a computer equipped with a registration unit 221, a display unit 222, an authorization setting unit 223, a notification unit 224, and a dispatch unit 225. The functional configuration of each unit will be described below. Figures 7 to 17 and 20 to 22 show the screen of the approver terminal 6. In the following description, it will be assumed that each terminal is provided with a touch panel as an example, and that the terminal is operated by the user touching the touch panel. However, this is just an example, and for example, the terminal can be provided with physical buttons or operated with a pen.

[0040] Figure 7 shows the initial screen of the approver terminal. When the above-mentioned application is launched on the approver terminal 6, the initial screen 60 is displayed. The initial screen 60 displays the notification display unit 601, the "Today's Schedule" button 602, the "Action Plan" button 603, the "Vehicle Dispatch Service" button 604, and the "Register / Manage" button 605. As will be described later, communication takes place between the approver terminal 6, the third-party terminal 7, or the proxy approver terminal 8 and the server device 2, and the following processing is performed by the respective parts 221 to 225 of the server device 2. For example, the server device 2 sends data for performing the various processing shown below to each terminal, and each terminal sends data necessary for the server device 2 to perform the various processing.

[0041] <7-1. Registration Unit> The registration unit 221 allows approver user U2 to register approved user U1 and to register an action plan including the destination of approved user U1. This registration will be explained with reference to Figures 8 to 11. The registration unit 221 performs the following processing.

[0042] <7-1-1. Registration of the Approved Person> When the registration / management button 605 of the approver terminal 6 is touched, as shown in FIG. 8, the approver terminal 6 displays a list of candidates for the approved user U2 received from the server device 2 in the approved person selection field 60a. For example, the approver terminal 6 may transmit the identification information input by the approver user U2 in the ID input field 60b to the server device 2, and the server device 2 may search for candidates for the approved user U1 using the identification information and transmit the list of candidates for the approved user U1 to the approver terminal 6.

[0043] When the approver terminal 6 accepts an operation of selecting an approved user candidate included in the list of approved user candidates in the approved person selection field 60a and an operation of pressing the determination button 60c, it transmits the identification information of the selected approved user candidate to the server device 2. When the server device 2 stores the identification information of the approved user candidate in the database 21 in association with the identification information of the approver user U2 as the identification information of the approved user U1 of the approver user U2, the registration of the approved user U1 is completed. For example, the server device 2 may store the identification information of the approved user U1 in the database 21 including the user registration information of the approver user U2.

[0044] If the approved user candidate is not registered in the server device 2, the approved user U1 can be newly registered from the approver terminal 6 to the server device 2. When registering the approved user U1, for example, the name, age, etc. of the approved user U1 can be registered.

[0045] <7-1-2. Destination Registration 1> When an approver user touches the destination dispatch button 504 on the approver terminal, a menu screen 62 is displayed as shown in Figure 9. When the "Register Destination" button 607 on this menu screen is touched, the destination candidates registered in the server device 2 are sent to the approver terminal 6. As a result, the approver terminal 6 displays destination candidates (Facilities A to D) as shown in Figure 10. For example, when an approver user touches Facility A as the destination, the approver terminal 6 displays candidate approved user U1s 609 who will go to the selected destination (Facility A), as shown in Figure 11. When an approver user U2 selects an approved user U1 who will go to the selected destination and touches the registration button 610, the destination and approved user U1 are sent to the server device 2. As a result, the server device 2 stores the destination and the approved user U1 going there in the database 21. The destinations listed above are facilities other than those where the events described later will be held, and will be referred to as "regular destinations" below.

[0046] <7-1-3. Destination Registration 2> Next, we will explain another method of registering a destination. The server device 2 transmits the registered event information to the approver terminal 6. When approver user U2 touches the "Today's Schedule" button 602 from the initial screen 60 in Figure 7, the approver terminal 6 displays the day's schedule 611 and the event information (event date and time, location, and content) 613, as shown in Figure 12. The "Today's Schedule" button 611 displays the registered schedule 612. This schedule 612 displays the event information and the participating approved users U1. When approver user U2 touches the event information 613, the screen of the approver terminal 6 displays a list 615 of the registered approved users U1, as shown in Figure 13. When approver user U2 selects the approved users U1 to participate in the event and touches the "Register" button 616, the event and the approved users U1 participating in it are transmitted to the server device 2. As a result, the server device 2 stores the event and the participating approved user U1 in the database 21.

[0047] <7-2. Display Unit>The display unit 222 performs the following processes to display the schedule and action plan of the approved user U1 on the terminal 6 for the approver. When the approver touches the "Today's Schedule" button 502 on the initial screen of the approver's terminal 6 shown in Fig. 7, the schedule shown in Fig. 12 is displayed as described above. When touching the schedule 612 described in this schedule, a list 617 of the approved user U1 who is a participant is also displayed as shown in Fig. 14. On this screen 65, it is possible to re-select the approved user U1. That is, when re-selecting the approved user U1 and touching the update button 618, the approved user U1 participating in the event is re-set and transmitted to the server device 2.

[0048] Also, when touching any of the approved users U1, as shown in Fig. 15, the registered destination of the selected approved user U1 is displayed. For example, when selecting the approved user U1 "Taro Yamada", a list 619 of permitted facilities is displayed. Therefore, on this screen, the destination can be re-registered. That is, the destination can be edited. <0 000097>

[0049] Further, when the approver U2 touches the "Action Plan" button 603 on the initial screen 60 shown in Fig. 7, the calendar shown in Fig. 16 is displayed.In the calendar, on the day when a schedule is registered (March 6), a mark 620 indicating the schedule, or alternatively, although not shown in the figure, the name of the event and the approved user U1 participating are displayed. When touching the day when the schedule is registered, the schedule for that day shown in Fig. 12 is shown, so the above-described operations and edits can be performed.

[0050] Also, it is possible to show the action plan for one day. For example, as shown in Fig. 17, on the screen 68 showing the action plan for one day, the destination where the approved user U1 acts, the arrival time, the departure time, and the required time are displayed. Also, when vehicle allocation has already been performed, as will be described later, the display of vehicle allocation is also performed.

[0051] The schedule of the approved user U1 is extracted from the database 21 of the server device 2 based on the operation of the approver's terminal 6. The extracted schedule is then sent to the approver's terminal 6 and displayed as shown above.

[0052] <7-3. Authority Setting Unit> The authority setting unit 223 has an authority table for performing various processes, and sets various permissions according to this authority table. Figure 18 is an example of an authority table.

[0053] This permission table 80 sets permissions for the principal guardian (approver user U2), other guardians (proxy approver user U4), children (approved user U1), event organizers, and event facility managers. Only one event facility manager is listed, but if there are multiple event facility managers, all of them can be displayed. There are four categories of permissions that can be set: administration, action plans, events, and vehicle dispatch. Administration includes adding and deleting permissions for guardians (approver user U2), adding, changing, and deleting permissions for children (approved user U1), and adding and deleting frequently used destinations. Action plans include adding, changing, deleting, and viewing action plans. Events include registering for and canceling events, check-in (joining an event), check-out (leaving an event), and viewing events. Vehicle dispatch includes proxy bookings, personal bookings (bookings by approved user U1), group dispatch, and viewing.

[0054] For ease of explanation, the authorization table 80 shown in Figure 18 indicates that the actions that can be performed by the principal guardian (approver user U2), other guardians (proxy approver user U4), children (approved user U1), event organizers, and event facility managers are marked with a circle (○), and actions that are restricted are marked with a triangle (△). Actions that are not marked with a circle or a triangle do not have authorization set (cannot be performed). The meaning of triangles will be explained later. Note that this authorization table 80 can be edited, for example, by the administrator of server device 2.

[0055] To set the permissions described above, the permission setting unit 223 performs the process shown in the flowchart of Figure 19. For example, as described above, if an unregistered event is displayed in the schedule (step S11) and approver user U2 registers to participate in the event (YES in step S12), the above permissions are automatically set for at least one of the event organizer and the administrator of the event venue (step S13). On the other hand, if approver user U2 does not register to participate in the event (NO in step S12), the unregistered event is displayed again (step S13).

[0056] Furthermore, approver user U2 can also set up third-party user U3 with the above-mentioned authority from approver terminal 6. In this case, by touching the registration / management button 605 described above, third-party user U3 with authority can be set up using the same operation as for registering approved user U1.

[0057] If a third-party user U3 with assigned permissions is the event organizer, according to the permission table 80, the event organizer can, from the third-party terminal 7, view the approved users U1 participating in the event, their activity plans, and the vehicle assignments for the approving user U2, as well as edit these. Therefore, the event organizer can view the activity plans of the participating approved users U1 on the day of the event, as shown in Figure 17, and understand their schedules before and after the event. This allows the event organizer to assign vehicles to their destinations after the event. Furthermore, if multiple approved users U1 participating in the event have the same destination after the event, the event organizer can assign the same vehicle to all of them.

[0058] However, the event organizer can only view the schedule of approved user U1, who is participating in the event, for that day only, and cannot view other schedules of approved user U1 (for example, participation in other events on days other than that day). For this reason, in the permissions table 80, the ability to view events is marked with a triangle (△) for the event organizer's permissions.

[0059] Furthermore, the authorization setting unit 223 can restrict the time during which authorizations can be set. For example, the event organizer can set the above authorizations only within a predetermined time period from a predetermined time before the start of the event to a predetermined time after the end of the event. This allows third-party user U3 to view the schedule of authorized user U1 only when necessary (for example, when vehicle dispatch is required), and prevents unlimited viewing of the schedule at other times.

[0060] The above-mentioned permissions can be granted to at least one of the event organizers or the person in charge of the venue where the event is held. This selection can be made by approver user U2.

[0061] <7-4. Notification Unit> As shown in Figure 7, the initial screen 60 of the approver terminal 6 is provided with a notification display unit 601. This notification display unit 601 can display various information transmitted from the server device 2 by the notification unit 224, for example. For example, it can display various information such as whether the approved user U1 boarded the dispatched vehicle, whether they alighted from the vehicle, whether there was a delay in the event, whether they participated in the event (checked in), and whether multiple approved users U1 boarded the same vehicle. This allows multiple approver users U2 to share information regarding the approved user U1's dispatch service. Such information can also be notified to the third-party terminal 7.

[0062] <7-5. Dispatch Unit> The dispatch unit 225 communicates with the dispatch server device 4 based on dispatch operations from the terminal for approved persons 5, the terminal for approvers 6, and the terminal for third parties 7, and can perform the following dispatch processing.

[0063] For example, when the dispatch button 606 is touched on the menu screen 62 shown in Figure 9 of the approver's terminal, the screen 69 shown in Figure 20 is displayed. This screen 69 displays the selection section 621 for the pick-up and drop-off locations for the day, the selection section 622 for the drop-off location, and the list 623 of the approved user U1 who will be riding. The pick-up location selection section 621 is a pull-down menu, and the user can select from the destinations registered in the action plan for the day (event facilities, regular destinations, and home). The drop-off location selection section 622 has the same configuration as the pick-up location selection section 621. In addition, all registered approved user U1s are displayed as the approved user U1 who will be riding. Here, the user can select the approved user U1 who will be riding.

[0064] Once the boarding location, alighting location, and the approved user U1 are set, the approver user U2 touches either the reservation button or the cancel button. When the reservation button is touched, the boarding and alighting locations, along with the action plan, are sent to the server device 2, which in turn sends them to the dispatch server device 4. The dispatch server device 4 dispatches a vehicle based on the received boarding location, alighting location, and action plan. At this time, the boarding and alighting times are also set. The boarding and alighting times thus set are sent to the approver's terminal via the server device, and the confirmation screen 70 shown in Figure 21 is displayed.

[0065] This confirmation screen 70 displays the boarding time at the boarding location and the alighting time at the alighting location. Touching the "Reserve" button completes the reservation. As a result, the registration unit 221 updates the action plan. Consequently, for example, the daily action plan displays the scheduled vehicle dispatch 600 as shown in Figure 22.

[0066] Figures 20 to 22 show the screen of the approver's terminal 6, but the third-party terminal 7 displays a screen like the one shown in Figure 23. Below, we will describe a terminal used by an event organizer as an example of a third-party terminal 7. When the program on the third-party terminal 7 is executed, a third-party application is launched. In that application, for example, the screen 71 shown in Figure 23 is displayed for reservation confirmation. This screen 71 displays the event section 711, the date section 712, and the participant list 714. The event section 711 allows the user to select an event using a pull-down menu. In this example, "Japanese Taiko Drums" is selected as the event, but the events displayed in the pull-down menu are limited to events hosted by the event organizer who logged in on this third-party terminal 7. Therefore, if this organizer also hosts other registered events besides "Japanese Taiko Drums," those other events will also be displayed.

[0067] The date section 712 also displays the date. By touching the calendar button 713 on the date section 712, a calendar (not shown) is displayed, and by selecting a date from it, the selected date is displayed on the date section 712. Once the event and date are selected in this way, a list of participants 714 that match them is displayed.

[0068] The participant list displays each participant's name, grade level, notes, reservation status, and attendance status. A checkmark indicates special notes regarding the participant. Touching the checkmark brings up a screen (not shown) displaying patent information. Patent information can be created, for example, by an approver user who has authorized participation, using the approver terminal 6. Regarding the reservation item, "×" indicates no prior reservation, while "○" indicates a prior reservation. Regarding the attendance item, "○" indicates arrival at the venue (check-in), while a blank space indicates no check-in. Note that participant Yamada Taro has a reservation marked "×" but attendance marked "○," indicating that he did not register in advance and participated spontaneously on the day of the event.

[0069] Furthermore, in this example, three approved user U1 users who have been approved by one approver user U2 are shown in list 714, but if there are other approved user U1 users who have been approved by other approver users U2, those approved user U1 users will also be included in list 714. Therefore, the event organizer can include all applicants or

[0070] There are various ways to check in to a facility. For example, an approved user U1 can complete the check-in by operating a terminal installed at the facility. In this case, the check-in can be completed by entering a pre-set password or the like. Alternatively, the check-in can be completed by holding a document that identifies the approved user U1 (for example, a document containing a barcode, QR code (registered trademark), etc.) over the facility's terminal. Such a document can be generated, for example, on the approver's terminal 6, printed, and provided to the approved user U1. Alternatively, the event organizer can directly input from a third-party terminal 7 that the approved user U1 has checked in. The facility's terminals are connected to the server device 2 via a network, and when the completion of check-in is received at any terminal, a "○" will be displayed in the participation item on the screen of the third-party terminal 7, as described above. Furthermore, once check-in is complete, this may be displayed in the action plan shown in Figures 17 and 22, for example. Alternatively, the completion of check-in can be notified to the notification display unit 601 of the approver's terminal 6 shown in Figure 7.

[0071] A third-party user U3 can make a reservation for a ride from the third-party terminal 7. For example, the user can launch a ride reservation screen similar to those shown in Figures 20 and 21 from the application on the third-party terminal 7 and make a reservation using the procedure described above. In this case, the list of scheduled passengers will display the approved users U1 who have checked into the event. By selecting one or more approved users U1 from this list, a ride reservation can be made. If multiple approved users U1 are selected, a reservation can be made for them to travel to their destination together in the same vehicle. For example, if more approved users U1 are selected than can fit in one vehicle, a reservation will be made for two or more vehicles corresponding to the number of approved users U1. In this way, a ride reservation can be made using the screens shown in Figures 20 and 21.

[0072] In summary, the process shown in the flowchart of Figure 24 is performed. The following explanation uses the approver terminal 6 as an example, but the process is the same for the third-party terminal 7. First, the approver user U2 sets the pick-up and drop-off locations on the approver terminal 6 (step S21). These pick-up and drop-off locations are sent to the dispatch server device 4 along with the action plan, and dispatch is made based on this. That is, the dispatch server device 4 generates the pick-up time at the pick-up location and the drop-off time at the drop-off location based on the pick-up and drop-off locations and the action plan (step S22). This information regarding dispatch will be referred to as dispatch information. Once the dispatch information is generated, it is sent to the approver terminal and displayed (step S23). After that, if the approver user U2 touches the reservation button (YES in step S24), the reservation is completed. On the other hand, if the user does not complete the reservation and touches the back button (NO in step S24), the pick-up and drop-off locations can be set again (step S21).

[0073] Additionally, you can cancel your reserved ride.

[0074] The processes shown in Figures 20 to 24 above were explained using the approver terminal 6 and the third-party terminal 7 as examples, but they can also be performed from the proxy approver terminal 8.

[0075] When booking a ride from a third-party terminal 7, the time frame during which a ride can be booked is limited, as described above. For example, if an action plan is created, as shown in Figure 17, to check out of facility X at 12:00 and check in to facility A at 12:45, the third-party terminal 7 can view the action plan shown in Figure 17 from 30 minutes before the approved user U1 checks out of facility X until the time of check-in at facility A. Therefore, third-party user U3 (the event organizer) can book a ride during this time.

[0076] <8. Features> As described above, the following effects can be obtained according to this embodiment.

[0077] (1) For example, if the approved user U1 does not have a terminal, the authority to view the approved user U1's action plan and arrange transportation can be granted to a third-party user U3, such as the event organizer, allowing transportation to be arranged on behalf of the approver user U2 and the approved user U1. For example, if the authority is granted to the event organizer as a third-party user U3, the event organizer can accurately grasp the status of the event and view the approved user U1's action plan, allowing transportation to be arranged according to the approved user U1's schedule. In this way, by granting the authority to arrange transportation to a third-party user U3, such as the event organizer, according to the approved user U1's schedule, the approved user U1 can receive appropriate transportation services.

[0078] (2) By granting the event organizer the authority of third-party user U3, they can view the action plan of authorized user U1, who is an event participant, and thus understand the schedule before and after the event. Therefore, for example, transportation arrangements to destinations after the event can be made smoothly.

[0079] (3) Third-party users U3, such as the event organizers, can view the action plans of multiple approved users U1 who will be using this ride-hailing service system. For example, if there are multiple approved users U1 who are going to the same destination after the event, the same vehicle can be assigned to these multiple approved users U1 as described above (multiple vehicles can be assigned if one vehicle is not enough). Therefore, the ride-hailing procedures by event organizers can be carried out efficiently.

[0080] (4) The server device is configured to automatically grant permissions to the event organizer or the person in charge of the event venue when the approver user U2 applies for an event in which the approved user U1 will participate. Therefore, the approver user U2 does not have to take the trouble to set permissions for the event organizer, etc.

[0081] <9. Modifications> Although one embodiment of the present invention has been described above, the present invention is not limited to the above embodiment, and various modifications are possible without departing from the spirit of the invention. For example, the following modifications are possible. Furthermore, the gist of the following modifications can be combined with each other as appropriate, and can also be combined with the above embodiment.

[0082] (1) In the above embodiment, operations from the terminal 5 for the approved user were omitted, but for example, operations such as dispatching vehicles can also be performed from the terminal 5 for the approved user based on the authorization table 18. That is, when the application is launched on the terminal 5 for the approved user, the processes defined in the authorization table 18 can be performed in the same way as described above for the approver terminal 6 and the third-party terminal 7.

[0083] (2) The notification unit 224 is not necessarily required and can be provided as needed.

[0084] (3) The screens of each terminal 6 to 8 shown in the above embodiment are examples, and the screen configuration, the number of screens to transition to, etc. can be changed as appropriate, as long as the processing by the registration unit 221, display unit 222, authority setting unit 223, notification unit 224, and dispatch unit 225 described above can be performed.

[0085] (4) The separate dispatch server device 4 for dispatching vehicles can be eliminated and integrated into the server device 2.

[0086] (5) The action plan may include status information indicating at least one of the following: whether or not a ride request has been made, the progress of the event, and the status of the authorized user U1 in the dispatched vehicle.

[0087] 6: Approver terminal 7: Third-party terminal 221: Registration unit 222: Display unit 223: Authority setting unit 224: Notification unit 225: Dispatch unit

Claims

1. An information processing device for providing a ride-hailing service, comprising: a registration unit configured to register an approved user whose approval is required by a registered approver user; a display unit configured to display an action plan including the registered destination of the approved user on the approver's terminal; an authorization setting unit configured to set authorization for a third-party user to view and edit at least part of the action plan; and a ride-hailing unit configured to receive a ride-hailing request from the third-party terminal of the third-party user to whom the authorization has been set, allowing the approved user to receive the ride-hailing service.

2. The information processing apparatus according to claim 1, wherein the authorization setting unit is configured to set the authorization for the third-party user upon request from the approver's terminal.

3. The information processing device according to claim 1, wherein the destination of the authorized user includes the facility where the event is held, and the third party to whom the authority is set includes at least one of the organizer of the event and the manager of the facility.

4. The information processing apparatus according to claim 3, wherein the authorization setting unit is configured to set the authorization for at least one of the organizer of the event and the administrator of the facility when the event is registered in the destination.

5. The information processing apparatus according to claim 3 or 4, wherein the authorization setting unit sets the time during which at least one of the event organizer and the facility manager can view the action plan.

6. The information processing apparatus according to claim 3 or 4, wherein the authorization setting unit sets the authorization for at least one of the event organizer and the facility manager to view and edit the destinations before and after the event in the action plan.

7. The information processing apparatus according to claim 3 or 4, wherein the dispatch unit is configured to allow the third-party user to collectively make dispatch requests to a plurality of approved users who have participated in the event.

8. The information processing device according to claim 3 or 4, wherein the action plan viewable by the third-party user includes status information indicating at least one of the presence or absence of the vehicle dispatch request, the progress of the event, and the status of the authorized person's presence in the dispatched vehicle.

9. The information processing apparatus according to claim 1, further comprising a notification unit for notifying the status of the approved user on at least one of the approver terminal and the third-party terminal.

10. The information processing apparatus according to claim 9, wherein the destination of the approved user includes a facility where an event is held, and the third party to whom the authority is set includes at least one of the event organizer and the facility manager, the notification unit notifies at least one of the event organizer and the facility manager of information regarding the approved user's arrival at the event.

11. When multiple approved users board the same vehicle that has been dispatched, the information processing device according to claim 9, which notifies each of the approver terminals of information regarding the boarding.

12. An information processing method performed by an information processing device for providing a ride-hailing service, comprising: a process for registering an approved user whose approval is required by a registered approver user; a process for displaying an action plan including the registered destination of the approved user on the approver's terminal; a process for granting a third-party user the authority to view and edit at least part of the action plan; and a process for receiving a ride-hailing request from the third-party terminal of the third-party user to whom the authority has been granted, so that the approved user can receive the ride-hailing service.

Images