JP7045068B2 - Delivery management server - Google Patents

Description

The present invention relates to a delivery management server , and particularly relates to regular delivery of goods (delivery items) purchased on an EC site.

Conventionally, a method of collectively delivering a plurality of deliverables has been proposed. For example, Patent Document 1 discloses a home delivery system that collectively delivers a plurality of products ordered to each mail-order company affiliated with the home delivery company by registering as a user on the registration web provided by the home delivery company. .. Further, Patent Document 2 discloses a product batch delivery preparation device that collects orders related to a customer's product delivery by communicating with the customer. Specifically, first, a transportation request including information on the customer requesting delivery, the delivery item, the delivery destination, and the quantity of the delivery item is acquired from the customer, and this information is stored in the order information storage means. Next, when the order information storage means is searched and the amount of deliveries related to the predetermined delivery destination reaches a predetermined predetermined amount, the collection information is output to the delivery person.

JP-A-2002-207800 Japanese Patent Application Laid-Open No. 2003-67653

By the way, in ordinary households, daily foods such as water, rice, bread, milk and eggs are often purchased regularly at physical stores such as supermarkets. However, in order to purchase these daily foods, it is necessary to go to a physical store, which is troublesome. Therefore, if there is a service that regularly delivers daily foods purchased at a supermarket site, which is a virtual store on the Internet, the burden on the user can be reduced. However, if such regular delivery is performed independently of the delivery of products purchased from other e-commerce sites, there may be cases where deliveries to the same user are duplicated at the same time, so there is room for improvement in delivery efficiency. Is left.

The present invention has been made in view of such circumstances, and an object of the present invention is to improve the delivery efficiency in regular delivery.

In order to solve such a problem, the present invention is connected to a network between a regular EC site that accepts regular purchases of products including daily foods and an occasional EC site that accepts occasional purchases of products, and also periodically. It provides a delivery management server that manages the delivery of deliveries in response to delivery requests and piggyback delivery requests. Here, the request for regular delivery relates to products (including daily foods) purchased on the regular EC site. The phoresis delivery is related to a product purchased on an EC site at any time, and can be selected by the user as one delivery form of the delivery at any time. Further, this delivery management server has a delivery database, a regular delivery registration unit, an occasional delivery registration unit, and a delivery arrangement unit. The delivery database manages information about the delivery of deliveries. When the regular delivery registration unit receives the regular delivery request, it registers the regular delivery with the scheduled delivery date of the delivery in the delivery database. When the phoresis delivery registration unit receives a request for a phoresis delivery, the delivery registration unit links this phoresis delivery to a specific regular delivery with the same delivery destination and registers it in the delivery database. When arranging regular delivery, the delivery arrangement department piggybacks the delivery related to this piggyback delivery on the regular delivery if the piggyback delivery associated with this regular delivery exists.

Here, in the present invention , there may be provided a delivery result processing unit that gives a predetermined incentive to the user who has selected the phoresis delivery as the delivery form of the occasional delivery.

In the present invention , the occasional delivery registration unit assigns the same delivery ID as the regular delivery as the delivery ID of the piggyback delivery, or the delivery ID of the piggyback delivery is different from the delivery ID of the piggyback delivery. By managing the correspondence with the delivery ID of the regular delivery, the phoresis delivery and the regular delivery may be linked.

In the present invention , when the scheduled delivery date of the regular delivery is changed, it is preferable that the scheduled delivery registration unit also changes the scheduled delivery date of the piggyback delivery associated with the regular delivery. Further, prior to the delivery arrangement of the regular delivery in the delivery arrangement unit, a regular delivery notification unit may be provided to send a confirmation notification of the regular delivery to the user who is the regular delivery destination. Further, the occasional delivery registration unit may perform a predetermined excess processing when the weight or size of the entire delivery exceeds a predetermined upper limit when linking the phoresis delivery to the regular delivery.

According to the present invention, a plurality of EC sites connected to the delivery management server via a network are classified into those for regular delivery and those for occasional delivery, and then the deliverables related to phoresis delivery are highly repurchasable. By piggybacking on regular delivery of products containing daily foods, it is possible to improve the delivery efficiency of regular delivery.

