Delivery support system

Abstract

To provide a system for increasing the chances of easily acquiring requests from other delivery destination stores having attributes similar to a given delivery destination store.SOLUTION: A delivery support system is provided, comprising: a request acquisition unit for acquiring a request from a delivery destination store; an identification unit for identifying the type of the request from among a plurality of types based on the request; and an acquisition unit configured to acquire same-attribute stores having an attribute identical to an attribute associated with the delivery destination store on the basis of the type of the request, and associate request information representing the request to each of the same-attribute stores and delivery destination store.SELECTED DRAWING: Figure 1

Description

[Technical field]

[0001] The present invention relates to a delivery assistance system. [Background technology]

[0002] Conventionally, a system for supporting delivery in a vehicle is known. For example, Patent Document 1 discloses a configuration in which a display unit displays the work contents (e.g., requests for the designation of the place to put the delivery item, etc.) for each customer when a delivery person works at a delivery destination. [Prior art documents] [Patent documents]

[0003] [Patent Document 1] JP 2015-224958 A Summary of the Invention [Problem to be solved by the invention]

[0004] As mentioned above, the business contents for each customer (i.e., the requests for each delivery destination) require manual addition of the request contents each time a request is made, which is time-consuming. For example, a similar request may occur at another delivery destination with similar attributes to a given delivery destination, but it is difficult to manually find the other delivery destination from the many delivery destinations.

[0005] The present invention has been made in consideration of the above-mentioned problems, and aims to provide a system that increases the possibility of easily acquiring requests from other delivery destination stores that have similar attributes to a specified delivery destination store. [Means for solving the problem]

[0006] In order to achieve the above-mentioned objective, the delivery support system includes a request acquisition unit that acquires requests from delivery destination stores, an identification unit that identifies the type of request from among multiple types based on the request, and an acquisition unit that acquires same-attribute stores having the same attributes as the attributes associated with the delivery destination store based on the type of request, and associates request information indicating the request with each of the same-attribute stores and the delivery destination store.

[0007] That is, in the delivery support system, same-attribute stores having the same attributes as the attributes associated with the delivery destination store are acquired, and request information indicating the same request is associated with each of the same-attribute stores and the delivery destination stores. This makes it possible to associate a request with a same-attribute store having the same attributes even before acquiring a request for the same-attribute store. In other words, since the same-attribute store has the same attributes as the delivery destination store, it is considered that there is the same request, and the request is associated with the same-attribute store. This saves the effort of associating requests compared to manually associating requests each time a request is made at each store, such as a same-attribute store, and as a result, it is possible to increase the possibility of easily acquiring requests from other delivery destination stores having attributes similar to the delivery destination store. [Brief description of the drawings]

[0008] [Figure 1] FIG. 1 is a block diagram showing a configuration of a delivery support system. [Diagram 2] FIG. 11 is a diagram illustrating an example of delivery plan information. [Diagram 3] FIG. 11 is a diagram showing an example of delivery destination store information. [Figure 4] FIG. 11 is a diagram showing an example of requested non-applicable condition information. [Diagram 5] 13 is a flowchart showing an example of a delivery support process. [Figure 6] 13 is a flowchart showing an example of a requested information guidance process. [Figure 7] FIG. 13 is a diagram showing an example of a display of a guide to requested information. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0009] Here, the embodiments of the present invention will be described in the following order. (1) System configuration: (1-1) Administrator terminal configuration: (1-2) Configuration of the shipper terminal: (1-3) Configuration of delivery support system: (2) Shipping support processing: (3) Other embodiments:

[0010] (1) System configuration: FIG. 1 is a block diagram showing the configuration of a delivery support system 10 according to the present invention. In this embodiment, an administrator belonging to a management company that manages multiple vehicles (e.g., delivery vehicles such as trucks) creates a delivery plan for each delivery vehicle and presents the created delivery plan to the delivery vehicle. In this embodiment, each delivery vehicle travels according to a planned driving route included in delivery plan information indicating the delivery plan. A deliverer (driver of the delivery vehicle) loads multiple packages onto the delivery vehicle at a departure point. In addition, the deliverer drives the delivery vehicle to go to a delivery destination store (hereinafter referred to as a delivery destination store) in the arrival order determined in the delivery plan information, and delivers the packages to a shipper (consignee) at the delivery destination store. In this embodiment, there may be multiple deliverers who are the drivers of the vehicles, and there may also be multiple delivery vehicles, but the following example will be mainly described with a focus on one deliverer and one delivery vehicle.

[0011] As shown in FIG. 1, in this embodiment, the delivery support system 10 cooperates with a deliverer terminal 100 and an administrator terminal 200 via communication. The deliverer terminal 100 is a terminal used by a deliverer (driver) who drives a delivery vehicle. In this embodiment, the deliverer terminal 100 may be portable or may be mounted on a delivery vehicle, and may be in any form. In this embodiment, the delivery vehicles driven by each of the multiple deliverers are determined in advance, and the delivery destination stores to be visited by each delivery vehicle and the order of visits, and the packages to be delivered to each delivery destination store are determined in advance. The administrator terminal 200 is a terminal used by an administrator who manages the delivery plan. The administrator creates a delivery plan using the administrator terminal 200, and the deliverer terminal 100 provides guidance for making deliveries according to the delivery plan. The deliverer terminal 100 periodically transmits the current location of the delivery vehicle to the delivery support system 10.

[0012] (1-1) Administrator terminal configuration: The administrator terminal 200 is a terminal used by an administrator who manages the operation of multiple vehicles. The administrator terminal 200 includes a control unit 210 including a CPU, RAM, ROM, etc., and a communication unit 220 for communicating with other devices. The administrator terminal 200 also includes a user I / F unit 230 for providing various information to the administrator and accepting input from the administrator. The user I / F unit 230 not only accepts input from the administrator, but also includes a display unit consisting of a display such as a touch panel (not shown), an input unit such as a switch, and an audio output unit such as a speaker, for providing various information to the administrator.

