JP2002347939A - Transport service system - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a system highly efficiently and optimally arranging a transport request, a transport vehicle, and its driver in the transport service system handling materials and persons set to transport objects. SOLUTION: This transport service system is provided with a transport request file 41 recording transport requests inputted by transport clients, a driving offer file 42 recording driving offer information inputted by drivers, a vehicle control file 43 recording control information of renting vehicles, a schedule file 44 assigning the transport request and the driving offer to each renting vehicle based on the transport request information, the driving offer information, and the vehicle control information, a schedule planning part 51 recording the transport plan in the schedule file 44, and a WWW server 52 browsably releasing the transport plan.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a transportation service for centrally managing transportation using vehicles.

[0002]

2. Description of the Related Art Conventionally, a rental car company or a leasing company lends a vehicle in a form in which a driver is prepared on a transportation request side, and generally required vehicles are leased in a contract with a vehicle management company. A vehicle lending system has been established. In addition, a general transportation company has a full-time or part-time driver, and when receiving any kind of transportation request, allocates the received transportation request to a vehicle owned or rented by the company and drafts a dispatch plan. Basically, each vehicle is assigned a driver managed by the company, so when a transportation company receives a transportation request from a customer, only the work of assigning this transportation request to the vehicle managing it is performed . Since such a transportation plan is performed for each transportation company, when a transportation request is made on the transportation request side, the transportation requester must first select the transportation company and convey the transportation request. For this reason, vehicles that meet the transportation request are limited to those managed by the transportation company, the choices of vehicles are narrowed, and transportation contracts are concluded when vehicles with special specifications are required to satisfy the transportation request. It tends to take a long time. In order to avoid such inconvenience in the handling of the transportation service in the closed area, for example, only by the individual transportation company, recently, the auction of the loading platform of the transportation vehicle by using the Internet has been carried out for one vehicle. A system has been proposed in which a transportation request to be assigned to a vehicle is directly recruited from a transportation requester to increase the transportation efficiency of the vehicle.

[0003]

The auction system for transport vehicles is effective for improving the transport efficiency of vehicles, but here, only the combination of transport vehicles and transport requests is handled. Absent. However, depending on the transportation request, the driver may play an important role together with the transportation vehicle. For example, if the transportation request is a pick-up service for the sick or disabled, the transport target is a person who needs some kind of nursing care, so compatibility with the driver is also important, and simply as in the case of goods transportation It is not enough to simply combine the transport object and the vehicle, and it is necessary to consider the driver in the combination work. In addition, there are many independent drivers who receive a transportation request and a transportation vehicle from a third party and can provide their own driving skills only. A transport service system that effectively utilizes such a driver in the transport field has not yet been proposed.

[0004] In view of the above situation, an object of the present invention is to provide a system for efficiently and optimally combining a transport request, a transport vehicle, and a driver thereof in a transport service system in which goods and people are transported. is there.

[0005]

In order to solve the above-mentioned problems, in a transportation service system according to the present invention, a transportation request file for recording transportation request information inputted from a transportation requester via a network, and a transportation request file recorded by a driver via a network. A driving offer file that records the driving offer information input in step 1, a vehicle management file that records the management information of the rented vehicle, and a transportation request to each rented vehicle based on the transportation request information, the driving offer information, and the vehicle management information. A scheduler for allocating a driving offer and recording the transportation plan in a schedule file, and a notifier for notifying at least a transportation requester and a driver of all or part of the transportation plan via a network. . The network here is a network open to at least registered general people, such as the Internet.

In this system, transportation request information, which is a transportation request for sending an article or a person to a predetermined place at a predetermined date and time, and driving offer information, which is an offer of a driver providing a skill of driving a vehicle at a predetermined date and time, From the vehicle management information that manages the operating state of the vehicle used for transportation, optimal combination processing of the transport object, the driver, and the transportation vehicle is performed to satisfy the wishes of the transportation requester and the driver. You. In other words, they are combined in consideration of the schedule and possibly qualitative demands of a person who wants to receive the transportation service, a person who wants to perform the transportation service, and a vehicle suitable for the transportation. In addition, since the result of the combination is notified through the network, the parties can easily confirm the result, and a contract for a transportation service that is satisfactory can be made.