Overall view of the delivery network system according to the first embodiment Delivery management server block diagram A diagram showing an example of the logical configuration of scheduled delivery records in a delivery database. A diagram showing an example of the logical configuration of occasional delivery records in a delivery database. A diagram showing another example of the logical composition of records in a delivery database. Flowchart of delivery instruction program The figure which shows an example of the 1st selection screen The figure which shows an example of the 2nd selection screen The figure which shows another example of the 1st selection screen Overall view of the delivery network system according to the second embodiment

(First Embodiment)
FIG. 1 is an overall view of the delivery network system according to the first embodiment. The delivery network system 1 includes a user terminal 2 operated by user A, a regular electronic commerce site 3 (hereinafter referred to as "regular EC site 3"), and a plurality of occasional electronic commerce sites 4 (hereinafter referred to as "as needed EC site 4"). It has a delivery management server 5 that manages delivery of deliveries by the delivery company B, and these are connected to a network by the Internet. The basic delivery scheme is the same as before, and when the user A purchases the product at the EC sites 3 and 4, the delivery company B delivers the product to the user A. The feature of this embodiment is that a plurality of regular deliveries P1 to P3 having different scheduled delivery dates are set in advance based on the regular delivery schedule, and the deliveries b and c according to the product purchase on the EC site 4 at any time. Is to piggyback the delivery of the above to any of the regular deliveries P1 to P3.

The periodic EC site 3 accepts the periodic purchase of the product by the user A, and requests the delivery company B for the periodic delivery P1 to P3 corresponding to each of the deliveries a1 to a3. For example, the delivery item a1 is assigned to the regular delivery P1 on Saturday of this week, the delivery item a2 is assigned to the regular delivery P2 on Saturday of the next week, and the delivery item a3 is assigned to the regular delivery P3 on Saturday of the following week. The scheduled delivery date (including the time designation) of the regular delivery is set based on the regular delivery schedule set by the user on the regular EC site 3. Regular delivery is not limited to cases where regular delivery P1 to P3 are delivered regularly on a fixed day such that the delivery date is set every Saturday, and regular delivery is regular delivery. include. Regular delivery also includes delivery delivered on the day set by the user within a predetermined number of times within a predetermined period, for example, delivery delivered on any day set by the user up to twice a month.

As the regular EC site 3, a supermarket site, which is a virtual store on the Internet, is typically assumed, and the products sold there include water, rice, bread, fruits, milk, eggs, juice, yogurt, and natto. , At least daily foods such as tofu. As a characteristic of daily foods, they have a high degree of regular purchase such that they are consumed almost every day at home, and about 10 to 20 kinds of foods tend to be purchased regularly every week. Therefore, the regular EC site 3 provides a plurality of types of products (including daily foods) with high regular purchaseability, and the regular delivery P1 to the combination of the products purchased by the user A is the delivery items a1 to a3. Request P3 from the delivery management server.

Here, the following points can be mentioned as the business characteristics of the supermarket site. First, daily foods are delivered to home (online order) on a regular basis, for example, every Saturday from 10 to 12 o'clock. As a result, the user A can obtain the product without visiting the actual store, so that the burden on the user can be reduced. It should be noted that a predetermined upper limit may be set for the number of daily foods that can be specified in one regular delivery, such as 10 products for regular members and 20 products for premium members. Secondly, since it is a virtual store on the Internet, it does not generate a sales margin as in a physical store, and it is possible to provide daily foods to users at a lower cost than in a physical store. Third, membership fees are collected from users on a regular basis, and regular delivery costs are covered by membership fees. As a result, the operating entity can secure the necessary resources to continue the business. And fourth, one kind of product is carefully selected for one brand. This has the merit of being able to continuously secure customers for food manufacturers, and also has the merit of enabling direct communication with long-term excellent customers by posting advertisements on the regular EC site 4.

The plurality of occasional EC sites 4 accept the occasional (that is, irregular) purchase of the product by the user A, and deliver the goods to the delivery company B at any time (that is, regular delivery) corresponding to each of the deliveries b and c. Request non-regular delivery that occurs with each purchase of low-purchasable items). Examples of products with low subscriptionability include books, sporting goods, toys, car goods, and the like. In addition, there are two forms of occasional delivery, "normal delivery" and "phoresis delivery". In the present specification, "normal delivery" refers to a delivery form in which a purchased product (delivery) is delivered independently, and "phoresis delivery" refers to a purchased product (delivery). Is a delivery form that links to a specific regular delivery and piggybacks on the regular delivery.