[0013] In this embodiment, the control unit 210 can communicate with the delivery support system 10 via the communication unit 220. The control unit 210 can execute a program recorded in a recording medium (not shown). The program includes a program for generating delivery plan information indicating a delivery plan for each vehicle.

[0014] Fig. 2 is a diagram showing an example of delivery plan information in this embodiment. The delivery plan information is information showing a delivery plan for each of multiple delivery vehicles, and for example, an administrator generates a delivery plan using the administrator terminal 200. Fig. 2 shows delivery plan information for a vehicle ID (e.g., "1001") among multiple delivery vehicles.

[0015] In this embodiment, the starting point S and the final destination G are the same, and these points are bases where the vehicle is loaded with goods. In the example shown in Fig. 2, a deliverer who delivers by vehicle moves the vehicle from the starting point S to the delivery destination stores G1, G2, G3, G4, and G5, and then to the final destination G. In other words, the order of arrival at the delivery destination stores is G1, G2, G3, G4, and G5 in order of earliest arrival.

[0016] Each delivery destination store is associated with its identification information (location name in this embodiment). Each delivery destination store is also associated with identification information (D1, etc.) of the cargo to be unloaded. Furthermore, each delivery destination store is associated with an expected arrival time, which is the expected time of arrival at the delivery destination store, and an expected departure time, which is the expected time of departure from the delivery destination store.

[0017] In addition, the delivery plan information is associated with the arrival time, which is the time when the delivery vehicle actually arrives at each delivery destination store, and the departure time, which is the time when the delivery vehicle actually departs from each delivery destination store. As described above, the delivery plan information is mainly generated by the administrator terminal 200, and the generated delivery plan information is transmitted to the delivery support system 10. The arrival time and departure time of the delivery vehicle are recorded when the delivery vehicle actually arrives at and departs from each delivery destination store, and the arrival time and departure time are recorded, for example, by the delivery support system 10. Specifically, for example, information on the current location of the delivery vehicle is periodically transmitted from the deliverer terminal 100 to the delivery support system 10, and the delivery support system 10 identifies the arrival of the delivery vehicle at the delivery destination store and the departure of the delivery vehicle from the delivery destination store from the information on the current location, and records the arrival time and departure time of each in the delivery plan information. The example shown in FIG. 2 shows a state in which there is a track record of arrival and departure for store a and store b.

[0018] Furthermore, the delivery plan information includes a planned driving route. The planned driving route is a route obtained by searching for a route with each delivery destination store as a destination based on map information (not shown) in the manager terminal 200. FIG. 2 shows an example in which the planned driving route is a permutation of nodes (nodes are Nx (x is a number indicating a node)). Of course, the planned driving route may be defined in various ways, and may be a permutation of links, etc. The arrival time may be determined based on the planned driving route.

[0019] In this embodiment, the manager specifies the delivery destination stores, the arrival order of each delivery destination store, and the cargo to be handled at each delivery destination store in the manager terminal 200. When the specification is made, the manager terminal 200 searches for a planned driving route based on map information (not shown) and obtains the arrival time to generate delivery plan information. The generated delivery plan information is transmitted to the delivery support system 10. Note that such generation of the delivery plan information is one example, and for example, at least a part of the information in FIG. 2 may be generated by the manager terminal 200, and the remaining information including the arrival time and departure time may be generated by the delivery support system 10. In addition, the delivery plan information may be generated, for example, by solving a delivery plan problem using various algorithms to specify a delivery order, and then specifying a planned driving route for going to the delivery destination store according to the delivery order to generate the delivery plan information.

[0020] (1-2) Configuration of the shipper terminal: The deliverer terminal 100 is a terminal used by each deliverer, and in this embodiment, is mounted on a vehicle. The deliverer terminal 100 is equipped with a control unit 110 equipped with a CPU, RAM, ROM, etc., a communication unit 120, a user I / F unit 130, and a recording medium 140. The user I / F unit 130 is an interface unit for inputting instructions from the deliverer (driver) and providing various information to the deliverer, and is equipped with a display unit consisting of a touch panel display (not shown), an input unit such as a switch, and an audio output unit such as a speaker.

[0021] The communication unit 120 is a device for communicating with other devices. In this embodiment, the control unit 110 can communicate with the delivery support system 10 via the communication unit 120. The control unit 110 can execute a program (not shown). In this embodiment, information indicating a delivery plan transmitted from the delivery support system 10 is displayed on the display of the user I / F unit 130. Details of the contents of the displayed screen will be described later.

[0022] Various information can be recorded in the recording medium 140. In this embodiment, delivery plan information 140a and map information 140b are recorded. The delivery plan information 140a is a part of the delivery plan information generated by the above-mentioned manager terminal 200. That is, the delivery plan information generated by the manager terminal 200 is transmitted to the delivery support system 10 and recorded. The delivery support system 10 extracts information for each vehicle from the recorded delivery plan information and transmits it to each vehicle. The delivery plan information 140a recorded in the recording medium 140 is a delivery plan for a vehicle equipped with a deliverer terminal 100 equipped with the recording medium 140. That is, the delivery plan information 140a only needs to indicate a delivery plan for each delivery vehicle, and does not need to include delivery plans for other delivery vehicles.

[0023] In addition, the delivery plan information 140a for the work day may be obtained in one lump sum from the delivery support system 10 before the vehicle departs, or the necessary information may be transmitted sequentially from the delivery support system 10 when it becomes necessary.

[0024] The map information 140b is information used for searching for a route and identifying the vehicle's position, and includes node data indicating the positions of nodes set on the road on which the vehicle travels, shape interpolation point data indicating the positions of shape interpolation points for identifying the shape of the road between the nodes, link data indicating the connections between the nodes, and facility data indicating the positions and attributes of facilities existing on the road and in its surroundings. The facility data includes facilities that can be delivery destination stores. In this embodiment, the map information 140b also includes information for drawing the facilities indicated by each facility data, the road sections indicated by the link data, and the roads indicated by the node data.