[0007] By introducing a driver as an item to be combined in a contract for a transport service, an independent driver having only driving skills not only having no direct contact with a transport requester but also owning a transport vehicle. Can be taken into the transport service circle, and the problem of compatibility between the driver and the transported person, which has conventionally occurred when the transport target is a person, can be considered as much as possible. This is particularly important when the transported person is a caregiver or a disabled person, as appropriate care skills are required and privacy issues are involved.

In such a transport service system, since the driver and the transport vehicle are randomly distributed, it is necessary to minimize the time required for the driver to travel to the combined vehicle in terms of transport efficiency and driver burden. Important from. For this reason, in one of the preferred embodiments of the present invention, the transportation request information includes position data of an object to be transported, and the driving offer information includes position data of a driver, The vehicle management information includes vehicle parking position data, and the schedule planning unit assigns a transportation request and a driving offer to each rented vehicle in consideration of the transportation target, the driver, and the position of the vehicle. It is configured. As a result, the time required for the driver to travel to the assigned vehicle is taken into account, and lending is carried out to maximize transportation efficiency and reduce driver burden as long as essential conditions are satisfied. A transportation request and a driving offer are assigned to the vehicle.

[0009] In addition, there is a strong tendency that the same request is repeated for a transport request from a transport requester. Particularly, when the transport target is a care elderly or a disabled person, the body of the care elderly or the disabled is combined through repetitive combinations. Drivers who understand their mental and mental characteristics will give a sense of security,
It is expedient to prioritize combinations with previously matched drivers. For this reason, in a preferred embodiment of the present invention, the schedule file includes a history file that records the assignment of past transportation requests and driving offers, and the schedule planning unit considers the past assignment history. Then, a transportation request and a driving offer are assigned to each rental vehicle.

[0010] A special use vehicle may be required depending on the transport object. For example, transportation of refrigerated food requires a vehicle having a refrigeration function, and transportation of a person using a wheelchair requires a vehicle with a wheelchair lift function. In order for the transportation service system according to the present invention to be able to respond to such specially-specified vehicle requests, the transportation request information, the driving offer information, and the vehicle management information include vehicle specifications indicating vehicle types and vehicle accessories. Data is included, and the schedule planning unit needs to allocate a transportation request and a driving offer to each rented vehicle in consideration of conformity with the vehicle specifications.

In a transportation service in which an independent driver, which is widely recruited from the general public, and a transportation request in which a special article or person is transported, are combined with a special vehicle, once the combination is set, Cancellation is likely to occur for convenience. In order to secure as much time as possible for the next combination setting for cancellation of a possible transportation combination (that is, cancellation of the transportation reservation), it is necessary to ensure that the parties approve the transportation reservation. According to one preferred embodiment of the present invention, in the present invention, the scheduler releases the first combined transportation plan as a provisional transportation plan to at least the driver through the notification section, and approves the provisional transportation plan by the parties. Later, the temporary transportation plan was made the official transportation plan. If the user carries the access means with the notification unit, he / she can be notified of the provisional transportation plan anytime and anywhere, so that the approval procedure by the parties can be reliably performed.

In order to improve the operation rate of vehicles, it is important to set the use time of vehicles in a transportation plan assigned to each vehicle as accurately as possible. For example, after the driver has traveled to the parking lot of the assigned vehicle, it is necessary to drive the vehicle and move to a place where the transport target waits, so that the actual use time of the vehicle needs to include this travel time . For this reason, it is convenient that the schedule planning unit is configured to calculate the vehicle lending start time and the vehicle lending end time based on the parking position of the vehicle and the position of the transport target.

In one preferred embodiment of the present invention, the transportation request information is divided into a priority request and a non-priority request, and after a transportation plan based on the priority request is established, a transportation plan based on the non-priority request is performed. It is configured as follows. This configuration is for example, if this transportation service system is adopted as part of a welfare car volunteering activity led by a local government, the volunteer driver will be required to transport the elderly and disabled people who are called the vulnerable. The first priority is to lend public vehicles (welfare cars) to the public, and lending surplus public vehicles to the public is in the spirit of welfare. In other words, the priority transportation request information is the transportation of the care recipient, and by selecting the driver for the transportation from the registered volunteers, we can increase the utilization rate of the welfare car and reduce the waste of welfare car service. A system can be built.

