Programs, methods, and information processing devices.

Abstract

To provide another technique of evaluating a driver for encouraging growth of the driver.SOLUTION: There is provided with a program activating a computer that provides a service of matching a package owner requesting delivery of a package with a driver in charge of delivering the package. The program causes a processor of the computer to execute the steps of: providing each driver with information of a package that a package owner requests for delivery; disclosing to the package owner, driver candidates to whom the package owner may request to deliver the package; recording by the driver, performance of deliveries based on the delivery request; identifying a history of deliveries based on the driver's delivery performance; and determining a first evaluation parameter in the service of matching the driver based on the identified result, where the first evaluation parameter for every driver candidate is disclosed to the package owner.SELECTED DRAWING: Figure 21

Description

Technical Field

[0001] The present disclosure relates to a program, a method, and an information processing apparatus.

Background Art

[0002] In the delivery business, evaluations of drivers' deliveries are being carried out.

[0003] In Patent Document 1 below, in order to encourage drivers to drive safely, technologies for analyzing drivers' safe driving based on the maximum speed, the number of speed overs, the time of speed overs, the number of sudden starts, the number of sudden accelerations, the continuous driving time, etc. are described.

Prior Art Documents

Patent Documents

[0004]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0005] On the other hand, there is a need for a technology that can further promote the growth of drivers by allowing drivers who deliver goods to come into contact with various delivery cases and accumulate new knowledge and experiences.

[0006] Therefore, the present disclosure provides another technology for evaluating drivers in order to promote the growth of drivers.

Means for Solving the Problems

[0007] According to one embodiment shown in this disclosure, a program is provided that operates a computer that provides a service matching a shipper who requests the delivery of goods with a driver who is responsible for delivering the goods. The program causes the computer's processor to perform the following steps: present information about the goods that the shipper requests the delivery of to each driver; disclose to the shipper a list of candidates for the driver to whom the shipper requests the delivery of goods; record the driver's record of deliveries made based on the delivery request; identify the delivery history based on the driver's delivery record; and determine a first evaluation parameter for the driver matching service based on the identified result. In the identification step, the delivery history is identified based on a predetermined number of the driver's most recent runs, rather than the driver's record for the most recent predetermined number of days. In the disclosure step, the first evaluation parameter for each candidate driver is disclosed to the shipper. [Effects of the Invention]

[0008] According to this disclosure, drivers can be evaluated based on the delivery conditions, specifically the types of deliveries they have made. [Brief explanation of the drawing]

[0009] [Figure 1] This is a block diagram showing an example of the overall configuration of System 1. [Figure 2] This figure shows the functional configuration of the server 20 in the first embodiment. [Figure 3] This is a block diagram showing the functional configuration of the driver terminal 10. [Figure 4] This diagram shows the data structure of the delivery request database 281. [Figure 5] This diagram shows the data structure of the driver database 282. [Figure 6] This diagram shows the data structure of the operation report database 283. [Figure 7] This diagram shows the data structure of the 284 originating database. [Figure 8] This diagram shows the data structure of the incident reporting database 285. [Figure 9] This diagram shows the process flow in which server 20 receives a trip report from a driver, updates the trip report database 283, and determines the fare, thereby updating the driver score "Trip Report" in driver database 282. [Figure 10] This diagram illustrates the process flow when a delivery request from a client is completed and server 20 receives the client's evaluation of the driver, thereby updating the driver's driver score, "User Rating." [Figure 11] This diagram shows the process flow in which Server 20, in response to an incident occurring with a driver, determines the severity of the incident and updates the driver's driver score, "Rule Compliance." [Figure 12] This diagram shows the process flow when server 20 receives a driving report from a driver and updates the driver score "Challenge". [Figure 13] This diagram shows the processing flow when server 20 receives a request from a client to deliver a package and sets a limit on the number of drivers who can offer to accept the order for that package (setting an entry limit). [Figure 14] This diagram illustrates the process of determining whether a client's delivery request has specific delivery conditions (challenges), and then informing the driver that it has specific delivery conditions and that they can improve their driver score. [Figure 15] This figure shows examples of screens provided to the driver on the driver terminal 10, and examples of screens presented to the client requesting delivery. [Figure 16] This figure shows the functional configuration of the server 20 in the second embodiment. [Figure 17] This diagram shows the data structure of driver database 282A. [Figure 18] This figure shows the data structure of rank table 286. [Figure 19]It is a diagram showing the data structure of the badge table 287. [Figure 20] It is a diagram showing the data structure of the quest table 288. [Figure 21] It is a diagram showing an example of a screen provided to a driver in the driver terminal 10.

Mode for Carrying Out the Invention

[0010] Hereinafter, embodiments of the present disclosure will be described with reference to the drawings. In the following description, the same parts are denoted by the same reference numerals. Their names and functions are also the same. Therefore, detailed descriptions thereof will not be repeated.

[0011] <First Embodiment> <Outline of the First Embodiment> In the following embodiments, a technique for specifying a driver evaluation value in a service that matches a requester who requests delivery and a driver who is in charge of delivery will be described. In the matching service, for the luggage requested for delivery by the requester, after the driver makes a bid for the order, the requester designates the driver and requests delivery.

[0012] In the matching service, a driver score for evaluating the driver is calculated and presented to the driver so as to promote the growth of the driver. On the driver side, when the driver score is good, the possibility of making a bid for a delivery request can be increased. For example, for a case where a driver is popular in a delivery request (for example, a case where the reward is relatively high as a delivery condition), a lower limit value of the driver score at which the driver can make a bid for the order is set. That is, in the process of improving the driver's score, there may be a state where a bid for a delivery request cannot be made.

[0013] On the other hand, in this matching service, clients are presented with information about drivers and given the option to choose which driver to request delivery from. This encourages clients to expect a variety of added value from drivers. As a result, drivers are more likely to provide a wider range of added value, potentially leading to higher compensation and opportunities to work on a wider variety of projects.

[0014] In the following description of the embodiment, the driver's engagement with various tasks is defined as one of the evaluation items for calculating the driver score.

[0015] On the other hand, matching services can include drivers who can frequently accept delivery requests (for example, full-time drivers) as well as drivers who make deliveries relatively infrequently (for example, drivers who work part-time for set hours).

[0016] By allowing for more diverse working styles for drivers, it is expected that the number of drivers participating in matching services will increase, and as a result, the number of deliveries requested by clients will also increase. Therefore, when evaluating drivers, it may be possible to evaluate them based on a certain number of past deliveries, making evaluations independent of each driver's delivery frequency.

[0017] In matching services, a driver score is determined based on a driver's recent track record of a certain number of deliveries, along with several other factors such as specific delivery conditions (challenges). This allows the matching service to determine each driver's overall score. Details are explained below.

[0018] <1.1 System Configuration Diagram> Figure 1 is a block diagram showing an example of the overall configuration of System 1.

[0019] System 1 is a system that assigns packages from clients requesting delivery to drivers. For example, System 1 can be used by the following types of businesses: • As a system for managing shipments for shipping companies, the shipping company collects the packages requested for delivery, and then each driver delivers them. The system acts as a platform that matches clients who request delivery with drivers who will deliver the packages. The system receives delivery requests from clients and accepts delivery requests from drivers. The driver collects the client's packages and delivers them to the destination.

[0020] The system 1 shown in Figure 1 includes multiple driver terminals 10, a server 20, and multiple delivery requester terminals 30.

[0021] The illustrated example shows multiple driver terminals, namely driver terminals 10A, 10B, ... Hereafter, these multiple driver terminals may be collectively referred to as "driver terminal 10".

[0022] Similarly, the illustrated example shows multiple delivery request terminals 30A, 30B, ... Hereafter, multiple delivery request terminals may be collectively referred to as "delivery request terminal 30".

[0023] The driver terminal 10, server 20, and delivery requester terminal 30 communicate with each other via network 80.

[0024] In this embodiment, each device (terminal device, server, etc.) can also be considered as an information processing device. That is, the collection of each device can be considered as a single "information processing device," and System 1 may be formed as a collection of multiple devices. The way in which the multiple functions required to realize System 1 according to this embodiment are distributed to one or more hardware can be appropriately determined in view of the processing capacity of each hardware and / or the specifications required for System 1.

[0025] The driver terminal 10 is a device operated by the delivery driver. The driver terminal 10 can be implemented, for example, as follows. • Handheld mobile devices such as smartphones and tablets • Stationary PCs (Personal Computers), Laptop PCs • Wearable devices (such as smartwatches or glasses) worn by the user who is the driver.

[0026] The driver terminal 10 includes a communication interface 12, an input device 13, an output device 14, memory 15, storage 16, and a processor 19.

[0027] The communication interface 12 is an interface for inputting and outputting signals so that the driver terminal 10 can communicate with an external device.

[0028] The input device 13 is a device for receiving input operations from the user, who is the driver (for example, a touch panel, touchpad, a pointing device such as a mouse, a keyboard, etc.).

[0029] The output device 14 is a device (such as a display or speaker) for presenting information to the user.

[0030] Memory 15 is for temporarily storing programs and data processed by programs, etc., and is a volatile memory such as DRAM (Dynamic Random Access Memory).

[0031] Storage 16 is for storing data, and can be, for example, flash memory or an HDD (Hard Disk Drive).

[0032] The processor 19 is hardware for executing the instruction set described in the program, and consists of an arithmetic unit, registers, peripheral circuits, etc.

[0033] Server 20 is a device that manages drivers who deliver packages to their destinations and the delivery status of those packages.

[0034] The server 20 includes a communication interface 22, an input / output interface 23, memory 25, storage 26, and a processor 29.

[0035] Communication IF22 is an interface for inputting and outputting signals so that the server 20 can communicate with external devices.

[0036] Input / Output IF23 functions as an interface between an input device for receiving user input operations and an output device for presenting information to the user.

[0037] Memory 25 is for temporarily storing programs and data processed by programs, etc., and is a volatile memory such as DRAM (Dynamic Random Access Memory).

[0038] Storage 26 is for storing data, and can be, for example, flash memory or an HDD (Hard Disk Drive).

[0039] The processor 29 is hardware for executing the instruction set described in the program, and consists of an arithmetic unit, registers, peripheral circuits, etc.

[0040] The delivery request terminal 30 accepts input from the requester who wants to request the delivery of a package.

[0041] <1.2 Functional Configuration of Server 20> Figure 2 shows the functional configuration of server 20. As shown in Figure 2, server 20 functions as a communication unit 201, a storage unit 202, and a control unit 203.

[0042] The communications unit 201 performs processing to enable the server 20 to communicate with external devices.

[0043] The memory unit 202 stores various databases, including a delivery request database 281, a driver database 282, an operation report database 283, a delivery source database 284, and an incident report database 285.

[0044] Delivery request database 281 is a database for managing information about packages that have been requested for delivery by the delivery company. Further details will be provided later.

[0045] Driver database 282 is a database for managing driver information. Further details will be provided later.

[0046] The operation report database 283 is a database used to manage the operations of the drivers who handled each delivery request. Further details will be provided later.

[0047] The shipping origin database 284 is a database for managing information about shipping destinations. Further details will be provided later. Incident Report Database 285 is a database for managing incidents (accidents, etc., based on laws and regulations such as the Road Traffic Act) that occur to each driver. Further details will be provided later.

[0048] The control unit 203 is realized when the processor 29 reads a program stored in the memory unit 202 and executes instructions contained in the program. By operating according to the program, the control unit 203 performs functions such as the reception control module 2041, the transmission control module 2042, the trained model generation module 2043, the home-occupancy rate estimation module 2044, the delivery route determination module 2045, the driver evaluation module 2046, the operation management module 2047, the matching module 2048, and the incident determination module 2049.

[0049] The receive control module 2041 controls the process by which the server 20 receives signals from external devices according to a communication protocol.

[0050] The transmission control module 2042 controls the process by which the server 20 transmits signals to external devices according to a communication protocol.

[0051] The pre-trained model generation module 2043 generates a pre-trained model for evaluating the probability of successfully delivering packages to each destination.

[0052] Specifically, the trained model generation module 2043 generates a trained model that outputs the probability of successful delivery to a destination by training with the delivery history of each package shown in the delivery request database 281 (delivery destination, time of delivery, and whether the delivery was successful or not) and the attributes of each delivery destination shown in the delivery source database 284 as training data.

[0053] The Home Presence Estimation Module 2044 estimates the probability of successful delivery for each package at each time of day. The Home Presence Estimation Module 2044 estimates the probability of successful delivery for each package based on information about the package to be delivered and trained models managed in the trained model database.

[0054] Specifically, the Home Attendance Rate Estimation Module 2044 outputs the probability (also called the "Home Attendance Rate") that a package will be received at the delivery destination for each time period. For example, for each package registered in the delivery request database 281 (a package scheduled for delivery), the Home Attendance Rate Estimation Module 2044 outputs the probability that delivery to the destination will be successful (i.e., the probability that the package will not be returned).

[0055] The delivery route determination module 2045 determines the delivery order and route for packages delivered by drivers, based on estimated occupancy rates.

[0056] Specifically, the delivery route determination module 2045 extracts candidate packages to be assigned to drivers based on the package information (packages scheduled for delivery) registered in the delivery request database 281, referring to the desired delivery date and time, location information of the delivery source, etc. For the extracted packages, the delivery route determination module 2045 refers to the desired delivery date and time information, and the estimated probability of successful delivery to the destination (at-home rate) (at-home rate estimation module 2044), and determines the delivery order based on the probability of successful delivery (i.e., packages that are unlikely to be returned) and the location of each package's destination. After determining the delivery order, the delivery route determination module 2045 searches for routes to deliver to each destination.