[0025] The control unit 110 can realize various functions by executing a program (not shown) recorded in the recording medium 140. In this embodiment, the control unit 110 acquires the current position of the delivery vehicle and provides route guidance by a program (not shown). The control unit 110 periodically acquires the current position of the delivery vehicle based on the output of a GNSS receiving unit (not shown), and transmits the acquired information on the current position to the delivery support system 10 via the communication unit 120. Then, the control unit 110 acquires a map on which a request and a planned driving route for a delivery destination store (described later) are superimposed from the delivery support system 10, and performs route guidance by displaying the acquired map on the display unit of the user I / F unit 130.

[0026] (1-3) Configuration of delivery support system: The delivery support system 10 includes a control unit 20 equipped with a CPU, RAM, ROM, etc., a recording medium 30, and a communication unit 40. The communication unit 40 includes a circuit for transmitting and receiving information to and from a deliverer terminal 100 and an administrator terminal 200. The control unit 20 can communicate with the deliverer terminal 100 and the administrator terminal 200 via the communication unit 40.

[0027] Delivery destination store information 30a, requested non-applicable condition information 30b, map information 30c, and delivery plan information 30d are recorded in the recording medium 30. Delivery destination store information 30a indicates information on each delivery destination store, and in the example shown in Fig. 3, information on location, availability of parking space, number of parked cars, requests, types of requests, and attributes is recorded in association with each delivery destination store (location name).

[0028] The location indicates the location information of the delivery destination store. In the example shown in FIG. 2, for example, for store a, the store identification information (S A ) and coordinates (X A ,Y B ) is matched with "S A (X A ,Y B )" is displayed.

[0029] The presence or absence of a parking lot indicates whether or not a parking lot exists at the delivery destination store, and if the delivery destination store has a parking lot, the information "Yes" is associated with it, and if the delivery destination store does not have a parking lot, the information "No" is associated with it. For example, the presence or absence of a parking lot at store A is "Yes."

[0030] The number of parking spaces indicates the number of cars that can be parked at the delivery destination store, and is indicated by a number of "1" or more if the above-mentioned parking lot is "yes," and is indicated by "0" if the above-mentioned parking lot is "no." For example, the number of parking spaces at store A is "5."

[0031] The request indicates a request to the delivery destination store. This request includes requests from employees of the delivery destination store, requests from residents in the neighborhood of the delivery destination store, and other requests directed to the delivery destination store. Specifically, the request information is assumed to be, for example, "delivery work is noisy," "quiet," "no parking on the road," and the like. The request information is input, for example, by the deliverer operating the user I / F unit 130 (direct input, voice input, etc.), and the control unit 110 of the deliverer terminal 100 associates the input information with the identification information of the delivery destination store and transmits the request information from the deliverer terminal 100 to the delivery support system 10. The transmitted request information is then recorded in the recording medium 30 as part of the delivery destination store information 30a. Note that the request information may also be recorded in the recording medium 30 by being transmitted to the delivery support system 10 from an external center (not shown) that accepts requests. In the example shown in FIG. 3, the request at store a is associated with information on "delivery work is noisy."

[0032] The type of request defines the type of the above-mentioned "request." For example, for requests such as "delivery work is noisy," "quiet," and other requests such as "noisy" and "buzzing," "noise" is defined as the type of request. For requests such as "no parking on the road," "obstruction of vehicles," and "cannot pass," "no parking" is defined as the type of request. This type of request is specified by the control unit 20, for example, based on a table (not shown) in which keywords such as "quiet" and "buzzing" that can be predicted as requests are associated with each type of request such as "noise." The control unit 20 may specify the type of request using a machine learning model such as Word2Vec. The type of request specified by the control unit 20 is then recorded as part of the delivery destination store information 30a.

[0033] Attributes indicate the characteristics of a delivery destination store, and are defined so that features that may generate the same request (for example, a request to be careful about noise during delivery) are the same attribute. In this embodiment, the attributes are particularly defined for the geographical attributes of the delivery destination store. Geographical attributes are attributes that can be identified based on map information, such as the distance to a residential area being less than a preset distance, there being no parking lot (or there is a parking lot), and the road width being less than a preset width. In FIG. 3, for example, store A is associated with the attributes "has parking lot" and "the distance to a residential area is less than a preset distance (for example, 200 m)."

[0034] The request non-applicable condition information 30b is information indicating conditions (non-applicable conditions) for which the above-mentioned requests are not applied; that is, a request that would normally be a request of a delivery destination store may not be a request of the delivery destination store if a certain condition is met. Non-applicable conditions are predefined according to the type of request. For example, as shown in FIG. 4, for the type of request "noise," conditions such as "near a main road," "near a factory," and "near an airport" are defined as non-applicable conditions. Note that a main road refers to, for example, an expressway or a general road (national or prefectural road). In other words, if the attributes of a delivery destination store include "near a main road," the delivery destination store may be excluded from the targets to which requests are applied.

[0035] The map information 30c includes node data indicating the positions of the nodes, shape interpolation point data indicating the positions of shape interpolation points for identifying the shapes of roads between the nodes, link data indicating the connections between the nodes, facility data indicating the positions and attributes of facilities existing on the roads and in the vicinity thereof, etc. The link data includes information indicating the number of lanes existing in the road section of each link, the width of the lanes (road width), the radius of curvature, the presence or absence of sidewalks, the direction of travel on the lanes, road attributes (highway, general road, narrow street, etc.), etc.