The notifying section for notifying at least the transport requester and the driver of all or a part of the transport plan via the network can be constructed in various forms. For example, you can use an email system,
It is also possible to use an automatic fax system. More preferably, this notifying unit is constructed by a WWW server, and the information published by the WWW server is:
It can be browsed anytime and anywhere by various computer devices having a WWW browser function (browser phone, PDA, portable computer, desktop computer), and as a result, all or a part of the transportation plan can be transmitted or requested by the operator via the network. Has been notified. That is, the concept of information notification by the notification unit in the present invention includes information disclosure performed in a format like a WWW server. Other features and advantages according to the present invention will become apparent from the following description of embodiments with reference to the drawings.

[0015]

BEST MODE FOR CARRYING OUT THE INVENTION As one embodiment of the transportation service system of the present invention, a volunteer drives a welfare rental car (hereinafter referred to as a welfare car or simply a vehicle) owned by a local government, and an elderly person or a car is driven. This section describes the case of a welfare car volunteer system in which a care recipient, such as a disabled person, with insufficient walking ability is sent to a hospital or meeting place. FIG. 1 shows the entire configuration of a welfare car volunteer system. Basically, in this system, the carrier is a care recipient, the driver is a volunteer, the vehicle manager is a local government official,
Each can access the central computer system 2 of the local government via the Internet 9 from the network terminal 1 equipped with a WWW browser. As the network terminal 1, a personal computer, a PDA, or a mobile phone having a communication function and a WWW browser function can be used.

The computer system 2 of the municipal government, which is the center of this welfare car volunteer system, transmits contents (collection of texts and images) generally displayed in HTML displayed by the WWW browser of the network terminal 1 through the Internet 9. A WWW server 3 equipped with software to be sent to each network terminal 1, a database server 4 storing various information in a searchable and extractable manner, mediating between the WWW server 3 and the database server 4 and detailed later. The application server 5 that implements a program according to the flow of the combination process of the care-requiring person, the driver, and the welfare car to be described and the management task, and the mail server 6 that is equipped with e-mail software, etc. These services have been built It is installed in a state of being connected to each other by LAN. Depending on the scale of the system, these servers can be integrated into one server machine.

The input information data obtained by the WWW server 3 through a session performed in response to access from the network terminal 1 of the care requester (or caretaker of the care requester) or the driver who is the transport requester is transmitted to the application server. 5 and is processed there to generate a command or the like for operating the database server 4, whereby information necessary for implementing the welfare car lending service is read from the database server 4. Application server 5
A variety of business functions are created by the programs installed in the program, but the most important one is the schedule planning unit 51 for creating a welfare car lending schedule. Information such as a schedule prepared by the schedule planning unit 51 must be disclosed through the Internet 9 in order to request approval from a care recipient, a driver, or, in some cases, a vehicle manager. Therefore, the application server 5 has WWW
The content created based on the information extracted from the database server 4 by the search condition created by processing the command and data sent from the server 3 is WW
An HTML generation unit 52 provided to the W server 1 is also mounted. In addition, an e-mail creating unit 53 for creating a standard e-mail is provided in the application server 5 in order to contact the transport requester, the driver, and the vehicle manager necessary for the welfare car lending reservation determination process by e-mail. Have been.

Various information is stored in the database server 4 for each file, and the file storing information particularly related to the present invention is input via a network from a transport requester who is a care recipient. Transport request file 41 that records the transport request information, a drive offer file 42 that records the drive offer information input from the volunteer driver via the network, a vehicle management file 43, a schedule file 44, a temporary file 45, a combination history File 46. Application server 5
The database management unit 40 specifies a corresponding file on the basis of the database operation command generated in step (1), performs a search / extraction operation on the file, and sends requested data to the application server 5. The schedule planning unit 51 implemented in the application server 5 performs transportation suitable for each welfare car based on the transportation request information of the care recipient, the volunteer driving offer information, and the vehicle management information recorded in the vehicle management file 43. The request and the driving offer are assigned, and the set transportation plan (the combination of the transportation request and the driver and the vehicle) is passed to the database management unit 40 and recorded in the schedule file 44. Temporary file 45
The data that needs to be temporarily stored during processing is stored in the combination history file 46. The combination history file 46 includes the past combination of the transport requester (need for caregiver) and the driver (volunteer), and also includes the vehicle if necessary. The results of the combination are recorded.