The delivery management server 5 receives requests from external systems such as the regular EC site 3 and a plurality of occasional EC sites 4, and manages and arranges the delivery of deliveries. When the regular delivery schedule is received from the regular EC site 3, the regular delivery P1, the regular delivery P2, and the regular delivery P3 are set in the order of the earliest delivery in chronological order according to this regular delivery schedule. When a delivery request for a plurality of daily foods a1 is received from the regular EC site 3 and the regular delivery a1 is designated as the delivery service, the regular delivery P1 is set as the delivery service of the delivery a1. The same applies to the deliverables a2 and a3, and the periodical delivery p2 is set as the delivery service of the delivery item a2 and the regular delivery P3 is set as the delivery service of the delivery item a3.

When a delivery request for deliveries b and c is received from the EC site 4 at any time and normal delivery is specified as the delivery form, delivery is arranged independently without being linked to regular delivery. On the other hand, when phoresis delivery is specified as the delivery form, the deliveries b and c related to this phoresis delivery are linked to any of the regular deliveries P1 to P3 and piggybacked. For example, when a request for a phoresis delivery of the delivery item b is received from a certain EC site 4 at any time and a regular delivery P1 is specified as the delivery service, the regular delivery P1 is set as the delivery service of the delivery item b. Further, when a request for a phoresis delivery of the delivery item c is received from another EC site 4 at any time and a regular delivery P1 is specified as the delivery service, the regular delivery P1 is set as the delivery service of the delivery item c. Then, at the stage of actually arranging the regular delivery P1 based on the scheduled delivery date, if the regular delivery P1 is associated with the phoresis delivery, the collective delivery of the deliveries corresponding to this is performed. As a result, in one regular delivery P1, the original delivery a1 of the regular delivery P1 and the deliveries b and c additionally added after the phoresis delivery are collectively delivered to the user A.

If the functions of the EC site 4 (front end) are limited at any time and the cooperation with the delivery management server 5 (back end) on the network is poor, the front end vendor will separately perform the back end delivery system. Enter the designation of phoresis delivery in. Instead of this, the delivery company may be contacted individually by telephone, e-mail, or the like, and the delivery company may enter the designation of phoresis delivery. Further, the operator of the EC site 4 may request the delivery management server 5 for the piggyback delivery by operating the client connected to the delivery management server 5 at any time. Further, the request for phoresis delivery may be made not only from the EC site 4 but also from the user terminal 2 by directly logging in to the delivery management server 5.

FIG. 2 is a block diagram of the delivery management server 5. The delivery management server 5 has a regular delivery registration unit 5a, an occasional delivery registration unit 5b, a delivery arrangement unit 5c, a regular delivery notification 5d, and a delivery result processing unit 5e as functional blocks thereof. Further, the delivery management server 5 includes a user database 5f, a delivery database 5g, and the like as a storage unit for storing information necessary for performing delivery management of deliveries. The user database 5f manages a name, an address, a telephone number, a user authentication information, and the like as information about the user for each user. In addition, the delivery database 5g manages the delivery address, name, telephone number, delivery date, information on the delivery, status indicating the delivery status, and the like as information on the delivery of the delivery for each delivery item.

The regular delivery registration unit 5a receives a request from the regular EC site 3 and registers a plurality of regular deliveries in the delivery database 5g. The scheduled delivery dates for these regular deliveries are different from each other, and are set based on the regular delivery schedule received from the regular EC site 3. This schedule is determined by the user inputting the scheduled delivery date and the like on the setting screen of the regular EC site 3. In addition, the user determines the combination of daily foods (delivery) to be purchased by several days before the scheduled delivery date (deadline) of the regular delivery. Information about the delivered goods determined by the user is notified from the regular EC site 3 to the delivery management server 5 (regular delivery registration unit 5a).