[0036] The delivery plan information 30d is delivery plan information generated by the above-mentioned manager terminal 200, and is recorded in the recording medium 30 by being transmitted from the manager terminal 200 to the delivery support system 10. As described above, the arrival time and departure time included in the delivery plan information are generated by the delivery support system 10 when the delivery vehicle arrives at (or departs from) the delivery destination store.

[0037] The control unit 20 can execute a program stored in the recording medium 30 or the ROM. In this embodiment, the control unit 20 can execute a delivery assistance program 21 and a requested information guidance program (navigation program) (not shown) as the program. The requested information guidance program has a function of guiding the delivery vehicle's deliverer along a planned driving route to the delivery destination and a function of guiding the requested information of the delivery destination store that is the destination. That is, when the route guidance program is executed, the control unit 20 periodically acquires the current location of the deliverer from the deliverer terminal 100. In addition, the control unit 20 draws a map including the deliverer's current location based on the map information 30c, and displays the map on the display unit of the user I / F unit 130. Furthermore, the control unit 20 identifies the planned driving route to the delivery destination store that is the next destination of the deliverer's current location, and the requested information of the delivery destination store, based on the delivery plan information 30d and the map information 30c, and displays them superimposed on the map displayed on the display unit.

[0038] In this way, the display unit displays the request information of the delivery destination store, which is the destination, but the registration of the request information at the delivery destination store is time-consuming because the content of the request must be manually entered by, for example, a delivery person, etc. For example, at other delivery destination stores that have similar attributes to a specific delivery destination store, there is a possibility that a request similar to that of the delivery destination store may occur, but it is difficult to manually find the same attribute store from among the many delivery destinations.

[0039] Therefore, in this embodiment, the system is configured to easily acquire requests from stores with the same attributes as the delivery destination store without the trouble of the delivery person or the like. The delivery support program 21 is a program for acquiring requests from the stores with the same attributes. When the delivery support program 21 is executed, the control unit 20 functions as a request acquisition unit 21a, a specification unit 21b, an acquisition unit 21c, and a guidance control unit 21d. Note that, below, the processes described as being performed by the request acquisition unit 21a, the specification unit 21b, the acquisition unit 21c, and the guidance control unit 21d are processes realized by the control unit 20.

[0040] The request acquisition unit 21a is a function that acquires requests from delivery destination stores. That is, the control unit 20 acquires requests from delivery destination stores to which requests correspond, by referring to the delivery destination store information 30a, using the function of the request acquisition unit 21a. For example, in the delivery destination store information 30a described in FIG. 3 above, requests from store a are recorded, so the control unit 20 acquires requests from store a.

[0041] The identification unit 21b is a function that identifies the type of the request from among multiple types based on the request acquired by the function of the request acquisition unit 21a. That is, the control unit 20, by the function of the identification unit 21b, refers to the delivery destination store information 30a and identifies the acquired type of request. Note that, as described above, the control unit 20 can identify the type of request by referring to a table that associates each type of request, such as "noise", with keywords that can be predicted as requests (e.g., "quiet", "noisy", etc.). A specific embodiment will be described later with reference to a flowchart.

[0042] The acquisition unit 21c is a function of acquiring a same attribute store (hereinafter, also simply referred to as a same attribute store) having the same attribute as the attribute associated with the delivery destination store based on the type of request, and associating request information indicating the same request with the same attribute store and the delivery destination store. That is, the control unit 20 refers to the delivery destination store information 30a by the function of the acquisition unit 21c, and acquires other delivery destination stores having the same attribute as the attribute associated with the delivery destination store (the delivery destination store associated with the request) as same attribute stores based on the type of request identified by the function of the identification unit 21b. Then, the control unit 20 associates the same request with the same attribute store and the delivery destination store, and updates the delivery destination store information 30a. A specific embodiment will be described later with a flowchart.

[0043] In this embodiment, the attributes include at least geographical attributes (for example, distance to residential areas is less than a preset distance, etc.), and the control unit 20 refers to the delivery destination store information 30a by the function of the acquisition unit 21c, and acquires stores with the same attribute based on the geographical attributes of the delivery destination stores. In addition, the definition of a store with the same attribute, "having the same attribute as the attribute associated with the delivery destination store," does not necessarily mean that the store has the same attribute, but may be considered to have the same attribute if it has an attribute with the same gist. For example, when a delivery destination store is associated with an attribute of "distance to residential areas is less than a preset distance," if there is a store associated with an attribute of "number of houses within a certain distance or more," the store may be considered to be a store with the same attribute. In other words, it can be said that the meaning of both stores being located near residential areas is the same.

[0044] The guidance control unit 21d is a function that guides a deliverer who delivers a package to a store with the same attribute to the requested information associated with the store with the same attribute. That is, the control unit 20 guides the planned driving route to the store with the same attribute (next delivery destination store) and the requested information at the store with the same attribute by using the function of the guidance control unit 21d. Specifically, the control unit 20 guides the planned driving route to the next delivery destination store based on the delivery plan information 30d, and guides the requested information if there is any. According to this process, even if the next delivery destination store is the same attribute store as described above and therefore the requested information is associated, even if the store is the store where the request occurred, if the requested information is associated, the function of the guidance control unit guides the requested information. The guidance of the planned driving route and the requested information are performed, for example, as follows. For example, the control unit 20 refers to the delivery destination store information 30a, the map information 30c, and the delivery plan information 30d, and transmits the location of the delivery destination store and the request information on the map and the surrounding area, etc. to the deliverer terminal 100, and displays it on the display unit of the user I / F unit 130 of the deliverer terminal 100. A specific embodiment will be described later in the flow chart.

[0045] According to this configuration, it is possible to associate the same request as the delivery destination store with a same attribute store having the same attribute as the attribute associated with the delivery destination store. As a result, it is possible to reduce the possibility that a deliverer or the like would manually register requests for each delivery destination store each time a request is made, which means that it is possible to increase the possibility of easily acquiring requests from same attribute stores having the same attribute as the delivery destination store.