The file structure of the transport request file 41 for recording the transport request information is shown in FIG. 2A, and includes "Requester name", "Requester number", "Reservation date", "Transfer start" Fields such as “time”, “pickup end time”, “departure place”, “transit point”, “destination”, “vehicle specification”, “number of passengers”, and “password” are provided. It should be noted that the personal information of the transport requester (need caregiver) is recorded in the care recipient master file 41a shown in FIG.
Since the care-requiring person master file 41a and the transport request file 41 are associated with each other using the "client number" as a key, personal information on the client can be extracted as needed. For example, since the caregiver master file 41a includes fields such as the address and telephone number of the client and desired vehicle specifications such as those with a wheelchair lift function, these fields are included in the record of the transport request file 41 as a relational file. Data processing as if provided is possible. Also,
If “home” is recorded in the “departure place” field of the transport request file 41, the data of the “address” field of the care recipient master file 41a is extracted using the “requester number” as a key, thereby obtaining the position data of the departure place. Can be grasped.

The file structure of the driving offer file 42 that records driving offer information including the date and time when a volunteer can be active as a welfare car driver is shown in FIG. ) Name, "volunteer number", "date of volunteer activity"
Fields such as "activity start time" and "activity end time" are provided. Again, personal information about volunteers
It is recorded in the driver (volunteer) master file 42a shown in FIG. 3B, and the driver master file 42a and the driving offer file 42 are associated with each other using the "driver number" as a key. Personal information about volunteers (drivers) can be extracted as needed. Volunteer master file 42
a has fields such as “volunteer name / address”, “telephone number”, and “e-mail address” in addition to the “volunteer number”. Fields can be considered as being provided.

As shown in FIG. 4A, the vehicle management file 43 which records the reservation / use status of the welfare car is
"Vehicle reservation number", "vehicle number", "lending start time",
"Lending end time", "use classification", "volunteer number", "transport requester number", "schedule number", and the like are also provided. The "vehicle number" is used as a key field for creating a relational relationship with the vehicle master file 43a shown in FIG. 4B, and the "schedule number" is used as a key field for creating a relational relationship with the schedule file 44. . The vehicle master file 43a includes fields such as "vehicle number", "parking position", and "vehicle specification".

The transportation request information from the care-requiring person recorded in the transportation request file 41 and the driving offer file 42
The schedule planning unit 51 refers to the driving offer information from the volunteer who is the driver of the welfare car recorded in the vehicle management file and the vehicle management information including the reservation / use status of the welfare car recorded in the vehicle management file 43. FIG. 5 shows the file structure of the schedule file 44 for recording the information on the welfare car lending schedule created by the company. From the record contents of the schedule file 44, a welfare car lending schedule published on the Internet 9 through the WWW server 3 is created by the HTML generation unit 52. Therefore, the schedule file 44 includes "schedule number" and "vehicle reservation number". "
Furthermore, “reservation date”, “pick-up start time”, “pick-up end time”, “client number” serving as a key for linking with the transport request file 41, and “driving” serving as a key for linking with the driving offer file 42 Fields such as "user number" and "schedule approval" for checking whether or not this schedule has been approved.

In this welfare car volunteer system,
Carriage request by the carrier requesting caregiver and driving offer by volunteer driver (volunteer activity)
Is sequentially combined with a welfare car of a vehicle type (specification) desired by both parties, thereby establishing a reservation for pick-up and drop-off using a welfare car of a care recipient. Such a processing flow will be described below with reference to the information flow chart of FIG. 6 and the processing flow chart of FIG.