Registration of regular delivery is performed by adding a new regular delivery record to the delivery database 5g. FIG. 3 is a diagram showing an example of the logical configuration of the periodic delivery record. A scheduled delivery record consists of fields such as "Delivery ID", "Scheduled delivery date", "Delivery address", "Delivery address", "Delivery", "Delivery information", "Regular delivery", and "Status". Has been done. In the "delivery ID", identification information individually numbered for each regular delivery is entered. In the "scheduled delivery date", the date and the designation of the delivery time according to the above-mentioned regular delivery schedule are entered. The user name of the delivery destination is entered in the "delivery destination". In "Delivery address", the address to be delivered is entered. Normally, the address held in the user database 5f is posted as it is, but if another address is specified by the user, the specified address is entered. The "delivery item" is filled with the delivery item to be delivered, and the "delivery item information" is filled with information about the delivery item, for example, the weight and size of the delivery item. Further, in "regular delivery", a flag (regular delivery flag) indicating that the delivery form is regular delivery is set only when the delivery form is regular delivery. Further, "Undelivered", "Delivery", "Delivery completed", etc. are entered in "Status", and these are changed at any time according to the delivery status of the delivery matter.

The figure shows an example in which three regular delivery records (delivery ID = "P1" to "P3") having different "scheduled delivery dates" are added as regular delivery with "user A" as the delivery destination. There is. The delivery of the first regular delivery record (delivery ID = "P1") is "a1", the delivery of the second regular delivery record (delivery ID = "P2") is "a2", and the delivery of the third regular delivery record. The delivery item (delivery ID = "P3") is "a3". However, unlike the occasional delivery record described later, for regular delivery records, "delivery" and "delivery information" may be left blank when the record is added (in other words, when the regular delivery schedule is set). It is permissible, and then the necessary information is filled in after the delivery is decided.

The occasional delivery registration unit 5b accepts a request from the occasional EC site 4 and registers the occasional delivery (normal delivery or phoresis delivery) in the delivery database 5g. The occasional delivery registration is performed by adding a new occasional delivery record to the delivery database 5g. FIG. 4 is a diagram showing an example of the logical configuration of the occasional delivery record. The occasional delivery record has the same logical structure as the regular delivery record described above, but is handled differently from the regular delivery in the following points. First, for occasional delivery records, regardless of whether they are regular delivery or phoresis delivery, the regular delivery flag is not set in "regular delivery" to distinguish them from regular delivery records. Further, in the case of normal delivery, the identification information individually numbered for each normal delivery is entered as the "delivery ID", and the "scheduled delivery date" and the like are also set independently. On the other hand, in the case of phoresis delivery, the identification information of the regular delivery that is the piggyback destination is quoted as the "delivery ID" without assigning an identification number, and the "scheduled delivery date" is also the regular delivery that is the piggyback destination. Information is quoted.

If the delivery destination of the phoresis delivery specified from the EC site 4 at any time is the user's workplace or the like, it is assumed that the delivery destination does not match the distribution destination of the regular delivery. In such a case, in order to promote the use of phoresis delivery, it is preferable to enable adjustment such as changing the delivery destination of phoresis delivery to that of regular delivery, subject to the consent of the user. As a specific processing flow, first, in the delivery management server 5 (as needed delivery registration unit 5b), the delivery address of the piggyback delivery received from the EC site 4 at any time and the "delivery address" stored in the user database 5f. It is checked whether or not it matches (that is, the delivery address of the regular delivery). If they do not match, the delivery management server 5 sends a confirmation notification to the EC site 4 at any time as to whether or not the delivery address of the phoresis delivery may be changed to the "delivery address". Then, upon obtaining the user's approval based on this confirmation notification, the delivery management server 5 changes the delivery address of the piggyback delivery to the "delivery address", and then transfers the delivery at any time (the piggyback delivery) to the delivery database 5g. to register. If the two do not match, some notification may be given to the user notifying that the two do not match, and the delivery address of the delivery management phoresis delivery as described above is set to the "delivery address". Instead of sending a confirmation notice as to whether or not the change may be made, it may simply be a notice that the two do not match.