[0046] (2) Shipping support processing: Next, the delivery support process executed by the control unit 20 will be described. FIG. 5 is a flow chart showing an example of the delivery support process. This process is executed, for example, whenever a request is received from a delivery destination store or the like. That is, when a deliverer receives a request from a delivery destination store or the like (for example, a complaint that the delivery work is noisy) and inputs the request, the deliverer terminal 100 transmits the request information to the delivery support system 10 in association with the identification information of the delivery destination store. The transmitted request information is received by the delivery support system 10 and recorded in the recording medium 30 as part of the delivery destination store information 30a.

[0047] When the delivery support process is started, the control unit 20 first acquires the request of the delivery destination store (step S1). That is, the control unit 20 acquires the request of the delivery destination store by referring to the delivery destination store information 30a through the function of the request acquisition unit 21a. For example, using the example of FIG. 3, if a request is received from store a, the control unit 20 acquires the request "delivery work is noisy" associated with store a. In the following explanation, the delivery destination store will be explained as store a in FIG. 3 unless otherwise specified.

[0048] Next, the control unit 20 acquires attributes of the delivery destination store (step S2). Specifically, the control unit 20 uses the function of the identification unit 21b to identify the type of request of the delivery destination store acquired in step S1. As described above, the type of request is identified by the control unit 20 based on a table (not shown). For example, in the example shown in FIG. 3, the request "delivery work is noisy" associated with store a is associated with "noise" as the type of request. Therefore, the control unit 20 refers to the delivery destination store information 30a to identify the type of request. Then, the control unit 20 acquires attributes associated with the delivery destination store based on the identified type of request. Specifically, the control unit 20 uses the function of the acquisition unit 21c to acquire attributes of the delivery destination store by referring to the delivery destination store information 30a. For example, using the example of FIG. 3, the geographical attributes of "no parking lot available" and "distance to residential area is less than a predetermined distance (e.g., 200 m)" are associated with store a, which is the delivery destination store. Among them, the attribute related to the request type "noise" is "the distance to the residential area is a preset distance (e.g., 200 m) or less." Therefore, the control unit 20 acquires the attribute "the distance to the residential area is a preset distance (e.g., 200 m) or less." After acquiring the attribute of the delivery destination store in step S2, the control unit 20 advances the process to step S3.

[0049] In step S3, the control unit 20 acquires identical attribute stores having the same attributes as the delivery destination store. That is, the control unit 20, using the function of the acquisition unit 21c, refers to the delivery destination store information 30a and identifies other delivery destination stores having the same attributes as the delivery destination store acquired in step S2. Specifically, in this embodiment, referring to the delivery destination store information 30a in FIG. 3, it can be identified that the identical attribute stores having the geographic attribute of the attribute of store a, "distance to residential area is a predetermined distance (e.g., 200 m) or less", are store d and store e. Therefore, the control unit 20 acquires store d and store e as identical attribute stores having the same attributes as the delivery destination store. When the control unit 20 acquires identical attribute stores having the same attributes in step S3, it advances the process to step S4.

[0050] In step S4, the control unit 20 associates the same request as that of the delivery destination store with the same attribute store. That is, the control unit 20 associates the same request as that of the delivery destination store with the same attribute store acquired in step S3 by the function of the acquisition unit 21c. That is, the control unit 20 presumes that a same attribute store having the same attribute as the delivery destination store has the same request as that of the delivery destination store, and associates the same request as that of the delivery destination store with the same attribute store. Specifically, the control unit 20 refers to the delivery destination store information 30a, identifies the request of store a, which is the delivery destination store, associates the same request as that of store a with stores d and e, which are same attribute stores, and records the information of the request in the recording medium 30 (i.e., the delivery destination store information 30a).

[0051] In this way, when the same attribute store is introduced as the next delivery destination store, the information of the request associated with the same attribute store is displayed on the display unit together with the planned driving route. FIG. 6 is a flowchart showing an example of a request information guidance process for guiding the planned driving route including the request information. Specifically, first, the control unit 20 refers to the delivery plan information 30d and acquires the delivery plan information 30d (step S10). As described above, the delivery plan information is mainly generated by the manager terminal 200, so that the control unit 20 acquires the delivery plan information from the manager terminal 200 via the communication unit 40 as a prerequisite. Then, the control unit 20 records the acquired delivery plan information in the recording medium 30. After acquiring the delivery plan information 30d, the control unit 20 advances the process to step S11.

[0052] In step S11, the control unit 20 performs route guidance along the planned driving route. Specifically, the control unit 20 identifies the current location of the deliverer transmitted from the deliverer terminal 100. Furthermore, the control unit 20 refers to the delivery plan information 30d and identifies the delivery destination, which is the next destination, from the current location of the deliverer. Furthermore, the control unit 20 refers to the delivery plan information 30d and the map information 30c and draws a map including the current location of the deliverer and the planned driving route. Then, the control unit 20 transmits the drawn image data to the deliverer terminal 100 and causes the display unit of the user I / F unit 130 to display the map. As a result, for example, a screen (not shown) showing the entire route guidance is displayed on the display unit of the user I / F unit 130.

[0053] Next, the control unit 20 judges whether the delivery vehicle has arrived in the vicinity of the delivery destination store (step S12). Specifically, the control unit 20 judges whether the distance between the current location of the delivery vehicle and the delivery destination store (for example, a store with the same attribute) is within a preset distance. That is, the control unit 20 identifies the current location of the deliverer transmitted from the deliverer terminal 100. The control unit 20 also acquires the distance between the delivery destination store and the current location of the vehicle based on the delivery plan information 30d and the map information 30c. Then, if the distance is within the preset distance, the control unit 20 judges that the delivery vehicle has arrived in the vicinity of the delivery destination store. If the control unit 20 judges in step S12 that the delivery vehicle has arrived in the vicinity of the delivery destination store, it proceeds to step S13. If it is judged that the delivery vehicle has not yet arrived in the vicinity of the delivery destination store, it repeatedly executes the process until the determination in step S12 is affirmative.