[0057] In addition to the above, the delivery route determination module 2045 may also determine the delivery order and route of each package by utilizing an external routing service (not shown) to determine the delivery order and route of each package. The server 20 transmits to the external routing service the delivery address of each package, the scheduled delivery time (for example, a time slot specified by the recipient or the person requesting the delivery), and various parameters such as the priority of each package (for example, a must-arrive delivery) to the external routing service. The external routing service determines the delivery order and route of each package based on the delivery address, scheduled delivery time, etc., and responds to the server 20 with the results of the determination. Here, the server 20 estimates the likelihood of recipients being home for each package and transmits the above parameters to the external routing service, specifying the time slot estimated to have a high likelihood of recipients being home. This makes it possible to determine the delivery order of each package so that it is delivered during a time slot when the likelihood of the package being returned is low, even if the package itself does not have information on the scheduled delivery time. Based on the delivery order determined in this manner, the server 20 can present the driver with the delivery order and delivery route. Alternatively, the processing of the external routing service described above may be performed by server 20 or the like.

[0058] The driver evaluation module 2046 assesses a driver's operational capabilities based on their delivery record.

[0059] Specifically, the driver evaluation module 2046 evaluates the driver based on the following items. • Did the driver deliver the package according to the delivery schedule (was there any delay)? Did the driver cause any accidents while making deliveries? • Did the driver have the required equipment installed in the vehicle when delivering the goods? • In cases where there is a supply and demand fluctuation resulting in a shortage of drivers relative to the volume of packages to be delivered, such as in a specific area or time slot, did the driver handle the delivery? Have you delivered packages that required a relatively long delivery distance (for example, delivery beyond a specified distance or time)?

[0060] Furthermore, the driver evaluation module 2046 evaluates the driver as follows: Based on a driver's delivery record, the service identifies the history of deliveries under specific delivery conditions and determines the driver's evaluation parameter (driver score) for matching drivers with shippers. • A driver's driver score may be determined each time a driver completes a delivery that meets the specific delivery conditions.

[0061] Here, the "delivery under specific delivery conditions" mentioned above includes the following: • The client requesting the delivery must have made deliveries within a specified number of times since initiating the service. • The client requesting the delivery must provide instructions regarding the delivery when picking up the package. • The client has requested one or more deliveries within a certain time frame. • The sender of the delivery must be the person sending the package for delivery under a specific service. • The delivery service is compatible with the shopping assistance service, and the delivery is related to the shopping assistance service.

[0062] The driver evaluation module 2046 evaluates the driver as follows: • In identifying specific delivery conditions, the driver's delivery history is identified based on a predetermined number of recent trips by the driver, rather than the driver's delivery history over the most recent predetermined number of days, to determine whether the delivery met the specific conditions. • When a delivery request is presented to a driver and the driver indicates that they are able to accept the order (or wish to accept the order), a limit may be placed on the number of drivers to whom the information about that order is presented as available for acceptance. For example, based on the driver score, the delivery of the order may be presented to a certain number of drivers (limited to drivers whose driver score exceeds a threshold). The driver evaluation module 2046 evaluates drivers by evaluating their driver score based on the history of deliveries made under specific delivery conditions, rather than the history of deliveries that set a limit on the number of drivers who can accept the delivery request as described above. • In determining the driver score, the driver's score is determined based on the delivery performance, regardless of the origin or destination location of the package in the driver's delivery record. In other words, the driver evaluation module 2046 determines the driver score based on the delivery record, regardless of the region in which the driver makes deliveries.

[0063] Furthermore, the driver evaluation module 2046 evaluates the driver score for each of the following items, and determines the driver's overall driver score based on the driver scores for each of these items. • Item "Operation Report": Has the driver submitted an operation report according to the prescribed standards for a prescribed number of deliveries in the past? The driver evaluation module 2046 may determine whether the operation report has been submitted according to the prescribed standards by evaluating the degree to which the operation report has been submitted appropriately based on the operation report database 283, as described later. The driver evaluation module 2046 may also determine the driver score for the item "Operation Report" by receiving the operation report from the driver and determining the compensation for the operation related to the operation report for the driver.

[0064] Here, the driver evaluation module 2046 may calculate a driver score for a driver's operation reports if the driver has not made the predetermined number of deliveries since registering with the service provided by the server 20 (for example, a newly registered driver), by assuming that the operation report score for at least a certain number of deliveries out of the predetermined number of deliveries is above a certain level (for example, "perfect score" as the operation report was properly submitted).

[0065] Furthermore, the driver evaluation module 2046 may calculate a driver score for the operation report based on a predetermined number of deliveries, excluding cases where the shipper canceled the delivery from the driver's delivery history. • Item "Equipment": Does the driver have the required equipment in the vehicle used for delivery? For example, the driver evaluation module 2046 may increase the driver's score for the "Equipment" item by having the driver register with the server 20 that they have the necessary equipment (e.g., dollies, protective cloths, non-slip gloves, helmets, safety vests, safety shoes, cargo securing belts, etc., which are relatively necessary for transportation). When a driver has just registered for the service provided by the server 20, the driver evaluation module 2046 may calculate the driver score for equipment as if the equipment were not present until the driver registers the equipment (calculating the score without assuming the equipment is present). • Item "User Rating": Whether the driver has received a certain level of rating from users at the origin or destination of a delivery in a predetermined number of past deliveries. For example, if the driver's rating is given on a multi-level scale (e.g., "dissatisfied," "satisfied," "very satisfied," etc.), points are set according to each level. The driver rating module 2046 may update the "User Rating" item by summing up the evaluation results for a predetermined number of past deliveries. The driver rating module 2046 may determine the driver score using driver ratings within a certain number of days since the driver was evaluated. The driver rating module 2046 may determine the length of the certain number of days when using driver ratings to specify the parameters of the "User Rating" item, depending on the geographical range including the location of the origin or destination, or the geographical range in which the driver makes deliveries. That is, depending on the geographical range of the order (e.g., prefecture level, city / town level), the number of days (reset date and time) until the "User Rating" item is reset based on the driver's rating is set. • Item "Rule Compliance": Has a specified incident occurred in a specified number of deliveries in the driver's past? The driver evaluation module 2046 may determine the driver score for the "Rule Compliance" item based on whether a specified penalty was applied to the driver in a specified number of deliveries, which constitutes a specified incident. For example, if an incident occurs to a driver, the driver evaluation module 2046 may, in response to detecting the occurrence of the incident, deduct points from the driver's rule compliance score over a specified period (e.g., a specified number of days such as several weeks, a month, or several months). The driver evaluation module 2046 may remove the deduction from the driver score after the specified period has elapsed. If another incident occurs to the driver within that specified period, the driver evaluation module 2046 may increase the degree of the deduction.

[0066] As described above, in System 1, Server 20 receives delivery requests from clients, registers information about the requests in the delivery request database 281, and then matches clients with drivers. Here, Server 20 may also receive delivery requests from partner services through API (Application Programming Interface) integration. Partner services that integrate with Server 20 include the following: • This is a separate service from the delivery management service provided by Server 20, and is a delivery management platform service that accepts delivery requests and matches them with drivers. • An e-commerce (EC) type service that allows users to offer and purchase goods or services from each other, such as an auction service, a flea market service, or shopping mall-type service. The items purchased between users may be delivered by the delivery management service provided by server 20. This service involves a business operator receiving purchase requests from customers on their website and delivering the goods or services to those customers. Such businesses may include those with physical stores in the real world where customers can purchase goods and services. Examples include supermarkets, convenience stores, drugstores, electronics retailers, outdoor equipment stores, restaurants, bookstores, rental services for video media and equipment, and other businesses that sell goods or services. When a customer purchases goods or services from a business operator, the delivery of the goods or services (e.g., the right to use them) may be handled by a delivery management service provided by Server 20.

[0067] In the aforementioned partner services, it is possible to accept reviews from users who utilize those partner services. For example, in an e-commerce service, it may be possible to accept reviews of the partner service from customers who have made a purchase, at a time of their choosing, such as after delivery is complete.

[0068] Such evaluations may involve receiving feedback from users on a scale of several levels (from low to high) for service evaluation. Users may be required to provide feedback on only one item. For example, a partner service could display a question on the user's terminal asking, "Please enter your feedback on using the service," and only accept a multiple-choice answer such as "not good" or "good," without requiring any other input from the user. Alternatively, a partner service could receive feedback from users on multiple items (for example, an overall evaluation of the service, the quality of delivery by the driver (which may include the condition of the delivered package and the interaction when handing the package over to the user), and an evaluation of the salesperson who made the sale). For example, in an e-commerce service, users may evaluate the seller, the e-commerce service itself, etc., and this evaluation may include items related to delivery (such as whether they were "satisfied" or "dissatisfied" with the condition of the delivered package, or whether they were "satisfied" or "dissatisfied" with the delivery person's interaction).

[0069] Server 20 may also receive evaluation information from the partner service when an evaluation is given to a driver who has made a delivery in that partner service. Furthermore, Server 20 may also receive driver evaluations by receiving user input operations from the partner service via the partner service through an API connection.

[0070] Server 20 may update each driver score managed in the driver database 282 based on the results of driver evaluations conducted based on the standards of the partnered service, as described above. For example, suppose the partnered service accepts evaluations of delivery quality at a different level of granularity than the driver evaluation levels accepted by Server 20 from clients or destinations, such as a 5-point scale. In this case, Server 20 converts each evaluation level in the partnered service to the evaluation levels in the service it provides, according to a predetermined rule. This allows Server 20 to incorporate the evaluations received by drivers in the partnered service (evaluations according to the standards of the partnered service) into the calculation of the driver score provided by Server 20. As a result, the opportunities for drivers to receive evaluations can be further expanded. Furthermore, for the service provider of the partnered service, the evaluations of users of that partnered service will be reflected in the driver score identified by Server 20, thus allowing them to participate in the management of driver quality in the delivery management service provided by Server 20. This can further improve the validity and reliability of the driver score identified by Server 20.

[0071] Here, the partner service that interacts with server 20 may include items that correspond to the driver evaluation items managed by server 20 (for example, the "Client Evaluation" item in the driver database 282 and delivery request database 281) as items for accepting evaluations from customers. Furthermore, the partner service that interacts with server 20 may request information from server 20 regarding evaluation items for accepting evaluations (such as questions to the customer and operation objects for accepting evaluations) in order to present a screen for accepting evaluations from customers to the customer. In other words, the partner service may present a screen for accepting evaluations from customers by communicating with server 20. This makes it even easier for server 20 to accept evaluations from customers in order to determine the driver score.

[0072] The operations management module 2047 manages the delivery status of each package and updates the operations report database 283.

[0073] Specifically, the operation management module 2047 manages the following information in the operation report database 283, etc., in response to the driver's operation to input delivery status. • A completion report indicating that the delivery of the package has been completed, and the timing at which the driver submitted the completion report. • Was the operational report submitted at the designated time (e.g., the scheduled delivery time) and location (e.g., around the delivery destination) in relation to the scheduled delivery of the package (delivery time, delivery route, etc.)? • Information such as the name of the driver who handled the delivery

[0074] The matching module 2048 matches the person who requests delivery of a package with the driver who will perform the delivery.

[0075] Specifically, when System 1 is used by a transportation company, the matching module 2048 matches cargo with drivers by accepting an operation from the administrator who manages operations at that company to assign cargo to a driver. In other words, the server 20 accepts an operation from the administrator to manually assign cargo to a driver (or delivery vehicle).

[0076] If System 1 is a system that matches clients who want delivery with drivers who will be responsible for the delivery, then matching module 2048 performs the following: • Refer to driver database 282 and extract drivers who are in a location capable of delivering the package as matching candidates. • The system presents the client with candidate drivers. Depending on the delivery conditions of the cargo to be delivered, the system may prioritize presenting drivers with high driver ratings (driver ranks) in the driver database 282 to the client. For example, the matching module 2048 sets a limit on the number of candidate drivers presented to the client by setting a threshold for the driver score of drivers who can deliver the client's cargo (only drivers with a certain level of driver score can deliver the cargo). In other words, the information on the cargo that the client requests to be delivered includes information on a first cargo that sets a limit on the number of drivers who can accept the delivery request for that cargo. For the first cargo with the limit set, the matching module 2048 prioritizes drivers with good driver parameters and presents the information on the first cargo in a way that allows those drivers to accept the delivery request. The first cargo is, for example, a cargo with delivery conditions that drivers are likely to want to accept (a cargo with delivery conditions popular with drivers). As described above, for the first cargo, the better a driver's driver score, the more likely that driver is to accept the delivery. The matching module 2048 may set conditions for the driver parameters of a driver that can offer to accept a delivery for a first package, based on the location of at least one of the origin or destination of the first package. The driver score required to enter the delivery of the first package may be varied depending on the area where the package is scheduled to be delivered. For example, if the ease of increasing a driver score differs from region to region, varying the conditions for entering the delivery of the first package may mitigate the sense of unfairness among drivers caused by the ease of increasing a driver score in each region. The matching module 2048 sets the conditions for the driver scores of drivers who can offer to deliver the first package, based on the location of the first package and the distribution of driver scores of multiple drivers who are available to deliver at that location.