The figure shows an example in which three occasional delivery records (delivery ID = “P1”, “P1”, “N6”) are added as an occasional delivery to “User A” as a delivery destination. First, the delivery item of the first occasional delivery record (delivery ID = "P1") is "b". Since the same delivery ID "P1" as that of the first scheduled delivery record shown in FIG. 3 is assigned to this occasional delivery record, it is possible that the record is a phoresis delivery record associated with this regular delivery record. Be identified. This means that the delivery "b" is piggybacked on the regular delivery of "P1". Further, the delivery item of the second occasional delivery record (delivery ID = "P1") is "c". Since the same delivery ID "P1" as that of the first scheduled delivery record shown in FIG. 3 is assigned to this occasional delivery record, it is possible that the record is a phoresis delivery record associated with this regular delivery record. Be identified. This means that the delivery "c" is piggybacked on the regular delivery of "P1". Further, the delivery of the third occasional delivery record (delivery ID = "N6") is "d". Since there is no regular delivery record having the same delivery ID "N6", it is identified that this occasional delivery record is a normal delivery record that is not associated with the regular delivery record. This means that the delivery "d" is delivered independently without being associated with any regular delivery.

The association between the phoresis delivery and the regular delivery can be performed by, for example, adopting the logical configuration of the record as shown in FIG. 5, in addition to the method of duplicating the same delivery ID as described above. This figure has the same management contents as those in FIGS. 3 and 4, but is significantly different in that unique delivery IDs “N4” and “N5” are assigned to the piggyback delivery records. In addition, a "linking destination" is added to the record, and the delivery ID of the regular delivery that is the piggyback destination is entered. As a result, it is identified that the records of the delivery IDs "N4" and "N5" are the piggyback delivery records associated with the regular delivery records of "P1". In this way, even if the same delivery ID is not duplicated, if the correspondence between the delivery ID of the phoresis delivery and the delivery ID of the regular delivery is maintained and managed, the two can be linked. This method has a great advantage especially for small and medium-sized EC businesses, and is advantageous for promoting the subscription of such businesses to this service. Many of the simple EC systems used by small and medium-sized e-commerce businesses are limited to the functions of the front end (up to ordering products), and in extreme cases, the invoice for courier services is sent by the e-commerce business. There are also cases of handwriting. In such a case, it is not always easy to adjust the delivery IDs on the delivery management server 5 side so that they are the same. According to this method, since it is not necessary to adjust the delivery ID, such a problem can be solved.

In addition to the delivery database 5g, an index table that describes the correspondence between records may be prepared separately, and the index table may be referred to when acquiring the correspondence. As a result, the processing load of the delivery management server 5 can be effectively reduced as compared with the case where the entire delivery database 5g is searched each time.

Further, the occasional delivery registration unit 5b performs a predetermined excess processing when the weight or size of the entire delivery exceeds a predetermined upper limit when linking the phoresis delivery to the regular delivery. The weight and size of each delivery can be specified from the "delivery information" of the delivery database 5g. As the excess processing, for example, it is assumed that an extra delivery fee will be incurred for the excess and the refusal of the phoresis delivery that causes the excess.

The user can change the scheduled delivery schedule once set after the fact within a predetermined time range. In this case, the regular delivery registration unit 5a changes the "scheduled delivery date" of the regular delivery in the delivery database 5g based on the change request from the regular delivery registration unit 5a (or the user terminal 2), and is linked to the regular delivery. The "scheduled delivery date" of the attached piggyback delivery is also automatically changed.

The delivery arrangement unit 5c searches the delivery database 5g by regular batch processing, extracts delivery cases that match the "scheduled delivery date" specified as the search target, and actually makes delivery arrangements. In addition, when a certain regular delivery is arranged, if there is a phoresis delivery associated with this regular delivery, the delivery related to this piggyback delivery is piggybacked on the regular delivery. For the delivery matter for which delivery arrangements have been made, the "status" of the delivery database 5g is changed from "undelivered" to "delivering".