[0054] In step S13, the control unit 20 displays a map of the area around the delivery destination store. That is, by determining in step S12 that the delivery vehicle has arrived in the area around the delivery destination store, the control unit 20 changes the scale of the map displayed on the display unit of the user I / F unit 130 so that the delivery destination store and the current location of the vehicle are displayed on the screen of the display unit, and displays a map of the area around the delivery destination store on the display unit. That is, the display is changed from a map showing the entire route guidance to a map showing the area around the delivery destination store.

[0055] Next, the control unit 20 displays the desired information on the map (step S14). That is, the control unit 20, by using the function of the guidance control unit 21d, refers to the delivery destination store information 30a, identifies the desired information associated with the delivery destination store (here, the store with the same attribute), and displays the desired information superimposed on the map displayed in step S13.

[0056] FIG. 7 is a diagram showing an example of guidance of a planned driving route and guidance of request information for a delivery destination store (for example, store d, which is a store with the same attribute). As described above, store d is a store with the same attribute as store a. The attribute is "distance to residential area is less than a preset distance" and the request is "delivery work is noisy". Therefore, when the delivery vehicle approaches store d, the control unit 20 displays, for example, "Be careful of noise during delivery as it is a residential area" as shown in FIG. 7. This makes it possible to guide the delivery person to the request even when guiding him / her to stores with the same attribute. In FIG. 7, polygons of facilities such as delivery destination stores are exemplified by gray rectangles. Also, symbol C indicates the current position of the delivery vehicle, and the thick arrow indicates the route to store d. Then, the control unit 20 refers to the delivery plan information 30d, and if there is a delivery destination store that is the next destination, returns the process to step S11, and conversely, if there is no delivery destination store that is the next destination, ends the process in FIG. 6.

[0057] Next, the effects of this embodiment will be described. As described above, in the delivery support system 10 of this embodiment, the same request as the delivery destination store from which the request was acquired is associated with a same-attribute store having the same attribute as the delivery destination store. This makes it possible to associate a request with a same-attribute store having the same attribute even before acquiring a request for the same-attribute store. In other words, since the same-attribute store has the same attribute as the delivery destination store, it is considered that there is the same request, and the request is associated with the same-attribute store. This saves the effort of associating requests compared to, for example, a delivery person manually associating requests each time a request is made at each store, and as a result, it is possible to increase the possibility of easily acquiring a request from a store having similar attributes to the delivery destination store (same-attribute store).

[0058] In addition, by reducing the effort required for delivery persons, etc. to manually match (record) requests (in other words, by having the delivery support system 10 automatically record the requests of the delivery destination store), it becomes possible to record and add requests in a timely manner without taking up much time.

[0059] If the request of the delivery destination store is not associated with the same attribute store, not only will the effort of registering the deliverer described above be undone, but the request may not be associated until the request is accepted for the same attribute store. In such a case, when delivery is performed at the same attribute store, for example, even if there is a request that "the delivery work is noisy," the deliverer may perform work such as unloading without knowing the information of the request. In contrast, in this embodiment, the same request as that of the delivery destination store is associated with the same attribute store as described above, and the control unit 20 causes the deliverer who delivers the package to the same attribute store to inform the request information associated with the same attribute store. Therefore, when performing work such as unloading at the same attribute store, it is possible to perform the work after knowing, for example, "the situation is that the delivery is in a residential area, so care must be taken with noise during delivery." In other words, by registering or adding requests in a timely manner, it is possible to provide accurate request information to the deliverer, and as a result, the possibility of mistakes occurring during delivery and delivery such as unloading can be reduced.

[0060] In the above embodiment, the control unit 20 acquires the same-attribute stores having the same attributes as the delivery destination store based on the geographical attributes. This makes it possible to easily acquire the same-attribute stores by extracting only stores having the same geographical attributes, even if attributes other than geographical attributes are included.

[0061] (3) Other embodiments: The above embodiment is an example for carrying out the present invention, and various other embodiments can be adopted. In the above embodiment, the same request is associated with the same store as the delivery destination store, but for example, if the store of the same attribute meets the condition for not applying the request, the association may not be performed. Specifically, at least some of the multiple types of requests are associated with the condition for not applying the request. For example, as shown in the request non-application condition information 30b in FIG. 4, the conditions "near the main road", "near the factory", and "near the airport" are non-application conditions for not applying the request to the type of request "noise". In other words, the request for "noise" may not be applied to a delivery destination store that meets at least one of the conditions of near the main road, near the factory, and near the airport. This is because a delivery destination store under such conditions can be considered to have resistance to noise. For example, in the delivery destination store information 30a shown in FIG. 3, the attribute "near the main road" is associated with store e. Therefore, the control unit 20 may not associate the request for "noise" with store e. This allows, for example, responses to be tailored to regional characteristics and reduces the number of things that delivery personnel need to take care of when making deliveries.