[0077] The matching module 2048 manages the conditions for drivers who can accept deliveries from each shipper, and for each shipper's request, it may allow drivers who meet the specified conditions to enter the delivery, while not accepting entries from drivers who do not meet the conditions. For example, server 20 manages a list of drivers (whitelist) associated with shipper identification information. Depending on the shipper, the requirements for operating deliveries for that shipper may be: (i) The driver's knowledge must meet certain requirements (for example, if the driver has taken a training course, there must be a record of that training; the driver must take the exam regularly, etc. For example, the driver must have the general common sense necessary for delivery, such as traffic manners and not disclosing personal information (information leakage). Depending on the type of cargo (for example, food delivery, delivery of valuables, etc., there are prescribed precautions to ensure safe delivery without damage to the cargo)), (ii) When the driver is operating the vehicle, the driver or the delivery vehicle is equipped with the prescribed equipment (for example, the driver is wearing the prescribed uniform such as a delivery hat), The following may be set. Server 20 registers a driver to the shipper's whitelist when it receives information indicating that the driver meets the requirements set by the shipper (for example, when the shipper receives information from the shipper indicating that the driver meets the requirements). For delivery requests from the shipper, Server 20 assigns the delivery to a driver registered on the whitelist associated with that shipper. In this way, the shipper can set certain requirements for the drivers who perform deliveries and can guarantee the quality of deliveries. Drivers who perform deliveries using Server 20's delivery service are encouraged to meet the shipper's expectations and can work on their own growth and expanding their work opportunities.

[0078] The matching module 2048 may automatically match clients requesting deliveries with drivers, regardless of client specifications. The matching module 2048 matches drivers to handle deliveries based on information about the delivery request, the characteristics of the shipper, and the driver's evaluation, by referring to the driver database 282, etc. Furthermore, the matching module 2048 may automatically match packages with drivers without requiring the administrator managing the operation of assigning packages to drivers.

[0079] Matching module 2048 automatically performs matching based on the following: • Is the vehicle suitable for the driver to deliver the client's goods? (e.g., light commercial vehicles, motorcycles, refrigerated equipment, etc., does the vehicle have the characteristics to deliver goods in the first place?) • The relative location of the loading point for the client's cargo and the driver's location (the distance requirement to determine whether the driver can reach the loading point and load the cargo within a certain time). • Whether the driver meets the criteria set by the shipper, as shown in the whitelist above. • When multiple driver candidates are selected based on the above criteria, the degree to which each selected driver's driver score is good (higher scores are given priority)

[0080] As described above, by having the matching module 2048 determine the driver rather than the shipper designating one, delivery requests can be made to drivers in a manner that is not based on the shipper's subjective judgment. This provides opportunities for drivers newly registering with the delivery service provided by server 20 to handle deliveries. Furthermore, each driver can experience fairness in delivery assignments, as assignments are matched based on driver evaluations and other factors. Automatic matching of drivers who meet certain conditions can further improve the quality of deliveries. Additionally, shippers can request deliveries more easily by eliminating the step of deciding which driver to assign, and drivers can reduce the waiting time for the results of their delivery request entries.

[0081] The matching module 2048 may, at the request of the shipper, perform matching from a group of drivers whose past delivery history meets certain requirements. For example, some shippers may require drivers to have experience delivering in a specific industry. In this case, the matching module 2048 may not accept driver specifications from the shipper, instead referencing the delivery history stored in the delivery request database 281, and instead match drivers who have previously delivered for the shipper, or drivers who have previously delivered for clients in the same industry as the shipper, as the population. The scope of the same industry may include the following: • Whether or not the company has experience handling deliveries for pre-identified businesses as a comprehensive e-commerce platform that handles a relatively large volume of deliveries (for example, this could involve maintaining a database of such businesses on server 20). • Whether or not they have experience in delivering goods in industries such as construction and precision equipment, where safer delivery is required (for example, a database of companies in those industries may be maintained on server 20). • Whether or not they have experience delivering orders for companies that compete with the shipper (for example, a database of competing companies may be maintained on server 20 for each industry).

[0082] The matching module 2048 may accept an operation from a driver to specify whether or not they are currently available for delivery, and may perform matching based on the driver's status without the shipper specifying a driver. The driver's status may include the following: • Currently able to accept delivery requests (ON state) (Online mode) • We are currently unable to accept delivery requests (OFF state) (offline mode).

[0083] The matching module 2048 may perform delivery request matching only for drivers who are in the ON state. The matching module 2048 may also accept delivery requests along with information indicating that the request is an immediate delivery request (an immediate response request). For such immediate response requests, the matching module 2048 may perform matching only for drivers who are in the ON state, and exclude drivers who are in the OFF state from the matching process. This allows for appropriate driver matching for each delivery request.