Prior to the delivery arrangement of the regular delivery in the delivery arrangement unit 5c, the regular delivery notification unit 5d notifies the user who is the regular delivery destination of the confirmation of the regular delivery, that is, the regular delivery according to the "scheduled delivery date". Send a reminder to that effect. This confirmation notification is a form of delivering an e-mail to an address registered in advance as an e-mail address of a regular delivery destination, a form of using SNS or LINE, or a form of using the notification function of an application installed on the user terminal 2. It may be any of. In addition, the confirmation notice will be sent several days before the scheduled delivery date. By sending a confirmation notice in advance, it is possible to prevent the user from forgetting and prevent a decrease in delivery efficiency due to absence. The main body that sends the confirmation notification may be the periodic EC site 3 instead of the delivery management server 5.

The user who received the confirmation notification can change the "scheduled delivery date" of the scheduled delivery as needed. As a specific flow, for example, the regular EC site 3 notifies the user of the delivery confirmation, the regular EC site 3 accepts the change of the delivery date from the user, and the regular EC site 3 plans to deliver to the delivery management server 5. A pattern such as requesting a change of date is conceivable. Further, a pattern is also conceivable in which the delivery confirmation notification and the change of the scheduled delivery date are directly exchanged between the delivery management server 5 and the user. The target for changing the "scheduled delivery date" may be limited to the latest scheduled delivery related to the confirmation notification, or may be all future scheduled deliveries.

The delivery result processing unit 5e changes the "status" of the delivery database 5g from "delivering" to "delivered" according to the delivery result of the delivery matter. Further, when the regular delivery with the phoresis delivery is completed, the delivery result processing unit 5e gives an incentive such as points to the user who has specified / selected the phoresis delivery. The user can receive various services by accumulating a predetermined number of points. The entity that gives the incentive for the piggyback delivery may be the delivery management server 5, but may be the EC site 4 at any time.

Further, if the regular delivery cannot be completed due to reasons such as absence, the user may be charged an additional cost such as a redelivery fee via the regular EC site 3 or the like. At that time, if the regular delivery is accompanied by a piggyback delivery, the sender of each delivery (regular EC site 3 and occasional EC site 4) is specified, and the additional cost is apportioned to each sender. To claim. For example, if the regular delivery P1 shown in FIG. 1 cannot be completed, the sender of the delivery a1 (regular EC site 3) and the sender of the delivery b (as needed EC site 4) are billed for the additional cost. ) And the sender of the delivery c (as needed, EC site 4). Then, for example, the sender of the delivery item a1 is 50%, the sender of the delivery item b is 25%, the sender of the delivery item c is 25%, and so on, and the additional cost is apportioned. The proportion to be apportioned to each sender is predetermined by the apportionment table provided in the delivery management server 5.

FIG. 6 is a flowchart of a product delivery instruction program executed at the EC site 4 at any time. This program is implemented as an API (application programming interface) on the front-end EC site 4 at any time, and acts as an API (application programming interface) between the user terminal 2 and the back-end delivery management server 5.

When a product is purchased / ordered on the EC site 4 at any time, first, in step 1, the first selection screen is displayed. As shown in FIG. 7, on the first selection screen, options for the delivery form of the product purchased on the EC site 4 are displayed at any time. The delivery types as options are roughly divided into "normal delivery" and "phoresis delivery", and "normal delivery" is further divided into "express delivery", "date and time specified", and "date and time not specified". It is subdivided into. The three types of "normal delivery" are themselves known mechanisms adopted by existing EC sites. The user selects a desired one from the four options.

In step 2, the user selection operation relating to the delivery form option presented in step 1 is accepted, and it is determined whether or not "phoresis delivery" is selected by the user (step 3). When "normal delivery" is selected instead of "phoresis delivery", the process proceeds to step 4, and the delivery management server 5 gives an instruction for normal delivery, that is, an instruction to deliver the product without piggybacking on regular delivery. Will be sent to. Then, in step 9, the processing result for the normal delivery instruction in step 4 is acquired from the delivery management server 5, necessary processing is performed based on the processing result, and then a series of processing is completed.

On the other hand, when "Phooresis delivery" is selected, the process proceeds to step 5, and user authentication required for logging in to the delivery management server 5 is performed. Note that user authentication may be performed using the ID of the regular EC site 3. In this case, necessary user authentication is performed by logging in to the regular EC site 3 instead of the delivery management server 5. At the time of user authentication, the user operates the user terminal 2 and inputs authentication information (user ID, password, etc.). The authentication information is transmitted to the delivery management server 5 and collated with the user authentication information held in the user database 5f, and whether or not the authentication is possible is determined. It should be noted that the authentication may be successful if the user can log in to a specific SNS, for example, Facebook ID.