[0062] In addition, the delivery destination store in the above embodiment may include a new delivery destination store that is newly registered, such as a new store. That is, in the above embodiment, as shown in FIG. 3, when a request for an existing delivery destination store is acquired, the same request as that delivery destination store is associated with a same attribute store having the same attribute as that existing delivery destination store. However, when a new delivery destination store is registered, the control unit 20 may associate a request associated with a same attribute store having the same attribute as that associated with the new delivery destination store with the new delivery destination store. More specifically, as information on the new delivery destination store, a part of the delivery destination store information similar to that in FIG. 3 is recorded (registered) by, for example, an administrator (not shown) who manages the delivery destination store. That is, as information on the new delivery destination store, information on the location of the new delivery destination store, the presence or absence of a parking lot, the number of parked cars, and attributes are recorded. The recorded information on the new delivery destination store is transmitted from a terminal (not shown) of the administrator (not shown) to the delivery support system 10 and recorded (i.e., updated) in the delivery destination store information 30a. The control unit 20 refers to the delivery destination store information 30a by the function of the acquisition unit 21c, and when information on a new delivery destination store is recorded, acquires a same-attribute store having the same attribute as the attribute associated with the new delivery destination store. Here, the attribute is assumed to be, for example, a geographical attribute as described above, and the control unit 20 identifies the geographical attribute associated with the new delivery destination store, and identifies a same-attribute store having the same attribute as the geographical attribute by referring to the map information 30c. Then, the control unit 20 further identifies a request associated with the identified same-attribute store, and associates the identified request as a request for the new delivery destination store. In other words, the control unit 20 assumes that the same request as the same attribute store having the same attribute as the new delivery destination store will occur, and associates the same request as the same attribute store with the new delivery destination store with the new delivery destination store.

[0063] In this way, when a new delivery destination store is registered, by associating the new delivery destination store with the same requests as the same attribute stores that have the same attributes as the new delivery destination store, it is possible to associate the requests as if there were requests the same as the same attribute stores even before the requests for the new delivery destination store are acquired. This allows requests to be associated before acquiring the requests for the new delivery destination store, so compared to when a delivery person or the like manually associates the requests when there are requests, it is possible to save the effort of associating requests and to increase the possibility of easily acquiring requests from stores with similar attributes (here, the new delivery destination store).

[0064] Also, for example, if the time period when the "noisy" request is received as a delivery destination store request is night / late night (e.g., 8 p.m. to 5 a.m.) or early morning (e.g., 5 a.m. to 8 a.m.), the late night or early morning request may be further associated as request information. In other words, in this case, the request information to be displayed on the display unit may be, for example, "Be careful of noise during late night deliveries."

[0065] In the above embodiment, as described in the delivery destination store information 30a of FIG. 3, attributes are associated with each delivery destination store in advance, but attributes may be associated with delivery destination stores by analyzing information such as the map information 30c. Such a configuration is realized by a configuration in which an attribute specification condition, which is a condition for specifying an attribute, is associated with a type of request. For example, assume that a request for "noisy" is made to store a. Also assume an example in which the type of request is "noise" and "distance to residential area" is associated with the type of request as an attribute specification condition. In this case, the control unit 20 acquires the attribute specification condition as "distance to residential area" based on the fact that the type of request is "noise". Furthermore, the control unit 20 refers to the map information 30c and specifies the attribute of store a according to the attribute specification condition. Here, assume an example in which the nearest residential area to store a is 200 m away. In this case, the control unit 20 associates the attribute "distance to residential area is 200 m or less" with store a. Then, the control unit 20 refers to the map information 30c, identifies the distance between the residential area and the delivery destination stores other than store A, and identifies delivery destination stores that are "200 meters or less away from the residential area." The control unit 20 then associates the attribute "200 meters or less away from the residential area" with the identified delivery destination store, and regards it as a store with the same attribute.

[0066] In the above embodiment, the content of the request is described as "noise" such as "delivery work is noisy", but the content of the request is not limited to this. As another content of the request, for example, a request regarding "parking location" such as "no parking on the road" at store b in the delivery destination store information 30a of FIG. 3 is assumed. When this request of "no parking on the road" is accepted, the control unit 20 refers to the delivery destination store information 30a, identifies the attribute associated with store b, and acquires a store with the same attribute having the same attribute as the attribute associated with the store b. In the example of FIG. 3, store c has the same attributes as store b, "no parking lot" and "road width is below the default width (for example, 4m)". Therefore, when the control unit 20 accepts the request of "no parking on the road" from store b, it associates the same request as store b with store c, which is a store with the same attribute. Then, when the control unit 20 guides the request information on the display unit, since the delivery destination store, which is the destination, does not have a parking lot, the control unit 20 guides, for example, a parking lot near the store.

[0067] In addition, in addition to the above-mentioned examples of "no parking lot" and "road width less than the specified width", the attribute of the "no parking lot" request may be "no parking lot" and at least one of the following attributes. Examples of the attribute include "road curvature is greater than the specified value", "number of lanes is one lane or less on each side (including roads with no lanes)", "sidewalks available", and "traffic volume is greater than a specified level of congestion". That is, when "no parking lot" and at least one of these four attributes are associated with a specific store (e.g., store b), the control unit 20 associates the same request as store b with the same attribute store. That is, if the curvature of the road in front of a specific store (e.g., store b) is greater than the specified value, it may be difficult to see oncoming vehicles, etc., so the control unit 20 associates a request for parking prohibition with the same attribute store and the delivery destination store. Note that even if the curvature is greater than the specified value, if the road with the curvature greater than the specified value is a one-way road, there are no oncoming vehicles, and in such a case, the attribute for parking prohibition may be excluded.

[0068] Furthermore, when the number of lanes on each side is one or less, if a delivery vehicle is parked on such a road, it may obstruct the passage of other vehicles, etc., so the control unit 20 associates a request for parking prohibition with the same attribute store and the delivery destination store. Furthermore, when there is a sidewalk, if a delivery vehicle is parked on the sidewalk, it may obstruct the passage of other vehicles, etc., so the control unit 20 associates a request for parking prohibition with the same attribute store and the delivery destination store. Furthermore, when the traffic volume is at or above a predetermined congestion level (for example, if the congestion level is set to three levels, vacant, crowded, and congested, it is at or above congestion), if a road adjacent to the delivery destination store is congested and a delivery vehicle is parked on the shoulder of the road, it may obstruct the passage of other vehicles, etc., so the control unit 20 associates a request for parking prohibition with the same attribute store and the delivery destination store.