[0084] The following are possible delivery requests for such immediate-response cases: • Requesting delivery from a food delivery service • Delivery requests in shopping assistance services (where drivers are given discretion in shopping based on the client's requests). • A service in which a driver picks up goods that have been ordered and paid for in advance by the customer from a store or other location and delivers them to the customer's desired location (for example, delivery of food ordered through an ordering app provided by a restaurant, delivery of fresh food such as sushi, delivery of dry cleaning, etc.) • Requests for urgent pickup and delivery, such as express delivery.

[0085] As described above, the driver terminal 10 receives input from the driver to switch between an ON state and an OFF state. The driver terminal 10 may also accept driver operations by displaying an operation reception section (button, slider, etc.) for switching between an ON state and an OFF state on a screen for searching for cases, for example.

[0086] If the driver terminal 10 is in the OFF state, it may display the case information to the driver as follows: • Allow viewing of cases that do not require immediate attention. • Allow entry and acceptance of projects that do not require immediate attention. • Both non-immediate-response and immediate-response tasks can be operated (for example, a driver may switch to OFF mode while receiving and delivering an immediate-response task. While OFF, the driver will not receive notifications for immediate-response tasks, and there will be no automatic matching). (It is also acceptable to stipulate that immediate-response tasks cannot be operated.) • For cases that do not require immediate attention, we will notify you when new cases become available. Drivers will not be notified of cases requiring immediate attention.

[0087] If the driver terminal 10 is in the OFF state, it may display the case information to the driver as follows: • Allow viewing of cases that do not require immediate attention. • For immediate delivery requests, offer the delivery request to the driver. • Allow entry and acceptance of both immediate-response and non-immediate-response cases (expanding the options available to drivers). • We can operate both cases that require immediate attention and those that do not. • For cases that do not require immediate attention, we will notify you when new cases become available. • For immediate response cases, drivers will be notified of new cases (alarm sound, push notification, etc.).

[0088] Server 20 may, if the driver has not yet completed registration of their information for the service delivered by Server 20 (provisional registration), allow the driver to view the case information, but may not accept the driver's operation to turn on the service. This can prompt the driver to complete the registration of their information. Additionally, if the driver is unable to enter a case, Server 20 may not accept the driver's operation to turn on the service.

[0089] The incident determination module 2049 determines whether a predetermined incident has occurred during a driver's delivery.

[0090] Specifically, the incident determination module 2049 determines whether or not penalties stipulated in laws and regulations such as the Road Traffic Act, or in the regulations of the matching service provided by the server 20, have been applied to each driver managed in the driver database 282. For example, the server 20 collects information on incidents that have occurred for each driver as follows: • Reports from the driver: We accept reports from each driver in the event of an accident or other incident. • Information provided by sources other than drivers: We accept reports of incidents from users of the service (such as clients) based on user ratings, etc. • Natural detection: By collecting information accumulated on the web, etc. (for example, news articles about accidents, etc.), it is possible to detect when an incident has occurred involving a driver.

[0091] The incident determination module 2049 updates the incident reporting database 285 based on the collected incident information. The incident determination module 2049 determines the severity of the incident that occurred for the driver (for example, in multiple stages such as "minor," "moderate," and "critical," depending on the degree to which it affects the driver score). The incident determination module 2049's determination of incident severity includes the following: • Whether the reported incident is subject to a penalty or not (whether the incident is "not a concern" or not) Regarding the occurrence of the incident, was the incident detected on server 20 through a driver report, other external notification, or natural detection?

[0092] <1.3 Configuration of Driver Terminal 10> Figure 3 is a block diagram showing the functional configuration of the driver terminal 10.

[0093] As shown in Figure 3, the driver terminal 10 includes a plurality of antennas (antenna 111, antenna 112), communication units corresponding to each antenna (first communication unit 120, second communication unit 121), an input device 130 (including a touch-sensitive device 131), a display 132, an audio processing unit 140, a microphone 141, a speaker 142, a position information sensor 150, a camera 160, a motion sensor 170, a storage unit 180, and a control unit 190. The driver terminal 10 also has functions and configurations not specifically shown in Figure 3 (for example, a battery for maintaining power, a power supply circuit for controlling the supply of power from the battery to each circuit, etc.). As shown in Figure 3, each block included in the driver terminal 10 is electrically connected by a bus or the like.

[0094] Antenna 111 radiates the signal emitted by driver terminal 10 as radio waves. Antenna 111 also receives radio waves from space and provides the received signal to first communication unit 120.

[0095] Antenna 112 radiates the signal emitted by driver terminal 10 as radio waves. Antenna 112 also receives radio waves from space and provides the received signal to second communication unit 121.

[0096] The first communication unit 120 performs modulation and demodulation processing, etc., for the driver terminal 10 to transmit and receive signals via the antenna 111 in order to communicate with other wireless devices. The second communication unit 121 also performs modulation and demodulation processing, etc., for the driver terminal 10 to transmit and receive signals via the antenna 112 in order to communicate with other wireless devices. The first communication unit 120 and the second communication unit 121 are a communication module that includes a tuner, an RSSI (Received Signal Strength Indicator) calculation circuit, a CRC (Cyclic Redundancy Check) calculation circuit, a high-frequency circuit, etc. The first communication unit 120 and the second communication unit 121 perform modulation, demodulation, and frequency conversion of the wireless signals transmitted and received by the driver terminal 10, and provide the received signal to the control unit 190.

[0097] The input device 130 has a mechanism for receiving user input operations. Specifically, the input device 130 is configured as a touchscreen and includes a touch-sensitive device 131. The touch-sensitive device 131 receives user input operations from the driver terminal 10. The touch-sensitive device 131 detects the user's contact position with the touch panel, for example, by using a capacitive touch panel. The touch-sensitive device 131 outputs a signal indicating the user's contact position detected by the touch panel to the control unit 190 as an input operation.

[0098] The display 132 displays data such as images, videos, and text in accordance with the control of the control unit 190. The display 132 can be implemented, for example, by an LCD or an organic EL display.

[0099] The audio processing unit 140 modulates and demodulates the audio signal. The audio processing unit 140 modulates the signal received from the microphone 141 and provides the modulated signal to the control unit 190. The audio processing unit 140 also provides the audio signal to the speaker 142. The audio processing unit 140 is implemented, for example, by an audio processing processor. The microphone 141 receives an audio input and provides the audio signal corresponding to that audio input to the audio processing unit 140. The speaker 142 converts the audio signal received from the audio processing unit 140 into sound and outputs the sound to the outside of the driver terminal 10.

[0100] The location information sensor 150 is a sensor that detects the position of the driver terminal 10, and is, for example, a GPS (Global Positioning System) module. A GPS module is a receiving device used in a satellite positioning system. In a satellite positioning system, signals are received from at least three or four satellites, and based on the received signals, the current position of the driver terminal 10, which is equipped with a GPS module, is detected. For example, in system 1, the driver terminal 10 transmits location information to the server 20 by allowing the server 20 to refer to the user's location. The server 20 determines whether the user is within a certain distance from the delivery destination (i.e., is attempting to complete a delivery) based on the location information of the driver terminal 10 and the location information (coordinates) of the delivery destination.

[0101] Camera 160 is a device that receives light using a photodetector and outputs it as an image. Camera 160 is, for example, a depth camera that can detect the distance from camera 160 to the object being photographed. The motion sensor 170 includes an acceleration sensor, an angular velocity sensor, etc., and detects the movement of the driver terminal 10.

[0102] The storage unit 180 is composed of, for example, flash memory and stores data and programs used by the driver terminal 10. The various types of information stored in the storage unit 180 will be described later.

[0103] The control unit 190 controls the operation of the driver terminal 10 by reading the program stored in the memory unit 180 and executing the instructions contained in the program. The control unit 190 is, for example, an application processor. By operating according to the program, the control unit 190 performs the functions of an operation reception unit 191, a transmission / reception unit 192, a data processing unit 193, a notification control unit 194, and a memory control unit 195.

[0104] The operation reception unit 191 processes input operations from the user to an input device such as a touch-sensitive device 131. Based on the coordinate information of the touch-sensitive device 131 where the user's finger or the like has made contact, the operation reception unit 191 determines the type of operation, such as whether the user's operation is a flick operation, a tap operation, or a drag (swipe) operation.

[0105] The transmitting / receiving unit 192 performs processing to enable the driver terminal 10 to send and receive data with external devices such as the server 20 and the driver terminal 10, in accordance with the communication protocol.

[0106] The data processing unit 193 performs calculations on the data received as input by the driver terminal 10 according to the program and outputs the calculation results to memory or other locations.

[0107] The notification control unit 194 performs the following processes: displaying the display image on the display 132, outputting sound to the speaker 142, and generating vibrations.

[0108] The memory control unit 195 controls the storage of data to the storage unit 180. For example, the memory control unit 195 causes various data to be stored in the storage unit 180 based on the operation of the delivery management application 181.

[0109] The various types of information stored in the memory unit 180 will now be described. In a certain scenario, the memory unit 180 stores the delivery management application 181.

[0110] The delivery management application 181 is an application for managing the delivery of packages. When System 1 is used by a transportation company, the delivery management application 181 performs the following: • Provide the driver with information about the one or more packages to be delivered, the delivery schedule (delivery destination, the order in which packages will be delivered to the destinations, and the estimated delivery time), and the delivery route. Based on the number of packages the driver will deliver and the order in which those packages will be delivered (which package to deliver first), the system provides the driver with instructions on how to load the packages onto the delivery vehicle. For example, the delivery management application 181 provides the driver with instructions on where to load each package on the delivery vehicle, along with the order in which each package will be delivered. Specifically, the delivery management application 181 notifies the driver that packages with earlier delivery orders should be loaded on the side of the cargo bed closest to the loading opening (for example, the rear side near the door if the vehicle is a truck with loading from the rear door), as packages with later delivery orders will be loaded later in the vehicle. The delivery management application 181 also notifies the driver that packages with later delivery orders should be loaded on the side of the cargo bed furthest from the loading opening (for example, the back of the cargo bed if the package is loaded from the rear door), as packages with later delivery orders will be loaded later in the vehicle. This allows even drivers unfamiliar with delivery procedures to be guided through the loading process, potentially shortening the time required for loading and unloading at the delivery destination. · When a driver begins delivering packages, the system accepts input from the driver indicating that each package has been loaded as described above. For example, for each package, the system accepts an operation from the driver, such as using the driver terminal 10, to indicate that it has been loaded into the delivery vehicle, in accordance with the order in which each package will be delivered. The delivery management application 181 may also display the number of packages assigned to the driver and update the information on the remaining number of packages to be loaded in response to the input operation indicating that each package has been loaded. The delivery management application 181 may also refuse to accept input operations to start or complete delivery until the remaining number is "zero," i.e., until the driver has completed the input operation to load all packages (for example, the driver may not be able to perform the operation to report the completion of delivery, and as a result, the driver may not receive payment). This helps prevent the driver from making mistakes such as accidentally failing to deliver multiple packages that have been assigned to them. • When a driver delivers a package, the system accepts input from the driver to complete the delivery. • Upon receiving confirmation from the driver that delivery is complete, the server 20 is notified that delivery is complete. • If a package is returned due to reasons such as the recipient being absent at the delivery address, the system will accept input from the driver indicating that the package was returned. The system may refuse to accept any actions from the driver (e.g., actions to receive payment) until the driver has reported whether all assigned packages have been delivered or returned due to the recipient's absence. This encourages the driver to report the delivery status of each package, and allows the server 20 to properly manage the status of each package, such as whether delivery was completed or returned due to unsuccessful delivery. • Enables the sending and receiving of messages between the transportation company's manager and the driver.

[0111] <2 Data Structure> Figures 4 through 8 show the data structure of the database stored by server 20. Note that Figures 4 through 8 are examples and do not exclude any data not shown.

[0112] Figure 4 shows the data structure of the delivery request database 281. The delivery request database 281 includes the following items: "Request ID", "Requester ID", "Sender ID", "Destination ID", "Item to be delivered", "Desired delivery date and time", "Estimated rate of recipient being home", "Entry restrictions", "Delivery driver", "Remarks", "Specific delivery conditions", and "Requester evaluation".

[0113] The "Request ID" field is information that identifies each delivery request from the delivery company.

[0114] Specifically, the item "Request ID" may be considered as information issued in association with each package for which a delivery request is received from the client.

[0115] The "Client ID" field is information that identifies the client requesting the delivery.

[0116] The "Shipping Origin ID" field is information that identifies the shipping origin of the package.

[0117] Specifically, the item "Shipping Origin ID" may include the following information as it identifies the shipping origin: • Information about the facility at the shipping origin. • Delivery address information • Information such as the name of the individual or business using the shipping address, and details of their business.

[0118] The "Delivery Destination ID" field is information that identifies the delivery destination of the package.

[0119] Specifically, the item "Delivery Destination ID" may include the following information as information that identifies the delivery destination: • Facility information for the delivery destination • Delivery address information • Information such as the name of the individual or business using the delivery address, and details of their business.

[0120] The item "Items to be delivered" contains information indicating the contents of the package.

[0121] Specifically, the item "Items to be delivered" may include the following as information about the contents of the package: • Package size • Weight of luggage • Name of the package • Number of packages • Type of luggage (daily necessities, etc.) • Shipping temperature (e.g., frozen)

[0122] The item "Desired Delivery Date and Time" contains information about the timing at which the sender or recipient prefers the package to be delivered.

[0123] Specifically, the item "Desired Delivery Date and Time" may include the following information regarding the desired delivery timing: • Date and time • Time slot · day of week

[0124] The item "Estimated Occupancy Rate" contains information on the estimated probability of being able to deliver packages to their destinations.

[0125] Specifically, the item "Estimated Home-Based Rate" may include the following as information on the estimated results: • Occupancy rate by time slot (the probability that the recipient or resident at the delivery address will be at home to receive the package) • Percentage of people at home by day of the week

[0126] The "Entry Restrictions" item contains information about the conditions under which drivers are eligible to accept a delivery request.

[0127] Specifically, the item "Entry Restrictions" may include the following as conditions for drivers who can offer to accept a job: • The region where the driver is based • Driver score threshold (a driver score above a certain level)

[0128] The item "Delivery Driver" contains information about the driver who delivered the package.

[0129] Specifically, the item "Delivery Driver" may include the following information about the driver. Further details will be provided later in the description of Driver Database 282. • Driver identification information

[0130] The "Remarks" field contains information about delivery conditions other than the location of the origin or destination of the delivery.

[0131] Specifically, the "Remarks" field may include the following information regarding delivery conditions: • Whether or not instructions have been received from the origin or destination at the location of the delivery. The item "Does it meet specific delivery conditions?" indicates whether or not the package meets specific delivery conditions.

[0132] Specifically, the item "Is it a specific delivery condition?" includes items determined to be specific delivery conditions based on the information in the delivery request database 281, such as the "origin of the package," "item to be delivered," and "remarks," as well as items designated as specific delivery conditions by the service provider operating the service provided by server 20.

[0133] The "Client Evaluation" item contains information showing the evaluation of the driver by the client who requested the delivery.

[0134] Specifically, the item "Client Evaluation" may include the following as evaluations given by the client to the driver: • Was the delivery made on schedule (without delays)? • Was the driver handling the luggage appropriately? • Driver's interaction with the client

[0135] Figure 5 shows the data structure of the driver database 282. Each record in the driver database 282 includes the following fields: "Driver ID", "Driver Name", "Location", "Working Hours", "Vehicle Type", "Driver Score_Operation Report", "Driver Score_Equipment", "Driver Score_User Rating", "Driver Score_Compliance", "Driver Score_Challenge", and "Driver Score_Overall".

[0136] The "Driver ID" field is information that identifies each driver.

[0137] The "Driver Name" field contains information about the name of each driver.

[0138] The "Location" item refers to the geographical area for which each driver is responsible for deliveries.

[0139] Specifically, the item "Location" includes the following information regarding the geographical area for which a driver is responsible for deliveries: • A certain geographical range based on the garage where the driver's vehicle is stored. • A certain geographical range based on the location where the driver operates. • Setting the geographical range for each scheduled date and time when drivers are scheduled to work (for example, the geographical range in which deliveries are possible may change depending on the date and time).

[0140] The "Operating Hours" item contains information about the time periods during which each driver performs delivery duties.

[0141] Specifically, the item "Operating Hours" may include the following information regarding the time periods during which drivers perform delivery duties: • Available delivery time slots for each day of the week (for example, available delivery time slots may vary depending on the day of the week)

[0142] The "Vehicle Type" item contains information about the vehicle used by each driver for deliveries.

[0143] Specifically, the item "Vehicle Type" may include the following as information about the vehicle: • Vehicle manufacturers • Year of manufacture of the vehicle • Total weight of cargo that can be transported by vehicle • Total cargo capacity that can be transported by vehicle • Vehicle inspection history

[0144] The item "Driver Score_Operation Report" contains evaluation information about the driver's operation report, which is identified when each driver performs deliveries using System 1.

[0145] Specifically, the item "Driver Score_Operation Report" may include the following as driver evaluation information: • Whether the driver's delivery procedures were appropriate (whether a report was submitted confirming that the delivery was made according to the scheduled delivery date and time). • Did the driver properly report the operation (did they report the operation at all? Did they report the operation at the appropriate time?)

[0146] For example, server 20 may update the "Driver Score_Operation Report" item for each driver each time the driver completes their operation report and confirms their payment.

[0147] The item "Driver Score_Equipment" shows information evaluating the equipment the driver is using during deliveries.

[0148] Specifically, the item "Driver Score_Equipment" may include the following as driver evaluation information: • Is the driver making deliveries with the vehicle equipped with the required equipment?

[0149] The item "Driver Score_User Rating" shows information on driver ratings based on feedback from clients.

[0150] Specifically, the item "Driver Score_User Rating" may include the following as driver rating information: • Customer reviews of those who requested delivery • Recipient's evaluation of the package

[0151] For example, server 20 may update the item "Driver Score_User Rating" each time a driver receives a rating.

[0152] The item "Driver Score_Rule Compliance" provides information on the evaluation of rule compliance, which is determined by whether or not the driver caused a specified incident.

[0153] Specifically, the item "Driver Score_Rule Compliance" may include the following as driver evaluation information: • No operational accidents (accidents related to driving on roads, accidents causing damage to cargo, etc.) have occurred over a certain period of time.

[0154] For example, server 20 may update the "Driver Score_Rule Compliance" item in response to an incident occurring with a driver and the determination of penalties.

[0155] The "Driver Score_Challenge" item displays driver evaluation information, which is determined by the driver's performance in delivering packages that meet specific delivery conditions.

[0156] Specifically, the item "Driver Score_Challenge" may include the following as driver evaluation information: • In the past, during a specified number of deliveries, the company has delivered packages that meet specific delivery conditions.

[0157] As specific delivery conditions, based on each of the following pieces of information, the server 20 may determine that each piece of luggage meets the specific delivery conditions and update the delivery request database 281. The server 20 may also vary the increase range of the score in the item "Driver Score Challenge" according to the conditions based on each of the following conditions. · Trial of delivery request from the requester: The delivery is within a predetermined number of times (for example, the first time) after the requester starts a delivery request in the matching service provided by the server 20. · Delivery on a specific day of the week (for example, for corporate deliveries, on days when the corporation is closed such as Saturdays, Sundays, and holidays) (for example, for proxy shopping deliveries, the delivery date and time (the date and time to deliver the items purchased through proxy shopping) is on a Saturday, Sunday, or holiday). · Delivery during a specific time period (for example, late at night (around 0:00 to 8:00)). For corporate deliveries, it is a delivery during a specific time period such as late at night) (for example, for proxy shopping deliveries, the delivery date and time is during late at night). · There is an instruction to the driver at the place of origin or destination of the delivery. · It is a delivery condition with a time limit (delivery is to be made within a certain time. There may be multiple deliveries). For example, in a delivery service, it is to make deliveries during a certain time period. · It is a proxy shopping delivery.

[0158] For example, the server 20 may update the item "Driver Score Challenge" each time the driver's operation is completed (for example, when the server 20 receives an operation report from the driver. It is not necessary to wait for the determination of the consideration for the transportation).

[0159] The item "Driver Score - Comprehensive" indicates the comprehensive evaluation information of the driver, which is evaluated based on each item of the driver's evaluation.

[0160] Specifically, the item "Driver Score - Comprehensive" may hold an evaluation value obtained by calculating the comprehensive evaluation of the driver based on the driver scores of each of the above items.

[0161] Figure 6 shows the data structure of the operation report database 283. The operation report database 283 includes the items "Request ID", "Delivery Driver", "Scheduled Delivery Date and Time", "Operation Report Content", "Operation Report Timing", and "Is the Operation Report Appropriate".

[0162] The "Request ID" field is information that identifies each delivery request from the delivery company.

[0163] The item "Delivery Driver" contains information about the driver who delivered the package.

[0164] The item "Scheduled Delivery Date and Time" is information that identifies the timing of the scheduled delivery according to the delivery route.

[0165] The item "Operation Report Details" contains information that the driver has reported regarding the delivery of the cargo.

[0166] Specifically, the item "Operation Report Contents" may include the following as part of the driver's report: • Delivery completed as scheduled. • The delivery address was not occupied, so the package was returned. • Delivery was completed later than scheduled, and the reason for the delay.

[0167] The item "Operation Report Timing" indicates the timing of operation reports from drivers.

[0168] Specifically, the item "Operation Report Timing" includes information updated by the operation management module 2047 based on the timing at which it received the driver's operation report input operation on the driver terminal 10.

[0169] The item "Was the operation report appropriate?" provides information indicating whether or not the operation report from the driver was appropriate.

[0170] Specifically, the item "Is the operation report appropriate?" may include the result of the operation management module 2047's determination of whether the driver's operation report was appropriate, based on the following information. • Whether the driver reported the start of the operation via the driver terminal 10 within a certain distance from the delivery source location (based on the location information of the driver terminal 10, it is possible to determine whether the driver reported the start of the operation within a certain distance from the delivery source location). - Whether the driver reported the completion of the delivery using the driver terminal 10, placed within a certain distance from the delivery destination. • Whether the timing of the driver's input operation to the driver terminal 10, reporting the start or completion of the operation, is within a certain time frame compared to the scheduled delivery time of the package (i.e., whether it is not delayed by more than a certain time).

[0171] The fleet management module 2047 may determine an overall evaluation value of whether the driver's operation report is appropriate or not, based on the results of the evaluation at each of the above timings. For example, the fleet management module 2047 may evaluate that the more operation reports the driver submits at each of the above timings, the higher the degree to which the operation report is appropriate.

[0172] Figure 7 shows the data structure of the shipping source database 284. The shipping source database 284 includes the fields "Shipping Source ID", "Coordinates", "Address", "Business Hours", and "Delivery Record".

[0173] The "Shipping Origin ID" field is information that identifies each shipping origin.

[0174] Specifically, the item "Shipping Source ID" may be an identification piece issued to each corporation or individual using the facility that serves as the shipping source.