Here, in the user authentication in step 5, the user's input may be omitted by using the authentication information input by the user at the first login at the second and subsequent logins to the delivery management server 5. Typically, the authentication information can be specified from a file for storing user data, that is, a cookie, which is sent from the Web server to the user's Web browser. When logging in to the delivery management server 5 for the second time or later, the user's authentication information can be input to the delivery management server 5 by logging in to the EC site 4 at any time by omitting the input of the user's authentication information. It is possible to log in to the delivery management server 5 without the user's trouble. Further, when logging in to the delivery management server 5 for the second time or later, delivery management is performed on the selection screen of the EC site 4 at any time as shown in FIG. 8 or FIG. 9 without inputting the user authentication information to the delivery management server 5. Information acquired from the server 5 can be displayed.

If the user authentication is successful, the delivery database 5g is searched, the information about the regular delivery of this user is acquired from the delivery management server 5 (or the regular EC site 3), and the second selection screen is displayed (. Step 6). As shown in FIG. 8, on the second selection screen, a plurality of scheduled deliveries P1 to P3 having different scheduled delivery dates are displayed as options for the destination (phoresis destination) of the piggyback delivery.

In step 7, a user selection operation for selecting one of the plurality of regular deliveries P1 to P3 (Phooresis destination) presented in step 6 is accepted. Then, in step 8, one of the regular deliveries (for example, P1) selected by the user selection operation is designated as the link destination of the piggyback delivery, and then the instructions for the piggyback delivery, that is, the regular delivery P1 is piggybacked on the product. Is instructed to be delivered to the delivery management server 5. As a result, the phoresis delivery is registered in the delivery database 5g after being associated with the regular delivery P1. Then, in step 9, the processing result for the phoresis delivery instruction in step 8 is acquired from the delivery management server 5, necessary processing is performed based on the processing result, and then a series of processing is completed.

In the above-mentioned product delivery instruction program, the destination (regular delivery) for the phoresis delivery is determined through the two steps of displaying the first selection screen and displaying the second selection screen. For example, If the first selection screen for displaying one regular delivery as a regular delivery (phoresis destination) as shown in FIG. 9 is displayed, the linking destination can be determined in one step. The difference between this selection screen and that in Fig. 7 is that the destination of the "Phooresis delivery" is not left to the user's selection, but the "latest scheduled delivery" (for example, from 18:00 to 20:00 on December 3, 2018). ), And the scheduled delivery date for "latest scheduled delivery" (delivered from 18:00 to 20:00 on December 3, 2018) is displayed as the scheduled delivery date for "Phooresis delivery". be.

Here, the "most recent regular delivery" is determined after considering the shipping schedule of the product related to the phoresis delivery because the product related to the piggyback delivery cannot always be shipped immediately. For example, regular delivery P1 (18:00 to 20:00 on December 3, 2018), regular delivery P2 (18:00 to 20:00 on December 10, 2018), and regular delivery P3 (18:00 to 20:00 on December 17, 2018) If the product related to piggyback delivery can be shipped on the same day in the set state and can be handled by the regular delivery P1, the "most recent regular delivery" is the regular delivery P1. In addition, since it takes about one week to ship the product related to the phoresis delivery, if the regular delivery P1 is not in time and the regular delivery P2 can be used, the "most recent regular delivery" is the regular delivery P2. Information on the latest scheduled delivery including the scheduled delivery date is acquired from the delivery management server 5 at any time based on the request from the EC site 4. In this case, by accepting the user selection operation for selecting the phoresis delivery in step 2, the latest regular delivery is designated as the link destination of the phoresis delivery.

As described above, according to the present embodiment, it is possible to improve the delivery efficiency in the regular delivery by piggybacking the delivery product related to the piggyback delivery on the regular delivery. For the user, there is an advantage that the troublesome purchase of daily foods is freed and the products purchased at a plurality of EC sites 4 can be collectively received by regular delivery. Further, for the delivery company, the spread of regular delivery has the advantage that the delivery efficiency is improved and the frequency of redelivery can be reduced.