[0069] The road width, road curvature, number of lanes, and presence or absence of sidewalks are included in the link data in the map information 30c, and correspond to geographical attributes. That is, the control unit 20 acquires the same attribute store based on the geographical attribute of the delivery destination store, and associates the request information with the same attribute store and the delivery destination store. The congestion degree indicating the traffic volume of the road corresponds to the attribute indicating the traffic volume of the road adjacent to the delivery destination store. That is, the control unit 20 may acquire the same attribute store based on the attribute indicating the traffic volume of the road adjacent to the delivery destination store, and associate the request information with the same attribute store and the delivery destination store. Regarding the congestion degree indicating the traffic volume of the road, for example, the control unit 20 acquires an FM signal, a beacon signal, or the like indicating the traffic volume from VICS (registered trademark), to specify the congestion degree (either vacant, crowded, or jammed). Alternatively, the control unit 20 may recognize vehicles from an image of the surroundings of the vehicle captured by a capture unit such as a camera provided in the vehicle, and specify the congestion degree from the number of recognized vehicles. Alternatively, the congestion degree may be specified from an external traffic information management system or the like. Alternatively, the degree of congestion may be defined in advance based on the attributes of the road adjacent to the delivery destination store (for example, a delivery destination store located along a main road such as a national highway is defined as being congested).

[0070] In addition, in this request for parking location, the above-mentioned "no parking lot" is one of the attributes, but even if there is a parking lot, if there is only a small amount of parking space, for example one car at a store, it may not be possible to park the delivery vehicle, and in that case, the delivery vehicle may park on the side of the road or in a no-parking space. Therefore, if there is only a small amount of parking space (less than a predetermined number), even if there is a parking lot, it may be considered to have the same attribute as no parking lot.

[0071] Furthermore, in the above embodiment, the attributes are described as "geographical attributes", but the attributes are not limited to geographical attributes. For example, depending on the delivery destination store, the business hours may be only in the morning (e.g., 6:00 to 10:00) or only in the evening (18:00 to 22:00). In such cases, it can be assumed that attributes such as morning business and evening business correspond to the attributes of the delivery destination store. Such attributes can be called, for example, "temporal attributes". In that case, the control unit 20 may acquire stores with the same attribute based on the temporal attributes of the delivery destination store, for example, by using the function of the acquisition unit 21c.

[0072] In addition, each system constituting the above-mentioned embodiment may be composed of fewer devices sharing functions. An example of such a case is that at least one system shown in FIG. 1 is composed of the same device as one or more other systems. For example, the delivery support system 10 and the deliverer terminal 100 may be composed of an integrated device, the delivery support system 10 and the manager terminal 200 may be composed of an integrated device, or the manager terminal 200 and the deliverer terminal 100 may be composed of an integrated device. Also, only a part of the functions of the delivery support system 10 (at least a part of the request acquisition unit 21a, the identification unit 21b, the acquisition unit 21c, and the guidance control unit 21d) may be realized by the delivery support system 10. Furthermore, the system shown in FIG. 1 may be composed of more systems. For example, at least a part of the delivery support system 10, the manager terminal 200, and the deliverer terminal 100 may be composed of a cloud server.

[0073] In addition, at least some of the components (request acquisition unit 21a, specification unit 21b, acquisition unit 21c, guidance control unit 21d) constituting the delivery support system 10 may be separated into multiple devices. Furthermore, configurations in which some of the components of the above-mentioned embodiment are omitted, or configurations in which processing is changed or omitted, may be assumed.

[0074] Furthermore, the technique of the present invention can also be applied as a program or method. The above-mentioned system, program, and method may be realized as a single device or may be realized by using parts shared with each part provided in the vehicle, and include various aspects. In addition, they can be modified as appropriate, such as being partly software and partly hardware. Furthermore, the invention can also be realized as a recording medium of a program that controls the system. Of course, the recording medium of the program may be a magnetic recording medium or a semiconductor memory, and any recording medium developed in the future can be considered in the same way. [Explanation of symbols]

[0075] 10...Delivery support system, 20...Control unit, 21...Delivery support program, 21a...Request acquisition unit, 21b...Identification unit, 21c...Acquisition unit, 21d...Guidance control unit, 30...Recording medium, 30a...Delivery destination store information, 30b...Request non-applicable condition information, 30c...Map information, 30d...Delivery plan information, 40...Communication unit, 100...Delivery person terminal, 110...Control unit, 120...Communication unit, 130...User I / F unit, 140...Recording medium, 140a...Delivery plan information, 140b...Map information, 200...Administrator terminal, 210...Control unit, 220...Communication unit, 230...User I / F unit.

Claims

1. A request acquisition unit that acquires requests from delivery destination stores; An identification unit that identifies a type of the request from among a plurality of types based on the request; and an acquisition unit that acquires a same-attribute store having the same attribute as the attribute associated with the delivery destination store based on the type of the request, and associates request information indicating the request with each of the same-attribute store and the delivery destination store. Delivery support system.

2. The acquisition unit is When a registration of a new delivery destination store that is a newly registered delivery destination store is accepted, an identical attribute store having the same attribute as the attribute associated with the new delivery destination store is acquired, and request information indicating a request associated with the identical attribute store is associated with the new delivery destination store. The delivery support system according to claim 1.

3. At least some of the multiple types of requests are associated with conditions under which the requests are not applied; and The acquisition unit is When the condition for not applying the request is satisfied in the same attribute store, the request information is not associated with the same attribute store. The delivery support system according to claim 1.

4. The attributes include geographic attributes; The acquisition unit acquires the same attribute store based on the geographical attribute of the delivery destination store. The delivery support system according to claim 1.

5. The attributes include an attribute indicating a traffic volume of a road; the acquiring unit acquires the same attribute store based on an attribute indicating a traffic volume of the road adjacent to the delivery destination store. The delivery support system according to claim 1.

6. and a guidance control unit that causes a delivery person who delivers a package to the same-attribute store to be notified of the request information associated with the same-attribute store. The delivery support system according to claim 1.

Images