First, the transport requester (care-requiring person) accesses the WWW server 3 using the network terminal 1 and
Through the welfare car reservation screen page shown in FIG. 1, a request for pick-up and drop-off by a vehicle (use of a welfare car), and the driver (volunteer) also uses the network terminal 1 to make a WWW server 3
And offers a volunteer activity for driving a vehicle (welfare car) through the volunteer activity reservation screen page shown in FIG. 9 (# 1a). The transport request information and the driving offer information written by each are written in the transport request file 41 and the driving offer file 42 via the application server 5 (# 1b). Such input is repeatedly performed by a large number of transport requesters and drivers within the set time limit (# 2).

While reading the transport request information and the drive offer information input within the time limit from the transport request file 41 and the drive offer file 42 in batch processing, the scheduler 51
Generates a provisional schedule (# 3). This temporary schedule generation processing will be described later in detail. The provisional schedule data generated in the provisional schedule generation process is written in the schedule file 44,
The reservation data of the welfare car determined by this is written in the vehicle management file 43 as vehicle management information. The generated tentative schedule is converted to a tentative schedule table by the HTML generation unit.
The document is converted into a TML document and made public only to the driver through the WWW server 3 (# 4). This is because the provisional schedule is created for the purpose of obtaining the driver's approval, and therefore, the screen page of this provisional schedule is suitable for provisional schedule adjustment as shown in FIG. ing. The driver who browses the provisional schedule table presses the approval button to set the provisional schedule as the fixed schedule, or presses the change request button to perform the provisional schedule adjustment process in which the driver is offered to change the assignment ( # 6). This provisional schedule adjustment processing is performed by all the combined drivers (# 7).
When the provisional schedule adjustment process is completed (# 7 Yes branch) and the provisional schedule is determined, a fixed schedule table is created and published based on the determined schedule (# 8). This fixed schedule is open to both the driver and the transport requester, and if it is necessary to change this schedule (# 9), an adjustment process for the fixed schedule is executed (# 10).

Next, the provisional schedule generation process (# 3) by the schedule planning unit 51 will be described in detail with reference to FIG. First, one transportation request to be processed is extracted from the transportation request file 41 (# 12). The driver who volunteers for the transportation request, that is, the desired date of the pick-up service by the welfare car, is extracted from the driving offer file 42 (# 14). It is checked whether any of the extracted drivers is within a predetermined short distance from the departure place (usually, the home of the care recipient) of the transportation request to be processed based on the driving offer information (# 16). If there is a driver that satisfies this condition (Yes in # 16), the compatibility between this driver and the care-requiring person to be processed is determined from the number of past combinations in the past recorded in the history file 46. Then, the most compatible combination, that is, the driver with the largest number of past combinations is identified (# 18). If there is no corresponding driver within a predetermined short distance in the check in step # 16 (No branch in # 16), the driver closest to the departure place of this transportation request is specified (# 3).
0), the combination compatibility check in step # 18 is omitted.

Subsequently, it is checked whether a vehicle satisfying the first desired vehicle specification of the combined driver is available on the day by accessing the vehicle management file 43 (# 20). If a vehicle that satisfies the driver's request can be assigned (Yes branch in # 20), it is further checked whether this vehicle satisfies the vehicle specification desired by the transport requester (# 22). If the vehicle specification of the transportation requester is also satisfied (# 22 Yes branch), it is determined that the combination of the transportation request, the driving offer, and the vacant vehicle is provisionally established (# 24). It is written in the schedule file 44 and the vehicle management file 43 (# 26).

If a vehicle satisfying the first desired vehicle specification of the combined driver is not available on the day, that is, if the vehicle branches to No in step 20, the second request is made when a driving offer is input.
Since the desired vehicle specification is also selected, it is checked whether a vehicle satisfying the driver's second desired vehicle specification is available on the day (# 32). If a vehicle that satisfies the driver's second request can be allocated (Yes branch at # 32), the process jumps to step # 22 to check whether this vehicle satisfies the vehicle specification requested by the transport requester. If no vehicle satisfying the second desired vehicle specification is available (No branch at # 32), is there a driver again within a predetermined short distance from the starting point of this transportation request, that is, is there a next driver candidate? It is checked whether it is (# 34). If the next candidate exists (Yes branch in # 34), step #
Returning to 18, the process of creating the provisional schedule is continued in the above-described flow while newly referring to the driving offer information of the next candidate driver. If the next candidate does not exist (No branch at # 34), there is no driving offer that can respond to the transportation request, so that this transportation request is processed as a driver undecided at this time (# 36) and the temporary file 45 (# 38), and is handled as a driver-unassigned transport request during the provisional schedule adjustment process (# 6).

If it is determined in step # 22 whether an empty vehicle that satisfies the driver's request satisfies the vehicle specification of the carrier, the vehicle does not satisfy the vehicle specification of the carrier (No branch in # 22). It is checked whether the vehicle type to be combined at this time is the driver's first desired vehicle type (# 40), and if it is the first desired vehicle type (# 40 Yes branch), the second desired vehicle type is to be combined. Then, the process jumps to step # 32 again to continue the schedule process. If the vehicle type to be combined at this time is already the second desired vehicle type (# 40 No branch), it is determined that the combination is impossible for this driver. It is checked whether or not the driver's next candidate exists (# 42). If there is a next candidate (# 42, Yes branch), the process returns to step # 18, and the provisional schedule creation process is continued according to the flow described above while newly referring to the driver offer information of the next candidate driver. If the next candidate does not exist (No branch in # 42), the process jumps to step # 36 to perform the process of undecided driver.

The above-described provisional schedule creation routine is sequentially performed for all the transport requests extracted from the transport request file 41 (# 28).

When the provisional schedule is released, an approval or change is given to the given schedule using the screen shown in FIG. The instruction input by the driver is processed in a provisional schedule adjustment processing routine (# 9). The contents of the temporary schedule adjustment processing routine will be described with reference to the flowcharts of FIGS. If the approval button is clicked (# 51),
Assuming that the presented provisional schedule is approved, the provisional schedule becomes a fixed schedule (# 52). As a result, a fixed display is made at the corresponding part of the provisional schedule (# 53) and added as one item of the fixed schedule (# 54).

When the change request button is clicked on assuming that the presented provisional schedule is inconvenient (# 55), a screen for inputting the reason for the inconvenience is displayed, and the driver inputs the reason and inputs the reason. Receive (# 56). The input reason contents are recorded in the temporary file 45 and then printed out in a timely manner. The provisional schedule for which the change request was issued is the schedule file 44
And the transportation request is temporarily stored in the temporary file 45.
And the process is forwarded to a process for an additional offer from another driver (# 57). The transportation request for which this change request has been issued is displayed on the HTML generation unit 5 together with the transportation request for which the driver has not yet been determined, as shown in FIG.
2 and published through the WWW server 3 (#
58). After waiting for a new driving offer through this driving offer recruiting screen (# 59), when the driving offer comes in, FIG.
The additional offer process indicated by 3 starts (# 60).

First, a new driving offerer inputs a desired vehicle type (vehicle specification) of a welfare car (# 62). It is checked whether the vehicle of the input desired vehicle type is vacant (# 64), and if it is vacant (# 64 Yes branch),
Next, it is checked whether this vehicle satisfies the desired vehicle specification of the transportation request (# 66). If the selected vehicle also satisfies the transportation request (# 66 Yes branch), it is determined that the combination of the transportation request, the driving offer, and the vacant vehicle is provisionally established (# 68), and the schedule data based on this combination is created. Then, the temporary file is written in the schedule file (# 70), and the fact that the combined vehicle is scheduled to be rented is written in the vehicle management file 43 (# 72). As a result, the provisional schedule shown in FIG. 10 is also updated (# 74).

If there is no vacancy in the vehicle of the vehicle type entered by the driver in step # 64 (No in # 64), it is checked whether the vehicle type can be changed (# 76). If the vehicle type can be changed (# 76 Yes branch), the process returns to step # 62 to input a different desired vehicle type. If the vehicle type cannot be changed (No in # 76), this additional offer is not established (# 7
8) Jump to step # 58 in FIG. 12 to recruit additional driving offers.

Even after the confirmed schedule is released, the use of the reserved welfare car may be changed due to reasons such as poor physical condition, especially when the elderly or disabled person requiring care is the carrier. Can occur. Such a change is processed by an adjustment processing algorithm for a fixed schedule as described below. 1. When the transportation requester presses a change button of a specific reservation schedule item, a change registration screen is displayed. 2. In the displayed screen, enter the details of the change, such as the date and time and the destination you want to change. 3. The input changes are stored in the application server 5
The program is rewritten into an e-mail in the form of a reservation change request by the e-mail creating unit 53 which is a program installed in the system, and is notified to the system administrator and the driver concerned. 4. The driver who has received the e-mail calls a dedicated page and inputs whether the change is possible or impossible. 5. When the change is accepted, the fixed schedule is updated with the change, and the schedule file 44 and the vehicle management file 43 are appropriately rewritten. 6. If the change is not accepted, if there is another driver making a driving offer at the changed reservation date and time,
The transportation is recombined with the driver, and the system administrator, the driver, and the transportation requester are notified of the combination in the form of an e-mail created by the mail creation unit 53. 7. If there is no driver who has made a driving offer at the changed reservation date and time, all the registered drivers are invited for a driving offer for this changed transport request. 8. If there is a new driving offer, determine the combination of the relevant transportation request with this driver, update the finalized schedule,
At the same time, the schedule file 44 and the vehicle management file 43 are appropriately rewritten. 9. The new combination is notified by e-mail to the system administrator, the driver, and the transportation requester via the mail creation unit 53.

In such a welfare car volunteer system, it is important to increase the operation rate of the welfare car. For this reason, it is convenient to give priority to the use reservation of the welfare car from the care recipient and, if the welfare car is still available after the reservation process is completed, accept a loan to the general public. First, the transport request and volunteer of the care recipient need to automatically combine the driving offer with the vacant vehicle of the desired vehicle type to determine the lending schedule of the welfare car, so that the schedule for the care recipient can be quickly determined, and then The commencement of the vehicle lending reservation period for the general public will be sufficiently secured, and as a result, the utilization rate of welfare cars will be increased.

Furthermore, in order to promote efficient use of a welfare car, the lending time of the welfare car must be set as accurately as possible. FIG. 15 shows a time chart from the time when the volunteer leaves his home for the driving volunteer activity to the time when the volunteer actually returns to the home using the welfare car. From this, in this system, when calculating the lending start time and the lending end time of the welfare car, the volunteer volunteer who is the driving offerer travels to the parking place of the welfare car to pick up the care recipient, The time to send the volunteers and travel to the welfare car parking point from there will be considered. This is especially important when the distance between the volunteer and each of the welfare car parking and the care recipient is long. For this reason, the schedule creation unit 51 is provided with an algorithm for calculating the travel time and travel time between each point from the address of each point and calculating the vehicle lending time. An example of this algorithm is as follows. 1. Identification of the home position (cargo position) of the care recipient. 2. Identify the desired vehicle parking position. 3. Search the route from the parking position to the home position of the care recipient. 4. Calculate the required travel time on the searched route. 5. The transfer start time (the departure time of the care-requiring person from home) is calculated and the time is advanced by the required traveling time, and this time is set as the vehicle lending start time (volunteering time). 6. The transfer end time (time to return home to the care-requiring person) is calculated to be later than the calculated travel time, and this time is used as the vehicle lending end time (volunteer drop-off time). 7. The vehicle lending start time and the vehicle lending end time are written in the vehicle management file.

The characteristic processing flow of the welfare car volunteer system described above is summarized as follows. The care recipient needs the pick-up and drop-off service on the welfare car reservation screen (see Fig. 8) published on the Internet, the start time, the end time, the departure point, the transit point, the destination, the vehicle use, etc. And register the reservation. 2. The volunteer inputs a date, start time, end time, and the like at which the driver can volunteer as a driver on the volunteer activity reservation screen (see FIG. 9) published on the Internet, and makes a driving offer. 3. Date and time, distance between volunteers and care recipients, use of vehicles, compatibility between past volunteers and care recipients, as a batch process, based on transportation requests, driving offers, and vehicle management status entered up to the specified reservation period , An optimal combination is automatically set based on history information or the like, and a provisional schedule is created. 4. Publish the provisional itinerary via the Internet and request the approval of the parties. 5. Prepare another opponent for unaccepted combinations. 6. If there is a vacancy in the welfare car after the reservation of the care recipient is determined,
Publish a reservation screen for lending to citizens via the Internet.

[Alternative Embodiment] In the above-described embodiment, the transport service system of the present invention is employed in a welfare car volunteer system. Of course, this transport service system is applied to a commercial logistics service system. Can also. In this case, the transport requester is a shipper, and registers necessary items such as shipping time and arrival time, departure place and destination, and vehicle specifications, and the driver offers a drivable date. Further, a vehicle owner as a vehicle manager registers vehicles that can be rented. After that, similar to the welfare car volunteer system described above, the provisional schedule and the provisional schedule adjustment (in this case, it is preferable to obtain the approval of both the transport requester and the driving applicant) are performed, and the fixed schedule is also set. Then, the goods are transported. When this transportation service system is applied to a taxi service system, its form is almost the same as that of a welfare car volunteer system. What is important in the transportation service of the present invention is that a transportation plan is created by setting combinations so as to satisfy each requirement between a transport requester, a driver, and a vehicle manager regardless of whether a transport target is a person or an article. That is.
With the optional selection of the vehicle and the driver, which cannot be achieved with the conventional distribution system, it is possible to realize a more flexible distribution system.

Further, in the above-described embodiment, the WWW server is employed as the notification unit. However, the notification unit for notifying the transportation requester or driver of all or a part of the transportation plan via the network is similar to the WWW server. Other than the public browsing type, for example, e-mail system and automatic FA
It is also possible to employ a direct information transmission type such as the X system.

[Brief description of the drawings]

FIG. 1 is an overall configuration diagram of a welfare car volunteer system.

Fig. 2 File structure diagram of the transportation request file and the care recipient master file

Fig. 3 File structure diagram of driving offer file and volunteer master file

FIG. 4 is a file structure diagram of a vehicle management file and a vehicle master file.

FIG. 5 is a file structure diagram of a schedule file.

FIG. 6 is an information flow chart in a welfare car service.

FIG. 7 is a processing flowchart in a welfare car service.

FIG. 8 is a welfare car reservation screen displayed on a WWW browser.

FIG. 9 is a volunteer activity reservation screen displayed on a WWW browser.

FIG. 10 is a provisional schedule table screen displayed on a WWW browser

FIG. 11 is a flowchart of a provisional schedule generation process;

FIG. 12 is a flowchart of a provisional schedule adjustment process;

FIG. 13 is a flowchart of an additional offer process.

FIG. 14 is a driving offer recruitment screen displayed on a WWW browser.

FIG. 15 is a time chart of a welfare car service.

[Explanation of symbols]

 DESCRIPTION OF SYMBOLS 1 Network terminal 2 Central computer system 3 WWW server (notification part) 4 Database server 5 Application server 6 Mace server 9 Network (Internet) 41 Transportation request file 42 Operation offer file 43 Vehicle management file 44 Schedule file 45 Temporary file 46 History file 51 Schedule planning unit 52 HTML generation unit 53 Email creation unit

──────────────────────────────────────────────────続 き Continued on the front page (51) Int.Cl. ⁷ Identification symbol FI Theme court ゛ (Reference) G06F 17/60 302 G06F 17/60 302C 314 314 318 318G ZEC ZEC G08G 1/00 G08G 1/00 D 1 / 13 1/13 F term (reference) 5H180 AA01 AA22 AA23 BB02 BB04 BB05 BB15 EE03 EE06 EE08 FF10 FF13 FF14 FF15 FF21 FF32

Claims (9)

[Claims] 1. A transportation request file for recording transportation request information inputted from a transportation requester via a network, a driving offer file for recording driving proposal information inputted from a driver via a network, and management of rental vehicles. A vehicle management file that records information, a schedule planning unit that allocates a transportation request and a driving offer to each rental vehicle based on the transportation request information, the driving offer information, and the vehicle management information, and records the transportation plan in a schedule file. And a notifying unit for notifying at least a transport requester and a driver of all or part of the transport plan via a network. 2. The transportation request information includes position data of an object to be transported, the driving offer information includes driver position data, and the vehicle management information includes vehicle parking position data. 2. The transportation according to claim 1, wherein the schedule planning unit assigns a transportation request and a driving offer to each rental vehicle in consideration of an object to be transported, a driver, and a position of the vehicle. 3. Service system. 3. The schedule file includes a history file in which past transportation requests and assignments of driving proposals are recorded, and the schedule planning unit considers past assignment history and transmits a transportation request to each rental vehicle. The transportation service system according to claim 1, wherein assignment of a driving offer is performed. 4. The transportation request information, the driving offer information, and the vehicle management information include vehicle specification data indicating a vehicle type, a vehicle accessory, and the like, and the schedule planning unit considers conformity with the vehicle specification. The transportation service system according to any one of claims 1 to 3, wherein a transportation request and a driving offer are assigned to each rental vehicle. 5. The schedule planning unit discloses the first combined transportation plan as a temporary transportation plan to at least a driver through the notification unit, and after approval of the temporary transportation plan by a party, sets the temporary transportation plan as a formal transportation plan. The transportation service system according to any one of claims 1 to 4, wherein: 6. The transportation service system according to claim 2, wherein the schedule planning unit calculates a vehicle lending start time and a vehicle lending end time based on the parking position of the vehicle and the position of the transport object. . 7. The transportation request information is divided into a priority request and a non-priority request, and after a transportation plan based on the priority request is established,
7. The transportation service system according to claim 1, wherein a transportation plan based on the non-priority request is performed. 8. The transportation according to any one of claims 1 to 7, wherein the priority transportation request information is transportation of a care recipient, and a driver for the transportation is a registered volunteer. Service system. 9. The system according to claim 1, wherein the notifying unit is constructed by a WWW server, and at least a notification to a transport requester and a driver is made by disclosing information by the WWW server. Transportation service system.