Further, according to the present embodiment, it is possible for the user to select either normal delivery or phoresis delivery as the delivery form of the product (delivery) purchased on the EC site 4 at any time, which is convenient for the user. Can be enhanced.

Further, according to the present embodiment, by giving a predetermined incentive to the user who has selected the phoresis delivery, the use of the phoresis delivery can be promoted and the delivery efficiency of the regular delivery can be further improved.

Further, according to the present embodiment, prior to the delivery arrangement of the regular delivery, the confirmation notification (remind) of the regular delivery is sent to the user who is the regular delivery destination, so that the delivery is caused by the absence due to the user's forgetfulness or the like. The decrease in efficiency can be suppressed.

(Second embodiment)
FIG. 10 is an overall view of the delivery network system 1 according to the second embodiment. Unlike the first embodiment, the transmission / reception of the periodic delivery schedule is performed directly between the user A and the delivery company B without the intervention of the periodic EC site 3. That is, the user directly accesses the delivery management server 5 instead of the regular EC site 3 and registers the regular delivery schedule. When the regular delivery registration unit 5a of the delivery management server 5 receives the regular delivery schedule from the user terminal 2 operated by the user, the regular delivery registration unit 5a registers a plurality of regular deliveries in the delivery database 5g on the scheduled delivery date according to this schedule. Since the other points are the same as those of the first embodiment, the same reference numerals are given and the description thereof will be omitted here.

According to the present embodiment, as in the first embodiment, the effects such as improvement of delivery efficiency in regular delivery can be obtained.

1 Delivery network system 2 User terminal 3 Regular electronic commerce site (regular EC site)
4 Anytime e-commerce site (anytime EC site)
5 Delivery management server 5a Regular delivery registration department 5b As-needed delivery registration department 5c Delivery arrangement department 5d Regular delivery notification department 5e Incentive processing department 5f User database 5g Delivery database

Claims (6)

A network connection is made between the regular EC site that accepts regular purchases of products including daily foods and the occasional EC site that accepts occasional purchases of products, and regular delivery of products purchased on the regular EC site. And the delivery that manages the delivery of the delivery in response to the request of the piggyback delivery that is related to the product purchased on the EC site at any time and that can be selected by the user as one delivery form of the delivery at any time. On the management server
A delivery database that manages information about the delivery of deliveries, and
When a request for regular delivery is received, the regular delivery registration unit that registers the regular delivery with the scheduled delivery date of the delivery in the delivery database, and
When a request for phoresis delivery is received, the delivery registration unit and the occasional delivery registration unit, which links the phoresis delivery to a specific regular delivery with the same delivery destination and registers it in the delivery database,
When arranging regular delivery , if there is a phoresis delivery associated with the regular delivery, the delivery management server is characterized by having a delivery arrangement unit that piggybacks the delivery related to the regular delivery on the regular delivery. .. The delivery management server according to claim 1 , further comprising a delivery result processing unit that gives a predetermined incentive to a user who has selected the phoresis delivery as the delivery form of the occasional delivery . The occasional delivery registration unit assigns the same delivery ID as the regular delivery as the delivery ID of the phoresis delivery, or the delivery ID of the piggyback delivery is different from the delivery ID of the piggyback delivery. The delivery management server according to claim 1 , wherein the piggyback delivery and the regular delivery are linked by managing the correspondence relationship with the delivery ID of the delivery . The delivery according to claim 1 , wherein the scheduled delivery registration unit also changes the scheduled delivery date of the piggyback delivery associated with the scheduled delivery when the scheduled delivery date of the scheduled delivery is changed. Management server. The first aspect of claim 1 is characterized in that it further has a regular delivery notification unit that sends a confirmation notification of the regular delivery to a user who is a regular delivery destination prior to the delivery arrangement of the regular delivery in the delivery arrangement unit. Delivery management server. The first aspect of the present invention is that the occasional delivery registration unit performs a predetermined excess processing when the weight or size of the entire delivery exceeds a predetermined upper limit when linking the piggyback delivery to the regular delivery. The listed delivery management server.

Images