[0175] The item "Coordinates" is the coordinate of the delivery location on the map.

[0176] Specifically, the item "Coordinates" may include latitude and longitude information as coordinates on a map.

[0177] The "Address" field contains the shipping address information.

[0178] Specifically, the "Address" field may include the following information necessary for package delivery as address information: ·prefectures Municipalities ·street address Building name • Building room number

[0179] When server 20 receives information about a package delivery request, it accepts the user's input of the delivery address. However, there may be inconsistencies in the way the user enters the delivery address. Server 20 may perform processing to absorb these inconsistencies in the delivery address (for example, processing to unify multiple addresses registered with server 20 for a delivery address that can be considered the same).

[0180] For example, when a driver delivers a package managed in the delivery request database 281, the server 20 retrieves address information from a map database or similar source based on the address information entered for that package and the coordinates of the delivery destination (for example, the location information of the driver's terminal 10). The server 20 also retrieves address information associated with the name of the delivery destination (for example, a company name) by referring to the name of the delivery destination (for example, the address published by the company). This allows for the handling of variations in the notation of delivery destination addresses.

[0181] For example, if System 1 is a delivery management system for transportation companies (where the administrator of each transportation company assigns drivers and packages, etc.), then System 1 may be used by multiple transportation companies. In such a case, System 1 can absorb (consolidate) variations in the notation of delivery destination addresses, and prompt each transportation company to enter addresses that have had these variations absorbed. As a result, the server 20 of System 1 can present each transportation company with address information that has had variations absorbed based on information such as the name and coordinates of the delivery destination, prompting them to specify the address, and making it even easier for users of each transportation company to enter delivery destination addresses.

[0182] The "Business Hours" item refers to the business hours of a business entity, such as a corporation or sole proprietor, if the delivery originates from that entity.

[0183] The item "Delivery History" is information regarding the delivery source's past delivery requests within the matching service provided by Server 20. Specifically, the item "Delivery History" includes the information updated by server 20 when it refers to the delivery request database 281 and determines whether or not it has previously delivered to the delivery source, and then updates the delivery source database 284 accordingly.

[0184] Figure 8 shows the data structure of the incident report database 285. The incident report database 285 includes the fields "Request ID", "Delivery Driver", "Incident Occurrence Date and Time", "Incident Report Date and Time", and "Incident Details".

[0185] The "Request ID" field is information that identifies each delivery request from the delivery company.

[0186] The item "Delivery Driver" contains information about the driver who delivered the package.

[0187] The item "Incident Date and Time" contains information about when the incident occurred for the driver.

[0188] Specifically, the item "Incident Occurrence Date and Time" may include the following as the timing when the incident occurred: • The timing when a record of an accident, etc., occurring under the Road Traffic Act is recorded by a public institution, etc.

[0189] The item "Incident Report Date and Time" contains information about when the incident was reported to server 20.

[0190] Specifically, the item "Incident Report Date and Time" may include the following as the timing when the incident was reported to server 20: • Timing when an operation to report an incident is received, such as an operation from the driver to the driver terminal 10. • When server 20 receives information from the client or other user that an incident has occurred regarding the driver. • By collecting information from the web, Server 20 detects the occurrence of an incident.

[0191] The item "Incident Details" contains information that describes the nature of the incident.

[0192] Specifically, the item "Incident Details" may include the following as the details of the incident: • Violations of laws and regulations related to delivery services, such as the Road Traffic Act, and the details of those violations. • Violation of the terms of service for the matching service provided by Server 20, and the details of that violation.

[0193] The "Incident Assessment" item provides information indicating the severity of the incident. Specifically, the item "Incident Assessment" may include a multi-level assessment of the severity of the incident, as follows. Server 20 may adjust the driver's driver score according to the results of the incident severity assessment, as follows. • Severity level "Low": For example, an incident was reported, but the incident itself was later canceled. • Severity "Normal": For example, an incident was reported, but the driver themselves reported it to server 20, or the driver was unaware that an incident had occurred. • High Importance: For example, an incident was reported, but the driver did not report it to server 20, the driver was aware of the incident, and it was detected naturally through external notification from the client or other source, or through information collected by server 20.

[0194] Server 20 may update the "Incident Assessment" item for each driver at the following timings: Each time a certain period of time has elapsed, Server 20 updates the "Incident Evaluation" item based on the incident history accumulated during that period. Each time an incident is reported or detected

[0195] <Operation of the first embodiment> Next, we will describe the operation of each device that makes up System 1.

[0196] Figures 9 to 12 show the process flow for updating each item of the driver score for each driver, which is managed in the driver database 282.

[0197] Figure 9 shows the process flow in which the server 20 updates the operation report database 283 after receiving an operation report from a driver, and then updates the driver score "operation report" in the driver database 282 by determining the fare.

[0198] In step S911, the control unit 190 accepts an input operation for reporting the operation based on the location information of the driver terminal 10, etc., if the driver is within a predetermined range from the delivery source location or within a predetermined range from the delivery destination location.

[0199] In step S921, the control unit 203 reads the delivery request database in response to the conditions being met for updating the trained model. Examples of conditions being met for the server 20 to update the trained model include the following: - A certain period of time has elapsed since the trained model was generated and began to be used to estimate the rate of people staying at home. The users (corporate and individual) of the delivery destination may change over time. Server 20 may generate a trained model for each region and change the length of the above-mentioned period before regenerating the trained model for each region. The trend of people moving in or out of a region may differ depending on the region. Server 20 may determine the period before regenerating a trained model appropriate for a region, depending on whether there is a high or low rate of people moving in or out of the region. • If the rate of successful delivery of packages falls below a certain threshold when estimating the rate of people being home using a pre-trained model (i.e., if the reliability of the pre-trained model's estimation of the rate of people being home falls below a threshold). • Construction status of buildings in the area. For example, when new office buildings, residential apartments, etc., are constructed. Once a certain amount of delivery data to new delivery destinations is accumulated, server 20 may generate a trained model for estimating the rate of people being at home.

[0200] In step S923, the control unit 203 learns based on the following information by referring to the delivery request database. • Time slots when delivery personnel delivered to each destination (Delivery request database 281) • Whether delivery to the destination was completed (Delivery Request Database 281) • Information entered by the delivery driver regarding the attributes of the delivery destination (Delivery source database 284)

[0201] The control unit 203 generates a trained model by performing the training as described above.

[0202] The control unit 203 identifies data from the delivery request database 281 targeting delivery destinations within a predetermined location and time range, based on the location information of the delivery destination and the timing of delivery to the delivery destination, and performs the learning process.

[0203] In step S925, the control unit 203 updates the trained model database based on the generated trained model. The trained model takes delivery information as input and outputs the probability of successful delivery (the probability that the recipient is home at the delivery destination for each time period).

[0204] The control unit 203 updates the trained model database based on the timing at which the trained model was generated, the range of the training data used for training (temporal and geographical range), and the number of times the trained model was generated based on the conditions of the training data (frequency of updates).

[0205] In step S927, in response to determining the driver's compensation for the operation, the control unit 203 identifies the driver's evaluation value (driver score) for the operation report based on whether the driver's operation reports have been submitted according to a predetermined standard for a predetermined number of deliveries in the past. Based on the identified evaluation value, the control unit 203 updates the driver score (operation report) in the driver database 282. Based on the updated driver score (operation report), the control unit 203 updates the driver score (overall).

[0206] Figure 10 shows the process flow when a delivery request from a client is completed and the server 20 receives the client's evaluation of the driver, thereby updating the driver's driver score, "User Evaluation."

[0207] In step S1031, the delivery request terminal 30 receives input from the user, who is the requester, regarding their evaluation of the driver's delivery.

[0208] In step S1033, the delivery requester terminal 30 sends the results of the user's evaluation to the server 20.

[0209] In step S1021, the control unit 203 updates the delivery request database 281 by receiving a delivery evaluation from the client, including an evaluation of the delivery source and an evaluation of the delivery destination.

[0210] In step S1023, the control unit 203 refers to the delivery request database 281 and, for deliveries over a predetermined number of past days, identifies the driver score (user evaluation) based on the evaluations received from the client for the most recent predetermined number of deliveries in the driver's past delivery history where the client provided an evaluation, and updates the driver database 282. Based on the updated driver score (user evaluation), the control unit 203 updates the driver score (overall).

[0211] Figure 11 shows the process flow in which Server 20, in response to an incident occurring with a driver, determines the severity of the incident and updates the driver's driver score, "Rule Compliance."

[0212] In step S1121, the control unit 203 receives input from another device indicating that a predetermined incident has occurred, such as an accident in the delivery service or a driver receiving a penalty.

[0213] In step S1123, the control unit 203 weights the incident based on the content of the incident report. The control unit 203 weights the incident as follows: • Whether the incident report falls under the category of events that are not subject to penalty ("not questioned") or not. • Does the incident report include the date and time when the driver was penalized? • Whether or not the incident was reported based on a voluntary report from the driver (for example, if the incident was reported based on a voluntary report from the driver, the reduction in the driver's evaluation score due to the incident may be reduced compared to cases where it was not reported (e.g., a report from someone other than the driver, or when the incident was detected based on information collected by Server 20 without a report)).

[0214] In step S1125, the control unit 203 updates the incident report database 285 based on the incident details, the date and time the incident was reported, information identifying the delivery request related to the incident, and the result of the incident weighting.

[0215] In step S1127, in response to the reporting of an incident, the control unit 203 identifies the driver score (rule compliance) depending on whether a predetermined incident has occurred in the driver's past predetermined number of deliveries, and updates the driver database 282. Based on the update of the driver score (rule compliance) for the driver, the control unit 203 updates the driver score (overall).

[0216] Figure 12 shows the process flow in which the server 20 receives a driving report from a driver and updates the driver score "Challenge".

[0217] In step S921, the control unit 203 receives operation report information from the driver terminal and updates the operation report database 283 based on the timing information of the operation report and the content of the operation report.

[0218] In step S1223, in response to the driver's report of the completion of the operation, the control unit 203 performs the following processes to identify the evaluation value of the driver. The control unit 203 refers to the delivery request database 281, the delivery source database 284, etc., and identifies the history of deliveries under specific delivery conditions in a predetermined number of past deliveries (for example, the most recent predetermined number of deliveries) by the driver. The deliveries under specific delivery conditions identified by the control unit 203 include the following. · Order from a new delivery requester: The delivery is within a predetermined number of times (for example, the first time) since the requester who requests the delivery starts requesting in the service. For example, it is the first delivery received by the server 20 from the delivery source (case in the delivery source database 284). · With on-site instructions: There are instructions regarding the delivery when collecting the goods from the requester who requests the delivery. · Time-limited delivery: There is a request for one or more deliveries of goods within a certain time from the delivery requester. Multiple deliveries may be made within the time period. · Delivery in a specific service: The goods to be delivered are those for which the delivery requester conducts deliveries in a specific service.

[0219] As a specific service, for example, a delivery service that manages the online receipt and order of food menus in a restaurant, presents the received orders to the driver, and the driver delivers on behalf of the store. Among others, as a specific service, a transportation service by a specific transportation company. · The server 20 supports a shopping proxy service, and it is a delivery associated with the shopping proxy. Based on the information of the purchase target requested by the requester, the driver makes a purchase while delivering to the requester.

[0220] In step S1225, based on the result of identifying the history of delivering under specific delivery conditions in the driver's past predetermined number of deliveries (for example, the most recent predetermined number of deliveries), the control unit 203 identifies the driver score (challenge) and updates the driver database 282. Along with the update of the driver score (challenge), the control unit 203 updates the driver score (overall).

[0221] FIG. 13 is a diagram showing the processing flow when the server 20 sets an upper limit (sets a restriction on entry) on the number of drivers who can receive a request for delivering a load from a consignor and submit a bid for accepting the order of the load.

[0222] In step S1321, the control unit 203 updates the delivery request database 281 by accepting a request for delivering a load from a consignor.

[0223] In step S1323, the control unit 203 refers to the delivery request database 281, identifies requests with entry conditions for a driver to receive a delivery request (sets an upper limit on the number of drivers who can enter), sets the conditions (such as the evaluation value of the driver required for entry), and updates the delivery request database 281. [[ID=第十三]]

[0224] In step S1325, the control unit 203 refers to the delivery request database 281, and for deliveries with entry conditions, preferentially presents the delivery request to drivers with a good driver score (overall). As the process of preferentially presenting the delivery request with entry conditions to drivers with a good driver score (overall), the control unit 203 performs the following. · For deliveries with entry conditions, present the deliveries with such entry conditions in a viewable manner to both drivers who meet the set driver evaluation value conditions (such as the driver score (overall) being score "AA" or higher) and drivers who do not meet such conditions, while accepting requests for such deliveries from drivers who meet the conditions and not accepting them from drivers who do not meet the conditions (for example, on the terminals of drivers who do not meet the conditions, the operation buttons for receiving orders for deliveries become disabled, etc.) · Among drivers with a good driver score (such as the driver score being above a certain level) and those without, present requests for deliveries with such entry conditions only to drivers with a good driver score. When the request for such a delivery is accepted, it may be made viewable to each driver regardless of the driver score.

[0225] In step S1311, the control unit 190 receives information on the delivery requested by the requester from the server 20 and presents it to the driver.

[0226] In step S1313, the control unit 190 receives an input operation indicating that the driver wishes to accept the delivery order and transmits it to the server 20.

[0227] In step S1327, the control unit 203 receives an input operation indicating that the driver wishes to accept the delivery request from the driver's terminal and updates the delivery request database 281. The control unit 203 refers to the driver database 282 and displays information on the drivers who wish to accept the delivery requested by the requester to the requester's terminal. The control unit 203 presents each item managed in the driver database 282 to the requester.

[0228] In step S1329, the control unit 203 receives an input operation from the delivery requester to specify the driver responsible for the delivery, refers to the delivery request database 281, and updates the information of the driver responsible for the requester's delivery. The control unit 203 then notifies the driver responsible for the delivery that the requester has made a request (order).

[0229] Figure 14 shows the process flow for determining whether a delivery request from a client has specific delivery conditions (challenges), and for informing the driver that it has specific delivery conditions and that they can improve their driver score.

[0230] In step S1423, the control unit 203 refers to the delivery request database 281, identifies a request with specific delivery conditions (challenges), and updates the delivery request database 281.

[0231] In step S1425, the control unit 203 refers to the delivery request database 281 and presents information about a delivery request with specific delivery conditions (challenge) to each driver by sending it to the driver terminal 10. The control unit 203 presenting a request with specific delivery conditions to each driver includes the following: • The screen displayed on the driver terminal 10 will indicate that the request is for delivery under specific delivery conditions.

[0232] On this screen, information will be displayed indicating how much the driver score (challenge) and driver score (overall) may change (for example, whether the score may increase) when a driver takes on a delivery request with specific delivery conditions.

[0233] <Screen example> Figure 15 shows examples of screens provided to the driver and screens presented to the client requesting delivery from the driver terminal 10.

[0234] The example screens (A) and (B) in Figure 15 show the phase in which the driver terminal 10 presents the driver score to the driver.

[0235] Screen example (C) shows a scenario in the driver terminal 10 where a delivery request is presented to the driver, and the driver accepts the request.

[0236] Screen example (D) shows a scene in the client's delivery request terminal 30 where the client is presented with a list of potential drivers to whom they can request delivery.

[0237] The control unit 190 displays UI (User Interface) components on the display 132 for presenting the driver score to the driver.

[0238] The control unit 190 displays images in the score display unit 132A that show the degree of the score for each item (driver database 282) that constitutes the driver score, as well as specific parameters for the overall evaluation of the driver score.

[0239] Specifically, the control unit 190 displays the evaluation value of the item "Driver Score_Overall" managed by the driver database 282 shown in Figure 5 in the overall parameter display unit 132A1. In the illustrated example, the overall driver score value of driver "E" displayed in the driver information display unit 132E is shown to be "900".

[0240] Meanwhile, the control unit 190 displays an image based on the evaluation value of the "Driver Score_Operation Report" item in the driver database 282 in the operation report parameter display unit 132A2.

[0241] Similarly, the control unit 190 displays an image in the equipment parameter display unit 132A3 based on the evaluation value of the "Driver Score_Equipment" item in the driver database 282.

[0242] Similarly, the control unit 190 displays an image based on the evaluation value of the item "Driver Score_User Evaluation" in the driver database 282 on the user evaluation parameter display unit 132A4.

[0243] Similarly, the control unit 190 displays an image based on the evaluation value of the item "Driver Score_Rule Compliance" in the driver database 282 on the rule compliance parameter display unit 132A5.

[0244] Similarly, the control unit 190 displays an image based on the evaluation value of the item "Driver Score_Challenge" in the driver database 282 on the challenge parameter display unit 132A6.

[0245] Here, for each item of the driver score for calculating the comprehensive driver score ("Operation Report", "Equipment", "User Evaluation", "Rule Compliance", "Challenge"), the control unit 190 may be set to be non-displayed as shown in the figure, and display the difference from the maximum value of the score.

[0246] For example, when calculating the comprehensive driver score, if the value is not simply the sum of each item of the driver score, by not presenting the evaluation value of each item to the driver, it is possible to avoid the driver having difficulty understanding the driver score. Also, by presenting the difference from the maximum value of the score for each item to the driver, the driver can be made to recognize which item it is advisable to focus on (for example, whether it is advisable to improve the item "Challenge", etc.).

[0247] The control unit 190 may choose to display only the overall driver score value in the overall parameter display unit 132A1, without displaying information on whether this value is good or bad (for example, whether it is good compared to other drivers). For example, the number and quality of delivery requests may differ from region to region, so the ease of improving the driver score may differ from region to region. In this case, by deliberately not displaying to the driver whether the overall driver score is good or bad, the driver may not become aware of the difficulty in improving their driver score in each region, and the driver may be encouraged to grow according to the request situation in each region.

[0248] The information display unit 132A7 shows information that should be notified to the driver regarding the driver score.

[0249] In example screen (B), compared to example screen (A), there is information that should be notified to the driver, and the information display unit 132A7 displays this information.

[0250] Specifically, the control unit 190 displays information that should be notified to the driver in relation to the driver score_equipment and the driver score_user evaluation in the information display unit 132A7.

[0251] For example, the control unit 190 displays in the information display unit 132A7 that the driver has not registered the equipment that should be installed in the vehicle using the service provided by the server 20, and prompts the driver to register it.

[0252] For example, the control unit 190 displays the deadline for when the user evaluation from the client will be reset in the information display unit 132A7, and also displays a message encouraging the driver to accept delivery requests and increase their score. The control unit 203 may also notify the driver that the user evaluation will be reset in the driver terminal 10 in response to a predetermined period of time (for example, a few days before) before the date and time when the user evaluation will be reset (in response to the remaining period until the reset becoming a certain period).

[0253] The control unit 190 displays an image in the equipment parameter display unit 132A3 and the user evaluation parameter display unit 132A4 that indicates that it is related to the content notified by the information display unit 132A7 (in the illustrated example, a display such as "!" to prompt the driver's attention).

[0254] In the example screen (C), the control unit 190 presents the driver with information about the delivery request and prompts them to input information to submit an order.

[0255] The control unit 190 displays information about the case for which the client has requested delivery in the case information display unit 132B.

[0256] Specifically, the control unit 190 displays information such as the case ID, case fare, collection time, origin, and destination in the case information display unit 132B1.

[0257] The control unit 190 displays in the information display unit 132B2 that the job being presented to the driver can improve the driver score, and also displays the factors that can improve the driver score. In the illustrated example, the information display unit 132B2 displays that the job meets specific delivery conditions (challenges), and that if the driver accepts the job, the driver score will increase, thereby encouraging the driver to offer to accept the job.

[0258] The control unit 190 displays the entry condition display unit 132B3 if there are conditions for a driver to be able to offer to accept a job for a case (for example, the overall driver score exceeds a threshold). In the illustrated example, there are no restrictions on offering to accept a job for a case (there are no restrictions on entry).

[0259] The control unit 190 accepts driver input operations for displaying detailed information about the delivery request in the information display unit 132D. For example, the server 20 responds to the driver's input operations to the information display unit 132D at the driver terminal 10 and displays various information from the delivery request database 281 (for example, information in the "Remarks" field) to the driver.

[0260] The control unit 190 receives input operations from the operation reception unit 132F to display the driver score. For example, in response to an input operation to the operation reception unit 132F, the control unit 190 displays screens such as example screens (A) and (B). This allows drivers to easily check the status of their own driver score when there are conditions (driver score thresholds) set for accepting offers for projects, and to easily consider what kind of projects to aim for (for example, increasing the number of challenge projects). As a result, driver growth can be further promoted.

[0261] In the example screen (D), the delivery request terminal 30 displays multiple candidate drivers for delivery on the display 332.

[0262] In the illustrated example, for packages that require a certain minimum driver score (entry restrictions) in order for a client to accept the delivery, the display unit 332G shows the driver score requirements, the location and score of each driver, and the loading location of the packages.

[0263] The control unit of the delivery request terminal 30 displays the requester's information on the display unit 332E.

[0264] The control unit of the delivery request terminal 30 displays the first driver candidate 332G1, the second driver candidate 332G2, the third driver candidate 332G3, and the cargo loading location 332GS on a map in the display unit 332G, thereby showing the positional relationship between these cargo loading locations and the location of each driver.

[0265] This makes it easier for clients to consider which driver to request delivery from, while referring to the driver's score.

[0266] The control unit of the delivery request terminal 30 accepts input operations at the operation reception unit 332H to display detailed information about each driver who has requested a delivery order.

[0267] The control unit of the delivery request terminal 30 receives input operations from the operation reception unit 332M and presents a screen to the requester that allows them to input information on the delivery status of packages that the requester has previously requested to be delivered (delivery request database 281) and the requester's user evaluation of the request.

[0268] The control unit of the delivery request terminal 30 accepts input operations to the operation reception unit 332K, thereby accepting operations to set delivery conditions for the cases displayed on the display unit 332G (delivery request database 281).

[0269] <Second Embodiment> <Summary of the second embodiment> In the first embodiment described above, the driver evaluation system involved the server 20 having a driver database 282 as shown in Figure 5, and calculating various driver scores (operation report, equipment, user evaluation, rule compliance, challenge) from this driver database 282 to ultimately calculate an overall driver score and evaluate the drivers.

[0270] In this embodiment, the server evaluates each driver based on the following four items as part of the driver evaluation system, and discloses at least a portion of these four items to the shipper requesting the delivery of goods. • Score: Determined each time a driver delivers a package, and accumulated as a performance score. • Badges… Drivers can earn badges by fulfilling the acquisition conditions that have been disclosed to them in advance. • Rank: Determined based on the delivery record of packages over a specified period. Recalculated after each specified period. • Quests… Drivers can earn quests by fulfilling the acquisition conditions, which have been disclosed to them in advance, within a specified period of time.

[0271] The server then grants the driver a reward based on their score and other factors. Preferably, the reward is one that reduces the costs required for the driver to deliver packages. For example, if the driver uses a vehicle to deliver packages, the reward could be a discount coupon for consumables used in the course of vehicle delivery, such as gasoline, oil, or maintenance packages.

[0272] Since the system of the second embodiment is substantially the same as system 1 of the first embodiment, the following explanation will focus on the differences.

[0273] <Functional configuration of Server 20> Figure 16 shows the functional configuration of server 20. As shown in Figure 2, server 20 functions as a communication unit 201, a storage unit 202A, and a control unit 203A.

[0274] The memory unit 202A stores various databases, including the delivery request database 281, the driver database 282A, the operation report database 283, the delivery source database 284, the incident report database 285, the rank table 286, the badge table 287, and the quest table 288.

[0275] Rank Table 286 is a table that describes the conditions for earning ranks when evaluating a driver's rank. Badge Table 287 is a table that describes the conditions for earning ranks that a driver can earn. Quest Table 288 is a table that describes the conditions for earning quests presented to drivers and the points earned when they earn them.

[0276] The control unit 203A is realized when the processor 29 reads a program stored in the memory unit 202 and executes instructions contained in the program. The control unit 203 operates according to the program and performs functions such as the reception control module 2041, transmission control module 2042, trained model generation module 2043, home rate estimation module 2044, delivery route determination module 2045, driver evaluation module 2046A, operation management module 2047, matching module 2048A, incident determination module 2049, and reward granting module 2050.

[0277] The driver evaluation module 2046A evaluates a driver's operational ability based on their delivery record.

[0278] The operation and function of the driver evaluation module 2046A in this embodiment are substantially the same as those of the driver evaluation module 2046 in the first embodiment. The differences will be explained below.

[0279] As already explained, the driver evaluation module 2046A evaluates each driver based on the following four items (evaluation axes), and discloses at least some of these four items to the shipper requesting the delivery of goods. • Score: Determined each time a driver delivers a package, and accumulated as a performance score. • Badges… Drivers can earn badges by fulfilling the acquisition conditions that have been disclosed to them in advance. • Rank: Determined based on the delivery record of packages over a specified period. Recalculated after each specified period. • Quests… Drivers can earn quests by fulfilling the acquisition conditions, which have been disclosed to them in advance, within a specified period of time.

[0280] Here, the score is substantially the same as the overall driver score calculated in the driver evaluation module 2046 of the first embodiment. The score is calculated and added for each delivery made by the driver. The score is added using a so-called cumulative method. The score may be accumulated indefinitely as long as the driver is receiving requests to deliver packages using System 1, but in this embodiment, it is the sum of the scores calculated for each individual delivery for the most recent predetermined number of deliveries (e.g., 10 deliveries).

[0281] As described later, the score calculated by the driver evaluation module 2046A is disclosed to shippers who are planning to request delivery of goods during the matching operation by the matching module 2048A. However, the evaluation values ​​disclosed to shippers are not limited to scores; any combination of evaluation values ​​may be disclosed to shippers. For example, the server 20 may disclose to shippers the badges of drivers who will enter the delivery request from the shipper, making it easier for shippers to specify the driver they want to request delivery from, while not disclosing the driver's score, rank, etc. to the shipper.

[0282] The overall driver score is calculated by the driver evaluation module 2046A by combining various driver scores (driving report, equipment, user evaluation, rule compliance, challenge), similar to the first embodiment.

[0283] In this embodiment, the driver evaluation module 2046A does not require that the driver score_user evaluation and driver score_equipment be used as the basis for calculating the driver score_overall. This is because the number of packages delivered for which user evaluation is performed may depend on the shipper, which could compromise the fairness of the cumulative driver score_user evaluation value. Furthermore, since the value of equipment remains unchanged once registered, a cumulative evaluation method may not be appropriate. However, user evaluation and equipment can be evaluated using evaluation axes other than the score.

[0284] If the overall driver score exceeds a predetermined value, the reward module 2050 will grant a reward to the driver whose score exceeds the predetermined value. Details will be described later.

[0285] Badges can be earned by a driver if they meet the predetermined acquisition conditions, specifically those described in Badge Table 287. The driver evaluation module 2046A makes a judgment for each individual condition, and the driver can earn a badge.

[0286] As described later, badges earned by the driver evaluation module 2046A are disclosed to shippers who are planning to request delivery of goods during the matching operation by the matching module 2048.

[0287] There are various badges and conditions for earning them, which are determined by the driver evaluation module 2046A. Some of these are disclosed in the badge table 287 shown in Figure 19, but as an example, the following badges may be available. • Usage Count Badge: Can be earned after completing a certain number of deliveries. Delivery assignments are categorized into several types, and badges can be earned after completing a certain number of deliveries for each individual type. • Skill Badges: These can be earned by categorizing delivery jobs into several types of destinations (construction sites, home delivery, food delivery, etc.) and completing a certain number of deliveries for each type of destination. • Hospitality Badge… Earnable when your driver score / user rating exceeds a certain threshold. • Equipment Badges… Earnable for each individual piece of equipment related to driver score. • Trouble-free badge: Earned if there are no driver score incidents within a specified period. • Driver Qualification Badge: Can be earned if you are qualified to handle delivery assignments from specific clients.

[0288] The badges you earn will be displayed on the driver terminal 10 screen. More details will follow.

[0289] The rank is determined by counting the number of trips made over a predetermined period, for example, each month. If the number of trips meets the acquisition conditions defined in rank table 286, the driver can acquire the corresponding rank. The reward module 2050 grants rewards to the driver according to the rank they have achieved. Details will be described later.

[0290] The driver evaluation module 2046A can update each driver's rank at regular intervals, for example, every three months. The rank each driver earns is based on their performance during these intervals, and rank increases, decreases, or maintenance occur in terms of advantageous rewards.

[0291] The ranks, conditions for earning them, and benefits determined by the driver evaluation module 2046A vary, some of which are disclosed in the rank table 286 shown in Figure 18. However, the details of the ranks, etc., are not limited to the example in Figure 18.

[0292] Quests are awarded when the driver fulfills the conditions set by Server 20 within a specified period determined by Server 20.

[0293] The driver evaluation module 2046A periodically, or after checking the driver's operational status, displays quests described in the quest table 288 on the screen of the driver terminal 10 and recommends that the driver complete the quests. Once it determines that the driver has met the conditions for completing the quest, the reward granting module 2050 grants the driver a reward in the form of points.

[0294] There are various types of quests, acquisition conditions, and points that can be determined by the driver evaluation module 2046A. Some of these are disclosed in the quest table 288 shown in Figure 20, but as an example, the following quests may exist. • New User Bonus: For those who register on Server 20 and complete a certain number of operations within a specified number of days. • Return Bonus: A bonus awarded for completing a certain number of restarts after a set number of days have passed since the last run. • Initial operation: The first operation of a specific project within the designated period, and the completion of the prescribed number of operations. • Operation accomplished… Multiple operations for a specific project were completed within the designated period. • Daily Achievement: Completed multiple runs of a specific project on a designated day. • Continued operation: Completed a certain number of runs each day of the week during the specified period. • Continuous login… Users who have viewed a certain number of projects each day of the week for a specified period. • Region… Complete a certain number of operations in a specific region. • Reward: Earn a certain amount of points within the specified period. • Online: The user has been online for a specified period of time or longer, meaning they have accessed Server 20.

[0295] Furthermore, when the driver evaluation module 2046A's evaluated score reaches a predetermined value, it exchanges this predetermined score for a ticket and reduces the current driver's score by this predetermined value. The driver evaluation module 2046A may exchange the score for a ticket at its own discretion (i.e., automatically) when the score reaches the predetermined value, or it may exchange the score at any time and set an expiration date for the ticket.

[0296] Tickets are, in a sense, a record of the score. As mentioned above, the score is a value accumulated from the scores calculated for each individual delivery over the most recent predetermined number of deliveries (e.g., 10 deliveries), and it fluctuates according to the driver's recent delivery status. For drivers, it is not always possible to maintain a high score solely through their own efforts, and fluctuations in the score value may be unavoidable. Therefore, it is preferable to maintain driver incentives by accumulating the score in a form different from the score (tickets) once the driver has raised it to a predetermined value, and by allowing drivers to enter projects with an upper limit on the number of drivers who can enter, as shown in Figure 13, based on the presence or absence of these tickets and the number of tickets.

[0297] The driver evaluation module 2046A can set an upper limit on the number of tickets that an individual driver may possess (which can be stored in the driver database 282A, described later). When a driver enters a designated job, the driver evaluation module 2046A deducts tickets for each entry. Tickets may or may not have an expiration date. The number of tickets required to enter a designated job may be determined for each job. Furthermore, when a driver enters a designated job, tickets may be consumed regardless of whether the driver accepts the job, or the number of tickets may be deducted only when the driver enters a designated job and accepts it (is designated by the shipper as the driver to perform the delivery).

[0298] The driver evaluation module 2046A converts scores into tickets, which will appear to increase or decrease the driver's score. From this perspective, it is preferable that the score calculated by the driver evaluation module 2046A is not disclosed to the shipper who is planning to request delivery of goods during the matching operation by the matching module 2048A.

[0299] Additionally, the driver evaluation module 2046A may evaluate the rank by taking into account the number of tickets acquired within a certain period (for example, one month).

[0300] The matching module 2048A matches the person requesting delivery (shipper) with the driver who will be performing the delivery.

[0301] In this embodiment, when presenting driver candidates to a client, the matching module 2048A refers to the driver database 282A and extracts matching candidates based on driver evaluation criteria such as score and rank. At this time, the matching module 2048A may also refer to the delivery request database 281, the delivery source database 284, etc., and extract the driver it considers to be best suited for the delivery of the requested package based on the attributes of the package and the driver's evaluation values ​​such as score and rank, and assign the package delivery to the driver. For example, if a package requires a specific piece of equipment, and only one driver among the candidate drivers has acquired the equipment badge related to that equipment, the package delivery may be assigned to this driver.

[0302] Furthermore, in the first embodiment described above, drivers with a score above a certain level were not displayed on the screen of the delivery requester terminal 30. However, this embodiment is not limited to this, and drivers to be displayed on the delivery requester terminal 30 may be extracted based on evaluation criteria other than score, or based on evaluation criteria other than score and score. For example, drivers who have earned all badges may be preferentially displayed on the delivery requester terminal 30.

[0303] In addition, when the matching module 2048A displays driver candidates on the screen of the delivery requester terminal 30, it may also display the evaluation axis values ​​for each driver on the screen. The requester may decide whether or not to accept the entry of the driver to be requested to make a delivery based not only on the score the driver has, but also on the type and number of badges.

[0304] The reward granting module 2050 grants rewards based on scores, badges, etc., determined by the driver evaluation module 2046A, as a reward for acquiring these scores, etc. Typical rewards include points (including values) linked to individual badges and quests, but other rewards such as the following may also be available. • Prioritization of job opportunities (compensation opportunities)...e.g., being able to apply for popular projects with good conditions, being given priority in project referrals, and having a higher chance of being selected. • Service benefits…Examples: lower insurance premiums, discounted maintenance, etc. • Financial benefits…e.g., lower fees • Provision of expenses incurred by drivers as a result of driving for each delivery, such as discount coupons, and especially items that are consumed during transportation by vehicle (gasoline, oil, maintenance packages, cleaning costs for uniforms and other items used for work). • Vehicle-specific benefits... e.g., insurance, ETC terminal, etc. • Consumable items provided during package delivery…e.g., work gloves, sunscreen, or discount coupons.

[0305] As described above, the benefits granted by the benefit granting module 2050 are reflected in the matching operation of the matching module 2048A.

[0306] <Data structure> Figures 17 to 20 show the data structure of a database stored by server 20 that is different from that of server 20 in the first embodiment. Note that Figures 17 to 20 are examples and do not exclude any data not shown.

[0307] Figure 17 shows the data structure of the driver database 282A. Each record in the driver database 282A includes the following fields: "Driver ID", "Driver Name", "Location", "Operating Hours", "Vehicle Type", "Driver Score_Operation Report", "Driver Score_Equipment", "Driver Score_User Rating", "Driver Score_Rule Compliance", "Driver Score_Challenge", "Driver Score_Overall", "Driver_Badge", "Driver_Rank", "Driver_Quest", and "Driver_Ticket".

[0308] Of these records, all except "Driver_Badge," "Driver_Rank," and "Driver_Quest" are common to the records in driver database 282 shown in Figure 5, so their explanation here will be omitted.

[0309] "Driver_Badges" displays information about badges earned by drivers based on their driving performance. Specific details will be explained when describing Badge Table 287. "Driver_Rank" displays information about the rank earned by drivers based on their driving performance. Specific details will be explained when describing Rank Table 286. "Driver_Quests" displays information about quests earned by drivers based on their driving performance. Specific details will be explained when describing Quest Table 288. "Driver_Tickets" is information about the number of tickets currently held by the driver.

[0310] Figure 18 shows the data structure of rank table 286. Each record in rank table 286 includes the fields "Rank", "Rank ID", "Acquisition Conditions", "Insurance", "Maintenance", and "Transfer Fee".

[0311] The "Rank" field contains information indicating the name of the rank. The "Rank ID" field contains information used to identify the rank.

[0312] The "Acquisition Conditions" section contains information about the conditions for acquiring the rank identified by the rank ID. In the example shown in Figure 18, the acquisition condition for each rank is described as whether the number of monthly operations is above a certain number. Here, A ≤ B ≤ C. In other words, from the perspective of the difficulty of the acquisition conditions, the conditions for acquiring the Bronze rank are the easiest, and the conditions become progressively stricter as you move up to Silver and then Gold.

[0313] The item "Insurance" contains information about insurance, which is an example of a benefit granted upon achieving a rank identified by the rank ID. In the diagram, "○" indicates that drivers who have achieved a rank identified by the rank ID are covered by insurance for their actions during transport, with at least a portion of the costs borne by the operator of System 1. "Points Back" refers to points, which are an example of a benefit granted to drivers each time they achieve a rank (whether or not a rank has been achieved and which rank has been achieved is determined at regular intervals). Here, D ≤ E.

[0314] The item "Maintenance" provides information about maintenance, which is an example of a benefit granted upon achieving a rank identified by the rank ID. In the diagram, "Maintenance Package" indicates that a vehicle maintenance package is provided as a benefit to drivers who have achieved their individual ranks, with at least a portion of the costs borne by the System 1 operator. "Loaner Vehicle" indicates that if a driver's vehicle requires repair due to breakdown, accident, etc., a loaner vehicle will be provided during the repair period, with at least a portion of the costs borne by the System 1 operator. Furthermore, "Maintenance Package Discount" indicates that the cost burden on the System 1 operator associated with the provision of a maintenance package is greater than for Bronze and Silver ranks.

[0315] The item "Transfer Fee" is an example of a benefit granted by achieving a rank identified by the rank ID. It concerns the transfer fee paid by the System 1 operator to the driver when transferring payment for the service to the driver's account. In the diagram, "No preferential treatment" indicates that there is no preferential treatment (benefit) regarding transfer fees. Also, "Number of transfers × ○ points" indicates the points that will be used to cover the transfer fee when a bank transfer is made (the conversion rate between points and yen is predetermined). Here, F ≤ G.

[0316] The driver evaluation module 2046A determines the driver's rank by referring to the "Acquisition Conditions" in the rank table 286, and as a result, writes the "Rank ID" of the corresponding rank to the "Driver_Rank" item in the driver database 282A. The reward granting module 2050 then grants the driver the rewards described in the "Insurance" item, etc., based on the "Rank ID" written in the "Driver Score_Rank" item in the driver database 282A.

[0317] Figure 19 shows the data structure of the badge table 287. Each record in the badge table 287 includes the fields "Badge ID", "Badge Name", and "Acquisition Condition".

[0318] The "Badge ID" field is information used to identify a badge. The "Badge Name" field is the name of the badge identified by the Badge ID. The "Acquisition Conditions" field is information about the conditions required to acquire the badge identified by the Badge ID.

[0319] The driver evaluation module 2046A periodically checks the driver's driving record and determines whether this driving record satisfies the conditions described in the "Acquisition Conditions" section of the badge table 287. If it determines that the acquisition conditions are met, the driver evaluation module 2046A writes the "Badge ID" of the corresponding badge to the "Driver_Badge" item in the driver database 282A.

[0320] Figure 20 shows the data structure of Quest Table 288. Each record in Quest Table 288 includes the fields "Quest ID", "Quest Name", "Quest Completion Conditions", and "Points".

[0321] The "Quest ID" field is information used to identify a quest. The "Quest Name" field is the name of the quest identified by the Quest ID. The "Quest Completion Conditions" field is information about the conditions required to complete the quest identified by the Quest ID. The "Points" field is information about the number of points awarded by the Reward Module 2050 upon completion of the quest completion conditions.

[0322] The driver evaluation module 2046A periodically checks the driver's operational performance and extracts candidate quests to present to the driver from the quest table 288 based on this performance. The driver evaluation module 2046A then determines whether the driver's operational performance satisfies the conditions described in the "Quest Completion Conditions" section of the quest table 288. If it determines that the completion conditions have been met, the driver evaluation module 2046A writes the "Quest ID" of the corresponding quest to the "Driver_Quest" item in the driver database 282A, and the reward granting module 2050 grants the driver the number of points described in the "Points" section of the quest table 288 as a reward.

[0323] <Screen example> Figure 21 shows an example of a screen provided to the driver by the driver terminal 10.

[0324] The example screen (A) in Figure 15 shows a scene in the driver terminal 10 where the driver is presented with the badges he has earned.

[0325] Screen example (B) is a diagram showing the driver terminal 10 presenting the driver with a list of quest options.

[0326] The control unit 190 displays UI (User Interface) components on the display 132 for presenting the driver score to the driver.

[0327] In the example screen (A), the control unit 190 displays images on the badge display unit 132G showing the badges the driver has earned and images showing the badges the driver has not yet earned.

[0328] Specifically, the control unit 190 displays the type of badge the driver has acquired and the number of badges acquired in the acquired badge display unit 132G1. In the illustrated example, the driver has acquired the "Usage Count Badge" (indicated by hatching in the figure), and it is also shown that the driver has acquired 10 "Usage Count Badges".

[0329] Furthermore, the control unit 190 displays the types of badges that the driver has not yet earned in the unearned badge display unit 132G2. In the illustrated example, it shows that the driver has not yet earned the "Hospitality Badge" (this is indicated by a blank space in the figure).

[0330] In example screen (B), the control unit 190 displays the candidate quests and completion conditions presented to the driver in the quest display unit 132H.

[0331] Specifically, the control unit 190 displays the completion deadline for the proposed quest candidates in the quest deadline display unit 132H1. The control unit 190 also displays the proposed quests to be presented to the driver and the operational performance conditions required to complete the quests in the quest candidate display unit 132H2. <Effects of the Embodiment>

[0332] According to System 1 of this embodiment described above, various evaluation values ​​(score, badge, etc.) of the driver, which are the evaluation results from the driver evaluation module 2046A, are disclosed to the client when matching the client with a driver using the matching module 2048A. Therefore, the client can select a driver to deliver their goods by referring to these evaluation values ​​as well. Since the client selects a driver by referring to the evaluation values, the driver will perform daily transportation jobs and accumulate transportation experience in order to raise these evaluation values ​​to favorable values. This also serves as an incentive for the driver to accumulate transportation experience that will raise their evaluation values ​​to favorable values. Therefore, by appropriately setting various evaluation values, it is possible to increase incentives for the driver, and at the same time, the operator of System 1 can guide the driver's job selection, job acquisition, and transportation behavior in a direction favorable to the operator.

[0333] Two aspects of what is meant by "desirable direction" are (1) active use of System 1 by registered drivers, and (2) continued use of System 1 by registered drivers. Badges and quests are valid evaluation values ​​from the perspective of (1), and quests and ranks are valid evaluation values ​​from the perspective of (2). Furthermore, scores are valid evaluation values ​​from the perspectives of both (1) and (2).

[0334] Thus, performing a multifaceted driver evaluation as in this embodiment, in addition to the score-based driver evaluation in the first embodiment, is preferable from the standpoint of encouraging the operator of System 1 to actively and continuously use System 1.

[0335] Furthermore, ranks are recalculated at regular intervals, resulting in rank increases, decreases, or rank maintenance, which incentivizes drivers to increase their transport performance. In addition, obtaining all badges grants priority in receiving orders, further incentivizing drivers from this perspective.

[0336] Furthermore, according to System 1 of this embodiment, drivers are given rewards based on their performance evaluation. This also serves as an incentive for drivers. In addition, the rewards include those that can reduce the costs required for drivers to deliver goods, such as gasoline discount coupons, making them an attractive incentive for drivers who use vehicles to deliver goods.

[0337] <Variation> In addition to what has been described in the embodiments above, the following may also be done.

[0338] Server 20 may refer to the driver database 282 and grant rewards to drivers based on the duration for which they have maintained a driver score above a certain level. This can encourage drivers to maintain a high driver score.

[0339] Server 20 may grant drivers rewards according to a multi-tiered ranking system based on the length of time they maintain a certain driver score (the longer the period, the higher the rank). As a reward for drivers, Server 20 may also provide other income opportunities besides accepting delivery orders if the period of time the driver score is above a certain level is less than a certain period, and provide other income opportunities such as advertising revenue and training for new drivers if the period exceeds a certain period.

[0340] For example, as a way to generate advertising revenue, the system may allow drivers to project or affix advertisements to the exterior of the vehicles they use for deliveries (vehicle casing, windows, etc.). For instance, the windows themselves could be used as signage to display advertising videos visible from outside the vehicle. Server 20 may, for example, restrict the types of advertisements that can be displayed based on the driver's score. For example, the higher the driver's score, the more expensive the advertising video they can display. As drivers maintain a certain level of performance, the quality of vehicle operation can be expected to be above a certain level, potentially improving the effectiveness of advertising.

[0341] For example, as part of training for new drivers, a driver who maintains a good performance rating could be offered the opportunity to ride along with the new driver on their deliveries for training purposes. Server 20 could then reward the driver who maintains a good performance rating with compensation for the training itself, as well as compensation based on the delivery performance of the trained driver. This could further improve the number and quality of drivers participating in the delivery service provided by Server 20.

[0342] Additionally, the above benefits may include the ability for drivers to use welfare facilities and access insurance.

[0343] While several embodiments of this disclosure have been described above, these embodiments can be implemented in a variety of other forms, and various omissions, substitutions, and modifications are permitted without departing from the spirit of the invention. These embodiments and their variations are included in the scope and spirit of the invention, as well as in the claims and their equivalents.

[0344] <Note> The details described in each of the above embodiments are noted below.

[0345] <Note 1> A program for operating a computer (10, 20) that provides a service matching shippers who request the delivery of goods with drivers who are responsible for delivering those goods, the program causing the computer's processor to perform the following steps: present information about the goods that the shipper requests delivery of to each driver; disclose to the shipper a list of candidates for drivers to whom the shipper requests delivery of goods (2048A); record the driver's record of making deliveries based on the delivery request (281); identify the history of deliveries based on the driver's delivery record (281); and determine a first evaluation parameter for the driver matching service based on the identified result (2046A, 282A), wherein in the identification step (281), the driver's delivery record is based on a predetermined number of the driver's most recent runs rather than the record of the most recent predetermined number of days, and in the disclosure step (2048A), the program discloses the first evaluation parameter for each candidate driver to the shipper. <Note 2> The program described in Appendix 1, wherein in the determination step (2046A, 282A), a third evaluation parameter is calculated based on at least one requirement from the group consisting of the delivery history over a predetermined number of times, the delivery history disclosed to the driver in advance, the number of deliveries made within a predetermined period, and the delivery history disclosed to the driver in advance within a predetermined period, and the first evaluation parameter is determined based on the calculated third evaluation parameter. <Note 3> In the decision-making step (2046A, 282A), the program described in Appendix 2 calculates a third evaluation parameter based on the number of deliveries made under specific delivery conditions within a predetermined period once a predetermined period has elapsed. <Note 4> The program is one of the programs described in any of Appendix 1 to 3, which further performs the step (2048A) of having the computer processor determine the driver to make the delivery based on a first evaluation parameter and delivery-related attributes. <Note 5> In the step of prompting, on the condition that the first evaluation parameter is greater than or equal to a predetermined value, the information of the package is provided by the program described in any one of Appendices 1 to 4 that enables the driver to prompt an order offer. <Appendix 6> In the step of specifying, at least any one of the following deliveries is specified based on the history by the program described in any one of Appendices 1 to 5: the delivery is within a predetermined number of times since the requester who requests the delivery starts the request in the service; there is an instruction regarding the delivery when collecting the package from the requester who requests the delivery; there is a request for one or more package deliveries within a certain time from the requester of the delivery; the package for which the delivery is requested by the requester of the delivery is a package for which the delivery is made in a specific service; the service corresponds to a shopping proxy service and is a delivery accompanying the shopping proxy. <Appendix 7> In the step of prompting, the information of the package for which the delivery is requested includes the first package information that sets an upper limit on the number of drivers who can offer to accept the order for the delivery of the package. For the first package for which the upper limit is set, the information of the first package is preferentially presented so that the driver with good first evaluation parameter or the history of the first evaluation parameter can offer to accept the order, by the program described in any one of Appendices 1 to 6. <Appendix 8> In the step of determining (2046A, 282A), the second evaluation parameter is specified by evaluating at least any one of the following: whether an operation report has been made by the driver based on a predetermined standard in the driver's past predetermined number of deliveries; whether the vehicle for which the driver makes the delivery has prepared predetermined equipment; whether the evaluation from the user of the delivery origin or destination to the driver in the driver's past predetermined number of deliveries is above a certain level; whether a predetermined incident has occurred in the driver's past predetermined number of deliveries. The first evaluation parameter is determined by the second evaluation parameter and the third evaluation parameter, by the program described in Appendix 2. <Appendix 9> The program is one of the programs described in any of Appendix 1 to 7, which causes the computer's processor to perform a step (2050) of granting a driver a benefit based on a first evaluation parameter. <Note 10> In the granting step (2050), the benefit is the program described in Appendix 8, which is a benefit that can reduce the costs required for drivers to deliver packages. <Note 11> A method for operating a computer (10, 20) that provides a service matching a shipper who requests the delivery of goods with a driver who is responsible for delivering the goods, the method comprising: a computer processor performing the steps of: presenting information of the goods that the shipper requests the delivery of to each driver; disclosing candidates for the driver that the shipper requests the delivery of to the shipper (2048A); recording the driver's record of making deliveries based on the delivery request (281); identifying the history of deliveries based on the driver's delivery record (281); and determining a first evaluation parameter in the driver matching service based on the identified result (2046A, 282A), wherein in the identification step (281), the delivery record of deliveries is identified not based on the driver's record for the most recent predetermined number of runs, but based on the driver's record for the most recent predetermined number of runs, and in the disclosure step (2048A), the first evaluation parameter for each candidate driver is disclosed to the shipper. <Note 12> Information processing device (10, 20) that provides a service matching a shipper who requests the delivery of goods with a driver who is responsible for delivering the goods, wherein the control unit of the information processing device performs the following steps: presenting information of the goods that the shipper requests the delivery of to each driver; disclosing candidate drivers to the shipper who is requested to deliver the goods (2048A); recording the driver's record of making deliveries based on the delivery request (281); identifying the history of deliveries based on the driver's delivery record (281); and determining a first evaluation parameter in the driver matching service based on the identified result (2046A, 282A), wherein in the identification step (281), the driver's delivery record is identified not based on the record of the most recent predetermined number of deliveries, but based on the driver's record of the most recent predetermined number of deliveries, and in the disclosure step (2048A), the first evaluation parameter for each candidate driver is disclosed to the shipper. [Explanation of Symbols]

[0346] 1: System, 10: Driver terminal, 13: Input device, 14: Output device, 15: Memory, 16: Storage, 19: Processor, 20: Server, 25: Memory, 26: Storage, 29: Processor, 30: Delivery requester terminal, 80: Network, 111: Antenna, 112: Antenna, 120: First communication unit, 121: Second communication unit, 130: Input device, 131: Device, 132: Display, 132A: Attribute information reception unit, 132B: Delivery operation reception unit, 132C: Delivery destination display unit, 132D: Information display unit, 132E: Driver information display unit, 132F: Delivery route display unit, 140: Voice processing unit, 141: Microphone, 142: Speaker, 150: Location information sensor, 160: Camera, 170: Motion sensor, 180: Memory unit, 181: Delivery management application, 190: Control unit, 191: Operation reception unit, 192: Transmit / receive unit, 193: Data processing unit, 194: Notification control unit, 195: Memory control unit, 201: Communication unit, 202: Memory unit, 203: Control unit, 281: Delivery request database, 282, 282A: Driver database, 283: Operation report database, 284: Delivery source database, 286: Rank table, 287: Badge table, 288: Quest table, 2041: Reception control module, 2042: Transmission control module, 2043: Model generation module, 2044: Home rate estimation module, 2045: Delivery route determination module, 2046, 2046A: Driver evaluation module, 2047: Operation management module, 2048, 2048A: Matching module, 2049: Incident judgment module, 2050: Reward granting module.

Claims

1. A program for operating a computer equipped with a processor, The memory unit is configured to store information on the conditions for acquiring badges that drivers can earn when they meet the acquisition conditions disclosed to them in advance, and information on the drivers' user delivery performance. The program is provided to the processor: The driver's user is presented with the conditions for earning the badge, which are determined based on delivery performance. Based on the delivery performance information of the driver's users, if the conditions for acquiring the badge are met, the step of storing the badge in the storage unit as having been acquired by the driver's user; The steps include presenting the driver's user with information about the badges the user of the driver has acquired, A program that causes a shipper requesting the delivery of goods to perform the following steps: disclose information about the badges that drivers who apply to accept delivery requests from the shipper have earned by meeting the aforementioned acquisition conditions.

2. A method performed by a computer equipped with a processor, The memory unit is configured to store information on the conditions for acquiring badges that drivers can earn when they meet the acquisition conditions disclosed to them in advance, and information on the drivers' user delivery performance. The above method involves the processor, The driver's user is presented with the conditions for earning the badge, which are determined based on delivery performance. Based on the delivery performance information of the driver's users, if the conditions for acquiring the badge are met, the step of storing the badge in the storage unit as having been acquired by the driver's user; The steps include presenting the driver's user with information about the badges the user of the driver has acquired, A method comprising the steps of: disclosing to a shipper who requests the delivery of goods information information on the badges that drivers who apply for delivery requests from the shipper have earned by fulfilling the aforementioned acquisition conditions.

3. An information processing device, The memory unit is configured to store information on the conditions for acquiring badges that drivers can earn when they meet the acquisition conditions disclosed to them in advance, and information on the drivers' user delivery performance. The control unit of the information processing device, The driver's user is presented with the conditions for earning the badge, which are determined based on delivery performance. Based on the delivery performance information of the driver's users, if the conditions for acquiring the badge are met, the step of storing the badge in the storage unit as having been acquired by the driver's user; The steps include presenting the driver's user with information about the badges the user of the driver has acquired, An information processing device that performs the steps of disclosing to a shipper who requests the delivery of goods information about the badges that drivers who apply for delivery requests from the shipper have earned by fulfilling the aforementioned acquisition conditions.

Images