US20020147654A1 - Real-time delivery feasibility analysis systems and methods - Google Patents
Real-time delivery feasibility analysis systems and methods Download PDFInfo
- Publication number
- US20020147654A1 US20020147654A1 US09/811,375 US81137501A US2002147654A1 US 20020147654 A1 US20020147654 A1 US 20020147654A1 US 81137501 A US81137501 A US 81137501A US 2002147654 A1 US2002147654 A1 US 2002147654A1
- Authority
- US
- United States
- Prior art keywords
- delivery
- cost
- time window
- customer
- computer
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q10/00—Administration; Management
- G06Q10/08—Logistics, e.g. warehousing, loading or distribution; Inventory or stock management
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q10/00—Administration; Management
- G06Q10/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
- G06Q10/063—Operations research, analysis or management
- G06Q10/0631—Resource planning, allocation, distributing or scheduling for enterprises or organisations
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q10/00—Administration; Management
- G06Q10/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
- G06Q10/063—Operations research, analysis or management
- G06Q10/0637—Strategic management or analysis, e.g. setting a goal or target of an organisation; Planning actions based on goals; Analysis or evaluation of effectiveness of goals
- G06Q10/06375—Prediction of business process outcome or impact based on a proposed change
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q10/00—Administration; Management
- G06Q10/08—Logistics, e.g. warehousing, loading or distribution; Inventory or stock management
- G06Q10/083—Shipping
Definitions
- This patent relates generally to delivery scheduling systems, and more particularly to systems for scheduling deliveries to be made within specified time windows.
- the distributor would typically inform the customer by telephone as to generally when the delivery would be made. For example, the distributor might inform the customer that the delivery would arrive between 9:00 am and 1:00 pm on a particular day.
- Improved versions of traditional routing and scheduling software allow customers to schedule deliveries in real time within relatively narrow time windows.
- Such software uses a “bucket method” to schedule the deliveries.
- a distributor specifies a pre-determined number of deliveries that may be scheduled for each of several delivery time windows on a particular day. As a result, each particular time window is made available to customers until all of the deliveries scheduled for that particular time window have been reserved by customers. The time window is then “closed” to further deliveries.
- a distributor might specify that five deliveries within a designated area may be scheduled for a 8:00 am-9:00 am, March 31 time window, and that a single truck will be used to make all of these deliveries.
- this delivery time window would be made available to all customers until five deliveries had been scheduled to be made within the time window.
- the program would indicate to subsequent customers that the time window was “closed” and, therefore, unavailable.
- Such software is advantageous in that it allows customers to schedule deliveries in real time, and within relatively narrow time windows.
- such software does not promote cost-efficient delivery scheduling. For example, in the above example, if the first four deliveries to be made within the 8:00 am-9:00 am, March 31 time window were scheduled to be made within a half mile of each other, and if the fifth delivery were scheduled to be made 15 miles away from any of the first four deliveries, the distributor might actually lose money making the fifth delivery. This is because the cost associated with driving fifteen miles out of the way to make the fifth delivery might be greater than the profit made from the delivery.
- the present invention seeks to provide an improved delivery scheduling system that only schedules deliveries within a particular time window if: (1) it is possible to make all scheduled deliveries within the time window; and (2) it makes business sense to make each delivery within the time window.
- the present invention accomplishes this by providing a system and method for: (1) identifying a time window in which a requested delivery may be made to a customer; (2) determining a cost of delivery that includes the cost of making the requested delivery to the customer within the time window; (3) comparing the cost of delivery with a threshold cost; and (4) responsive to the cost of delivery being less than the threshold cost, indicating that the time window is available for the delivery.
- the system preferably displays the time window to the customer in response to the cost of delivery being less than the threshold cost.
- the system and method are configured for, responsive to the cost of delivery being equal to the threshold cost, indicating that the time window is not available for the delivery.
- the system and method are also configured for, responsive to the delivery cost being greater than the threshold cost, both indicating that the time window is not available for the delivery and withholding the time window from display to the customer.
- the system and method are configured for receiving the threshold cost from a user.
- the time window is associated with a delivery vehicle that is already scheduled to make at least one confirmed delivery within the time widow
- the step of identifying a time window comprises the step of determining whether the delivery vehicle can make both the confirmed delivery and the requested delivery within the time window.
- the step of identifying the time window also preferably includes the step of determining whether the delivery capacity of the delivery vehicle would be exceeded by the requested delivery.
- the cost of delivery referenced above includes the labor costs and transportation costs associated with the delivery, and may also include the vehicle preparation costs, and vehicle loading costs associated with the delivery.
- the system and method are preferably configured for executing the steps described above for a plurality of time windows.
- the step of displaying the time window to the customer comprises displaying the time window to the customer for a predetermined period of time
- the system and method are also configured for executing the steps of: (1) determining an updated cost of delivery, the updated cost of delivery comprising the cost of making the delivery to the customer within the time window; (2) comparing the updated cost of delivery with the threshold cost; and (3) displaying the time window to the customer if the updated cost of delivery is less than the threshold cost.
- the system and method may further be configured for withholding the time window from display to the customer if the updated cost of delivery is greater than the threshold cost or if the updated cost of delivery is equal to the threshold cost.
- Another preferred embodiment of the invention comprises a system and method for performing the steps of: (1) identifying a time window in which a delivery may be made to a customer, the time window being associated with a delivery wave having a delivery wave capacity; (2) comparing a portion of the delivery wave delivery capacity that has been allocated to deliveries with a threshold value; (3) responsive to the portion of the delivery wave delivery capacity that has been allocated to deliveries being greater than the threshold value, performing the steps of: (a) determining a cost of delivery that includes the cost of making the delivery to the customer within the time window; (b) comparing the cost of delivery with a threshold cost; and (c) responsive to the cost of delivery being less than the threshold cost, indicating that the time window is available for the delivery.
- the system and method are preferably configured for, responsive to the cost of delivery being less than the threshold cost, displaying the time window to the customer. Furthermore, in this embodiment of the invention, the system and method are also preferably configured for, in response to the cost of delivery being equal to the threshold cost, indicating that the time window is not available for the delivery.
- a further preferred embodiment of the invention comprises a system and method for performing the steps of: (1) identifying a time window in which a delivery may be made to a customer; (2) identifying a customer classification associated with the customer; (3) determining a cost of delivery, the cost of delivery comprising a cost of making the delivery to the customer within the time window; (4) comparing the cost of delivery with a first threshold cost if the order classification corresponds to a first customer classification; (5) comparing the cost of delivery with a second threshold cost if the order classification corresponds to a second customer classification; (5) indicating that the time window is available for the delivery if either: (a) the cost of delivery is greater than the first threshold cost, and the customer classification corresponds to the first customer classification; or (b) the cost of delivery is greater than the second threshold cost, and the order classification corresponds to the second customer classification.
- the customer classification may correspond to either the size of an order placed by the customer, the customer's financial characteristics, or the customer's order history.
- An additional embodiment of the invention includes a computer-readable medium that includes computer-executable instructions for executing the various steps that the systems and methods described above are configured to perform.
- a further embodiment of the invention comprises a method of determining whether to offer to make a requested delivery within a particular delivery time window, the method comprising the steps of: (1) determining a cost factor associated with making the requested delivery within a particular delivery time window; (2) determining a customer factor associated with a customer requesting the requested delivery; (3) using both the cost factor and the customer factor to determine whether to offer to make the requested delivery within the particular delivery time window.
- the step of using both the cost factor and the customer factor preferably includes the steps of: (1) identifying a threshold “display window” value; (2) combining the cost factor and the customer factor to derive a combined delivery factor; and (3) in response to the combined delivery factor being greater than the “display window” value, determining to offer to make the requested delivery within the particular delivery time window.
- This embodiment of the invention preferably includes the step of, in response to the combined delivery factor being less than the “display window” value, determining to not offer to make the requested delivery within the particular delivery time window.
- the step of using both the cost factor and the customer factor may include the steps of: (1) identifying a threshold “display window” value; (2) combining the cost factor and the customer factor to derive a combined delivery factor; and (3) in response to the combined delivery factor being less than the “display window” value, displaying the particular delivery time window.
- This embodiment of the invention preferably includes the step of, in response to the combined delivery factor being greater than the “display window” value, determining to not offer to make the requested delivery within the particular delivery time window.
- the step of combining the cost factor and the customer factor comprises adding the cost factor and the customer factor.
- FIG. 1 is a first block diagram of a system according to one embodiment of the present invention.
- FIG. 2 is a second block diagram of a system according to a preferred embodiment of the present invention.
- FIG. 3 is a block diagram of a Time Window Processing Server according to a preferred embodiment of the invention.
- FIGS. 4A and 4E depict a flowchart that generally illustrates a delivery feasibility module according to the current invention.
- FIGS. 5A and 5B depict a flowchart that generally illustrates a filtering module according to the current invention.
- FIGS. 6A and 6B depict a flowchart that generally illustrates a cost analysis module according to the current invention.
- FIG. 7 is a graphic illustration of an “Add Filter” window according to the current invention.
- FIG. 8 depicts a flowchart that generally illustrates a filtering module according to an alternative embodiment of the current invention.
- FIG. 9 is a graphic illustration of a user login window according to the current invention.
- FIG. 10 is a graphic illustration of a new user sign-up window according to the current invention.
- FIG. 11 is a graphic illustration of a grocery selection window according to the current invention.
- FIG. 12 is a graphic illustration of a “Delivery Times and Dates” time window selection window according to the current invention.
- FIG. 13 is a graphic illustration of an order confirmation and logout window according to the current invention.
- the present invention may be embodied as a method, a data processing system, or a computer program product. Accordingly, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the present invention may take the form of a computer program product on a computer-readable storage medium having computer-readable program code means embodied in the storage medium. More particularly, the present invention may take the form of web-implemented computer software. Any suitable computer-readable storage medium may be utilized including hard disks, CD-ROMs, optical storage devices, or magnetic storage devices.
- These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means that implement the function specified in the flowchart block or blocks.
- the computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions that execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart block or blocks.
- blocks of the block diagrams and flowchart illustrations support combinations of means for performing the specified functions, combinations of steps for performing the specified functions and program instruction means for performing the specified functions. It will also be understood that each block of the block diagrams and flowchart illustrations, and combinations of blocks in the block diagrams and flowchart illustrations, can be implemented by special purpose hardware-based computer systems that perform the specified functions or steps, or combinations of special purpose hardware and computer instructions.
- FIG. 1 shows a block diagram of a variable time window processing system 10 in accordance with a preferred embodiment of the present invention.
- the variable time window processing system 10 includes a customer client computer 20 , one or more computer networks 30 , a web server 40 , a time window processing server 50 , and a router client computer 55 .
- the one or more computer networks 30 facilitate communication between the customer client computer 20 , the web server 40 , the time window processing server 50 , and the router client computer 55 .
- These one or more computer networks 30 may include any of a variety of types of computer networks such as the Internet, a private intranet, a public switch telephone network (PSTN), or any other type of network known in the art.
- the communication link between the customer client computer 20 and the web server 40 is implemented via the Internet 32 using Internet protocol (IP), and the communication links between the web server 40 , the time window processing server 50 , and the router client computer 55 are implemented via a Local Area Network (LAN) 35 .
- IP Internet protocol
- LAN Local Area Network
- FIG. 3 shows a block diagram of an exemplary embodiment of the time window processing server 50 of FIGS. 1 and 2.
- the time window processing server 50 includes a processor 60 that communicates with other elements within the time window processing server 50 via a system interface or bus 61 .
- a display device/input device 64 for receiving and displaying data.
- This display device/input device 64 may be, for example, a keyboard or pointing device that is used in combination with a monitor.
- the time window processing server 50 further includes memory 66 , which preferably includes both read only memory (ROM) 65 and random access memory (RAM) 67 .
- the server's ROM 65 is used to store a basic input/output system 26 (BIOS), containing the basic routines that help to transfer information between elements within the time window processing server 50 .
- BIOS basic input/output system 26
- the time window processing server 50 includes at least one storage device 63 , such as a hard disk drive, a floppy disk drive, a CD Rom drive, or optical disk drive, for storing information on various computer-readable media, such as a hard disk, a removable magnetic disk, or a CD-ROM disk.
- each of these storage devices 63 is connected to the system bus 61 by an appropriate interface.
- the storage devices 63 and their associated computer-readable media provide nonvolatile storage for the personal computer 20 . It is important to note that the computer-readable media described above could be replaced by any other type of computer-readable media known in the art. Such media include, for example, magnetic cassettes, flash memory cards, digital video disks, and Bernoulli cartridges.
- a number of program modules may be stored by the various storage devices and within RAM 67 .
- Such program modules include an operating system 80 , a delivery feasibility module 77 , a filtering module 78 , and a cost-analysis module 79 .
- the delivery feasibility module 77 , the filtering module 78 , and the cost-analysis module 79 control certain aspects of the operation of the time window processing server 50 , as is described in more detail below, with the assistance of the processor 60 and an operating system 80 .
- time window processing server 50 Also located within the time window processing server 50 is a network interface 74 , for interfacing and communicating with other elements of a computer network. It will be appreciated by one of ordinary skill in the art that one or more of the time window processing server 50 components may be located geographically remotely from other time window processing server 50 components. Furthermore, one or more of the components may be combined, and additional components performing functions described herein may be included in the time window processing server 50 .
- time window refers to a discrete block of time during which a particular delivery may be scheduled. For example, a delivery may be scheduled to be made within a 9:00 am-10:00 am time window. In this example, the scheduled delivery should be made sometime between 9:00 am and 10:00 am.
- delivery route refers to a series of scheduled deliveries that are performed by a single delivery vehicle.
- delivery wave refers to a plurality of routes that scheduled at generally the same time, and usually have common beginning and ending times.
- a “delivery wave” generally includes a plurality of delivery windows in which deliveries may be scheduled for the various routes within the delivery wave. For example, a delivery wave may extend from 8:00 am-6:00 pm and include 10 hour-long delivery windows such as 8:00 am-9:00 am and 9:00 am-10:00 am.
- delivery wave capacity and “capacity of a delivery wave” refer the maximum amount of goods that may be delivered within a particular delivery wave. This capacity is calculated by adding together the individual capacities of the various delivery trucks that are scheduled to make deliveries within the delivery wave.
- the term “delivery position” refers to a period of time within a given delivery route during which an additional delivery could possibly be scheduled. This period of time is defined relative to other deliveries already scheduled for the particular delivery route. Thus, for example, for a delivery route for which two deliveries have already been scheduled, three “delivery positions” exist for the route.
- the first delivery position represents the period of time between the time at which the delivery route is scheduled to begin and the time for which the first delivery is scheduled.
- the second delivery position represents the period of time between the time at which the first delivery is scheduled to end and the second delivery is scheduled to begin.
- the third delivery position represents the period of time between the time at which the second delivery is scheduled to end and the time at which the delivery route is scheduled to end.
- One embodiment of the present invention provides an improved delivery scheduling system that only allows deliveries to be scheduled within a particular time window if the cost of making the delivery within the particular time window would be below a specified threshold cost.
- the present invention accomplishes this by first asking a customer to specify a desired date of delivery, and then determining how much it would cost to make a requested delivery within each of a pre-determined set of time-delivery windows that are scheduled for the requested day. If the cost of making the delivery within a particular window would be less than a specified threshold cost, the system displays that time window to the customer, so that the customer may schedule a delivery within the time window. If the cost of making the delivery within the time window would be greater than or equal to the specified threshold cost, the system withholds the time window from display to the customer, so that the customer may not schedule a delivery within the time window.
- a preferred embodiment of the invention provides an improved delivery scheduling system that only schedules deliveries within a particular time window if: (1) it is possible to make all scheduled deliveries within the time window; and (2) it makes business sense to make each delivery within the particular time window.
- a system according to the present invention first receives a request from a customer that a delivery be made to a particular location on a particular date. The customer makes this request using a graphical user interface, an example of which is shown in FIGS. 9 - 13 .
- the system determines which time windows to present for choice by a customer.
- the system does this by using a delivery feasibility module 100 to individually analyze each of a pre-determined set of time windows that are scheduled for the requested day. In doing so, the feasibility module 100 determines whether it would be possible, and whether it would make business sense, to make a requested delivery within that time window.
- the feasibility module 100 updates a “window available” attribute to indicate whether the time window is available to make the requested delivery.
- the graphical user interface withholds from display to the customer any time windows having a “window available” attribute that indicates that the window should not be made available for the delivery.
- An exemplary feasibility module 100 is shown in FIGS. 4A and 4B.
- the system uses a filtering module 200 (an example of which is shown in FIGS. 5A and 5B) to determine whether it would make business sense to make the delivery within any time windows within which it was determined at step 144 of the feasibility module that it would be possible to make the required delivery.
- the filtering module 200 identifies any time windows in which it would not make business sense to make the delivery.
- the filtering module 200 indicates that these time windows should not be made available for the delivery by updating a “filter” attribute of the time window to indicate that the time window should be “filtered” from being offered to the customer.
- the feasibility module 100 indicates, via the time window's “window available” attribute, that the time window is available to make the requested delivery.
- the graphical user interface displays to the customer any time windows having a “window available” attribute that indicates that the window should be made available for the requested delivery.
- the feasibility module 100 indicates, via the time window's “window available” attribute, that the time window should not be made available for the requested delivery.
- the graphical user interface withholds from display any time windows having a “window available” attribute that indicates that the window should not be made available for the delivery.
- the system withholds the time window from display to the customer, so that the customer may not schedule a delivery within the time window.
- the system may display unavailable time windows in a different color or font to indicate that these time windows are not selectable by the user.
- the system determines whether it makes business sense to make a requested delivery by determining whether the cost of making the delivery is less than a certain threshold cost, which may be defined to vary based upon the type of customer requesting the delivery, the size of the order to be delivered, or any other factor prescribed by the distributor. For example, the distributor may specify that it would only make business sense to make a delivery having a delivery cost of over $30 if the customer orders $300 worth of goods or more. Similarly, the distributor may specify that it only makes business sense to make a delivery having a delivery cost of over $30 if the customer requesting the delivery orders an average of $500 or more from the distributor per week.
- a certain threshold cost which may be defined to vary based upon the type of customer requesting the delivery, the size of the order to be delivered, or any other factor prescribed by the distributor. For example, the distributor may specify that it would only make business sense to make a delivery having a delivery cost of over $30 if the customer orders $300 worth of goods or more. Similarly, the distributor may specify that it only makes business sense to make
- the system 10 uses three program modules to determine whether to offer a certain delivery time window to a customer. These modules, which include a delivery feasibility module 100 , a filtering module 200 , and a cost-analysis module 300 , are described in greater detail below. As will be understood by one of ordinary skill in the art, other systems according to the invention could be devised that have more or less than three program modules.
- FIGS. 4A and 4B An exemplary embodiment of a delivery feasibility module 100 used in the time window processing system 10 is illustrated in FIGS. 4A and 4B, which depict the steps performed in computer-executable code to determine whether it would be possible and whether it would make business sense to make a delivery within a particular time window.
- the system obtains a list of potential time windows for the day on which the delivery is requested. The system then advances to process the first time window at step 104 .
- the system determines, at step 108 , whether the particular time window is open for an additional delivery. In doing so, the system determines whether the time window has been manually closed. If so, the window is not open for an additional delivery.
- step 108 the system determines that the time window is open, the system advances to step 110 where it processes the first delivery route within the time window.
- step 110 the system then proceeds to step 112 , where it determines whether the delivery vehicle servicing the route has the physical capacity to make the requested delivery.
- step 112 the system determines whether there is enough physical space on the delivery vehicle to accommodate both the delivery and any other deliveries already scheduled for the route. If so, at step 114 , the system advances to process the first delivery position within the route.
- the term “delivery position” refers to a period of time within a given delivery route during which an additional delivery could possibly be scheduled.
- the first delivery position represents the period of time between the time at which the delivery route is scheduled to begin and the time for which the first delivery is scheduled.
- the second delivery position represents the period of time between the time at which the first delivery is scheduled to end and the second delivery is scheduled to begin.
- the third delivery position represents the period of time between the time at which the second delivery is scheduled to end and the time at which the delivery route is scheduled to end.
- step 116 determines whether it would be possible to make the requested delivery at this delivery position within the geographical and time constraints associated with the delivery position.
- the system would perform an analysis to determine whether the delivery could be made within the first delivery position (i.e. the time period between the starting time of the route, and the time that the first delivery is scheduled to begin). If it would be possible to make the delivery within this period of time without being late for, or missing, any other previously-scheduled delivery, the system proceeds to step 118 , where it calculates the cost of making the proposed delivery at the current delivery position.
- the system uses the cost analysis module 300 , to calculate this cost.
- the system determines whether the cost of making the proposed delivery at this delivery position is lower than a current “lowest cost delivery position” value for the route. If so, at step 122 , the system sets the “lowest cost delivery position” value equal to the cost of making the proposed delivery at this delivery position. This allows the system to keep track of the currently-known lowest cost for making the delivery within the route.
- step 122 After completing step 122 (or after either determining, at step 116 , that it was not possible to make the proposed delivery at the current delivery position within the geographical and time constraints associated with the delivery position, or determining at step 120 that the cost of making the proposed delivery at the delivery position was lower than the current “lowest cost delivery portion” value for the route), the system proceeds to step 124 where it determines whether all delivery slots for the route have been processed. If not, the system proceeds to step 126 where it advances to process the next delivery position within the route, and then repeats the process described above, beginning at step 116 , for the next delivery position within the route.
- step 124 determines, at step 124 , that all delivery positions for the route have been processed.
- step 128 determines whether the lowest cost for which the delivery may be made within the current route is less than any previously determined lowest delivery cost for any other route for the current time window. If so, at step 130 , the system sets the “lowest delivery cost” value for the time window equal to the lowest cost for which the delivery may be made within the route. This allows the system to store in memory the currently known lowest cost for which the delivery may be made within the route.
- step 130 After completing step 130 (or after either determining, at step 128 , that the lowest cost for which the delivery may be made within the current route is not less than any previously determined lowest delivery cost for any other route for the current time window, or determining, at step 112 , that the truck servicing the current route does not have the capacity to make the requested delivery), the system proceeds to step 132 , where it determines whether all routes have been processed for the current time window. If not, at step 134 , the system advances to process the next route by repeating the process described above beginning at step 112 .
- step 136 determines whether there is an additional delivery vehicle available to use to start a new route. If so, the system advances to step 138 , where it calculates the cost of making the proposed delivery via a new route. The system then proceeds to step 140 , where it determines whether the lowest cost for which the delivery may be made within the new route is less than any previously determined delivery cost for any other route. If so, the system advances to step 142 where it sets the “lowest delivery cost” value for the time window equal to the lowest cost for which the delivery may be made within the new route.
- step 142 After completing step 142 (or either after determining, at step 140 , that the lowest cost for which the delivery may be made within the new route is not less than any previously determined delivery cost for any other route, or determining, at step 136 , that there is no additional delivery vehicle available to use to start a new route), the system proceeds to step 144 .
- step 144 the system checks to see whether it had determined that it was possible, under any circumstances, to make the requested delivery within the time window. If not, the system advances to step 146 , where it updates a “window available” attribute for the time window to indicate that this time window is not available for this proposed delivery, and then proceeds to step 156 , which is discussed in greater detail below.
- step 144 determines, at step 144 , that it had determined that it was possible to make the requested delivery within the time window.
- step 148 the system applies any applicable time filters to the time window per filter module 200 .
- the system determines, at step 150 , whether the time window has been “filtered” from consideration by any applicable time window filter. If so, the system proceeds to step 152 , where it updates a “window available” attribute to indicate that the time window is not available for this proposed delivery. If not, the system executes step 154 , where it updates a “window available” attribute to indicate that the time window is available for this proposed delivery.
- step 156 determines whether all applicable time windows have been processed. If not, the system advances to step 106 and processes the next time window beginning at step 108 as described above. If the system determines, at step 156 , that all applicable time windows have been processed, the system proceeds to step 158 , where it passes time window availability information to a web server.
- the web server may use this information to determine which time windows to offer to a customer for the requested delivery. For example, the web server may display to a customer all time windows for which the “window available attribute” indicates that the time window is available for the proposed delivery. Similarly, the web server may withhold from display to a customer all time windows for which the “window available attribute” indicates that the time window is not available for the proposed delivery. Thus, in this example, the customer will only be shown time windows for which it would be both possible, and for which it would make business sense, to make the delivery.
- FIGS. 5A and 5B depict the steps performed in computer-executable code to determine whether making a delivery within a particular time window makes business sense.
- the system receives the customer type for which the filter applies.
- the filter may be defined to only apply to “Gold” type customers, which, for example, order an average of $500 or more from the distributor per week.
- step 205 the system retrieves the “lowest delivery cost” value for the time window that was determined in steps 230 and 280 of the delivery feasibility module 100 .
- the system then advances to step 210 , where it identifies a delivery wave (i.e. a block of time during which several delivery routes are scheduled) that contains the time window.
- step 215 the system determines the percentage of the delivery wave's capacity that is already consumed by confirmed deliveries.
- step 220 identifies any filters that correspond to the customer's customer type.
- step 225 where it advances to process the first of these filters.
- the system identifies the threshold reserved capacity at which the filter would begin to apply.
- the filter may be configured to apply only after 80% of the delivery capacity of the delivery wave has been reserved for confirmed deliveries. As discussed in detail below, this allows the system to prevent some types of orders from being scheduled when the delivery window is close to being fully reserved.
- step 235 the system identifies the threshold delivery cost for the filter.
- the filter will cause the system to indicate that the time window should be withheld from display to the customer. This functionality would be useful, for example, to exclude any time window from display if the cost of making a requested delivery within the time window is $30 or more.
- Steps 230 and 235 are generally executed well before a customer places an order. More specifically, these steps are first executed when the distributor defines a time window filter using an Add Filter window, such as the Add Filter window shown in FIG. 7. As may be understood from this figure, the distributor configures the filter by using a “customer-type” drop-down menu 310 to specify the type of customer to which the filter applies, and then entering the threshold delivery cost in a threshold delivery cost entry box 320 . Finally, the user specifies the percentage of delivery capacity that must be reserved before the filter is to apply by using the threshold percentage box 325 and the capacity/resources drop-down menu 330 . Alternatively, the user may use these two fields to specify that the filter is to apply after a certain percentage of resources (e.g. delivery trucks) have been fully scheduled for delivery.
- resources e.g. delivery trucks
- customer type is based upon the amount of goods that the customer regularly orders from the distributor. For example, a customer who orders $500 or more worth of goods from the distributor every week on the average may be designated a gold customer. Similarly, a customer who orders between $250 and $499 worth of goods from the distributor every week on the average may be designated a silver customer. By the same token, a customer who orders $249 or less worth of goods from the distributor every week on the average may be designated to be a bronze customer.
- customer type is based upon the value of the order placed by the customer. For example, customers placing an order for $500 or more might be considered gold customers, while customers placing an order for between $200 and $499 might be considered silver customers. As will be understood by one of ordinary skill in the art, many other factors (such as the customer's credit rating, financial history, location, the length of the business relationship with the customer, etc. . .) may be used to determine the appropriate customer type for each customer.
- step 240 determines whether the percentage of the delivery wave's capacity that is already set aside for confirmed deliveries is greater than or equal to the threshold “reserved” capacity specified within the time window filter.
- the filter were defined so that it applies when 80% or more of the delivery capacity associated with the delivery wave has been reserved for confirmed deliveries, and if 80% or more of the delivery capacity associated with the delivery wave had already been set aside for other deliveries, the answer to the inquiry posed at step 230 would be “yes.” However, if 79% or less of the delivery capacity associated with the delivery wave had been set aside for other deliveries, the answer to the inquiry posed at step 230 would be “no.”
- step 245 determines whether the cost of making the requested delivery (which is represented by the “lowest delivery cost” value for the time window) is greater than or equal to the threshold delivery cost specified within the time window filter. If so, the system proceeds to step 260 , where it updates a “filter” attribute of the time window to indicate that the time window should be “filtered” from display to the customer.
- step 245 determines at step 245 that the cost of making the requested delivery is not greater than or equal to the threshold delivery cost for the time filter, or the system determines, at step 240 , that the percentage of the delivery wave's capacity that is already consumed by confirmed deliveries is not greater than or equal to the threshold “reserved” capacity specified by the time filter
- the system proceeds to step 250 , where it determines whether all applicable filters have been processed. If so, the system updates a “filter” attribute of the time window to indicate that the time window should not be “filtered” from display to the customer. If not, the system advances to the next applicable filter at step 255 , and then repeats the process described above for the next filter beginning at step 230 .
- FIG. 8 An exemplary embodiment of a filtering module 400 according to an alternative embodiment of the invention is illustrated in FIG. 8.
- the system receives a customer type for the customer.
- the system converts the customer type into a numeric customer factor.
- this customer factor ranges from 1-10, with 1 corresponding to the most desirable customers and 10 corresponding to the least desirable customers.
- a gold customer type might correspond to a customer factor of 1
- a silver customer type might correspond to a customer factor of 5
- a bronze customer type might correspond to a customer factor of 10.
- the system determines the cost of making the requested delivery within the time window. This determination may be made using the cost analysis module, which is depicted in FIGS. 6A and 6B and discussed below.
- the system then converts this cost of making the requested delivery into a numerical system factor (which may also be called a “cost factor”) at step 420 .
- a numerical system factor which may also be called a “cost factor”
- such system factors range from 1-10, with 1 corresponding to the lowest-cost deliveries and 10 corresponding to the most expensive deliveries.
- the system converts the cost of making the requested delivery into a numerical system factor using a conversion table such as the one shown below: Cost of Delivery Cost Factor $0-10.00 1 $10.01-$20.00 5 $20.01 and above 10
- any cost of delivery that falls within the range of delivery costs in the left-hand field in a particular row in the table is converted into the cost factor that is displayed in the right-hand field that particular row.
- a cost of delivery of $15.00 would correspond to a cost factor of 1
- a cost of delivery of $40.00 would correspond to a cost factor of 5.
- Many variations of such a conversion table may be envisioned by one skilled in the art.
- step 425 determines whether the sum of the system factor and the customer factor is less than a pre-determined threshold “display window” value. If so, the system proceeds to step 430 and updates a “filter” attribute of the time window to indicate that the time window should not be “filtered” from display to the customer. If not, the system proceeds to step 430 and updates a “filter” attribute of the time window to indicate that the time window should be “filtered” from display to the customer.
- a distributor might determine that it does not make business sense to make a delivery within a time window when the sum of the customer factor and the system factor is greater than or equal to 6.
- the system would display the time window because the sum of the customer factor and the system factor would be less than 6.
- the system would not display a time window for which the customer factor were 5, and the system factor were 6, because the sum of these two values is greater than 6.
- relatively high customer values correspond to very good customers
- relatively low customer values correspond to relatively undesirable customers
- relatively low system factors correspond to relatively high delivery costs
- relatively high system factors correspond to relatively low delivery costs.
- the system determines whether the sum of the system factor and the customer factor is greater than or equal to a pre-determined threshold display value. If so, the system displays the time window to the customer. If not, the system does not display the time window to the customer.
- each factor is weighted before the customer and system factors are added and compared to a threshold display value. For example, such weighting would be useful in a situation where, in determining whether to display a particular time window, delivery cost is considered twice as important as customer type. In such a situation, the cost factor would be multiplied by two before being added to the customer factor, and before the resulting sum is compared with the threshold display value to determine whether to display a particular time window. It should be understood that many alternative mathematical algorithms that include the cost and system factors could be used to determine whether to display a particular time window.
- FIGS. 6A and 6B An exemplary cost analysis module is depicted in FIGS. 6A and 6B. However, it should be understood that numerous variations of such a cost analysis module would come to mind to one of ordinary skill in the art.
- FIGS. 6A and 6B depict the steps performed in computer-executable code to determine the cost of making a particular delivery within a particular time window.
- the system determines the time that would be required to make the delivery, as is well known in the art. For example, the system may calculate this time by adding together: (1) the estimated travel time associated with the delivery; (2) any estimated delays associated with making the delivery; and (3) the time that it would take to load and unload the items to be delivered.
- the system determines the driver's standard wages associated with the delivery. The system does this by multiplying the amount of delivery time for which the driver would be paid the driver's standard hourly wage by the driver's standard hourly wage. The system then determines, at step 315 , the driver's overtime wages that are associated with the delivery. The system does this by multiplying the amount of delivery time for which a driver would be paid the driver's overtime hourly wage by the drivers overtime hourly wage.
- the system then executes steps 320 , 325 , 330 , 335 , and 340 , in which it determines, respectfully, (1) the fuel costs associated with making the proposed delivery; (2) the vehicle maintenance costs associated with the proposed delivery; (3) the vehicle loading costs associated with making the proposed delivery; (4) any toll road costs that would be associated with the proposed delivery; and (5) the vehicle preparation costs associated with making the delivery.
- assessments are known in the prior art (e.g. the Roadnet 5000 routing and scheduling program).
- step 345 the system determines whether it would be possible to make the proposed delivery without adding a new truck. Such a determination is made in a manner known in the prior art (e.g. the Roadnet 5000 routing and scheduling program.) If so, the system proceeds to step 355 . If not, the system first determines the costs associated with adding a new truck to accommodate the delivery and then proceeds to step 355 . At step 355 , the system determines any other miscellaneous costs associated with making the proposed delivery.
- step 360 the system calculates the total costs associated with making the delivery by adding together any costs identified in steps 305 , 310 , 315 , 320 , 325 , 330 , 335 , 340 , 350 , and 355 .
- a distributor first defines a series of filters that apply to the various time windows as described above in reference to the filtering module. After the various filters have been defined, a customer may enter the system by using the customer client computer 20 to log on to the distributor's web site.
- An exemplary “login” window 500 according to a preferred embodiment of the invention is shown in FIG. 9. While this preferred embodiment is described below in relation to a routing and scheduling system for grocery delivery, it could also be used in many other contexts, such as home video delivery and laundry delivery.
- the user logs onto the website by entering the customer's user identification code in a “USER ID” Box 510 and the customer's password in a “Password” Box 520 .
- First time shoppers enter the system using a “first time shopper” key 530 , which takes them to a new user sign-up window 600 , an example of which is shown in FIG. 10.
- the new user sign-up window 600 allows a new user to define a User ID and password that are associated with their name, address, and e-mail address and provide a means of payment. This information is then stored in a customer data database for later reference.
- the customer may shop for groceries by browsing through various grocery selection windows 700 .
- An example of a grocery selection window according to a preferred embodiment of the invention is shown in FIG. 11.
- the user may select various grocery items 710 by specifying the quantity of groceries desired in the quantity box 720 , and then selecting a “bag it” key 730 . Selecting the “bag it” key 730 adds the selected item to a list of ordered items 740 that is displayed at the bottom of the grocery selection window 700 .
- the customer may press a “check out” button 750 to schedule a time for the delivery and/or the confirm the delivery.
- the system After selecting the “check out” button 750 , the system requests the user to specify a day on which the delivery is to be made. After the user selects an appropriate delivery day, the system determines which, if any, time windows are available for the particular day. The system does this by first identifying any time windows scheduled for the requested day, and then determining, for each individual time window, whether it would be possible, and whether it would make business sense, to schedule the delivery for the given time window. In a preferred embodiment of the invention, the system withholds from display any individual time windows for which a “window available” attribute indicates that the time window is not “available” for the proposed delivery.
- a time window delivery feasibility module 100 will determine that a time window is unavailable if the time window if: (1) it would not be possible to make the delivery within the individual time window; or (2) it would not make business sense to make the delivery within the individual time window.
- the system displays all other time windows 810 to the user on a “Delivery Times and Dates” selection window 800 , an example of which is shown in FIG. 12. (In FIG. 12, the 12:00 pm-1:00 pm time window has been omitted from display because it would either not be possible, or it would not make business sense to make the delivery within the time window.)
- the customer may then select a convenient time window for the delivery by activating a radio button 820 that corresponds to the desired time window. After selecting a time window for delivery, the customer may then either reserve the time window and continue shopping by selecting a “reserve order” button 840 , or move on to a confirmation and logout window 900 by selecting a “place order” button 830 .
- An exemplary confirmation and logout window 900 is shown in FIG. 13. On the confirmation and logout window 900 , the user may review the order and log off of the system by selecting a “logout” button 910 .
- the system reserves the time window so that no other customers may schedule deliveries within this time window while the time window is reserved.
- the customer may, thus, continue shopping with the assurance that, when the customer is finished shopping, they can confirm the order for delivery within the reserved time window.
- the customer selects the “check out” button after shopping, the customer is merely asked to confirm that they still would like the delivery to be made within the reserved time window. If so, the system confirms and schedules the delivery.
- the system is configured to only reserve the time window for a certain, predetermined amount of time. If the customer does not confirm the delivery within this period of the time, the system releases the time window from its reserved status so that it is made available to other customers. In such a situation, when the user selects the “check out” button 750 after the reserved time window has been released to other customers, the system again determines, based on current conditions, whether it would: (1) be possible to make the delivery within the formerly reserved time window; and (2) make business sense to make the delivery within the formerly reserved time window. The system determines whether it would make business sense to make the delivery within the time window in the manner discussed above using the current system data to calculate, for example, an updated cost of delivery associated with making the delivery within the requested time window.
- the system merely asks the customer to confirm that they would still like the delivery to be made within the formerly reserved time window. If either one of the conditions is not satisfied (i.e. under current conditions, it would no longer be possible, and/or it would not be desirable from a business perspective, to make the delivery) the system does not display the formerly-reserved time window. Rather, the system offers the customer several alternative time windows in which it would be both possible, and desirable from a business perspective, to make the delivery. The user may then select one of the alternative time windows, confirm the delivery, and log off of the system.
- the system runs an optimization routine to optimize a delivery route immediately after each new delivery is added to the route.
- the system conducts a routing analysis in which the route is optimized to minimize the cost and/or time associated with making the deliveries.
- a routing analysis may be performed, for example, using a commercially available routing and scheduling program, such as Roadnet 5000, that is implemented on a routing client computer 60 . This provides for a system that dynamically optimizes each route in real time as the route changes.
- each route should be configured to complete its various deliveries along a route that has been developed to maximize efficiency and reduce the costs associated with making the various deliveries.
- an exemplary grocery delivery system according to the present invention is described below.
- the distributor has defined gold customers as customers who, on the average, order $500 or more worth of groceries from the distributor per week.
- the distributor has defined silver customers to be customers who, on the average, order less than $500 worth of groceries from the distributor per week.
- the distributor does not want to take any orders for which delivery costs would be $30 or more.
- the distributor defines two different filters. First, using an entry screen such as the screen shown in FIG. 7, the distributor defines a first filter that specifies that, when 0% or more of the capacity of a delivery wave is occupied with confirmed deliveries, the system should not offer silver customers any time windows for which delivery costs would be $30 or more. Additionally, the distributor defines a second filter that specifies that, when 0% or more of the capacity of a delivery wave is occupied with confirmed deliveries, the system should not offer gold customers any time windows for which delivery costs would be $30 or more. These filters work together to prevent the display of any time windows to any customer for which delivery costs would be $30 or more.
- the distributor also wishes to avoid adding additional orders established near a cut-off time for accepting orders for the next delivery day, but would be willing to add such orders if the delivery costs are relatively low. Also, the distributor would be more willing to add such a delivery for a very good customer (i.e. a gold customer), than for a standard customer (i.e. a silver customer). To accomplish these goals, the distributor defines two additional filters. First, the distributor defines a third filter that specifies that, when 80% or more of the capacity of a delivery wave is occupied with confirmed deliveries, the system should not offer the time window to silver customers if the delivery costs associated with delivering within the window would be $10 or more.
- the distributor defines a fourth filter that specifies that, when 80% or more of the delivery capacity of the delivery wave is occupied with confirmed deliveries, the system should not offer the time window to gold customers if the delivery costs associated with delivering within the window would be $20 or more.
- the system will only schedule a delivery if: (1) the customer is a gold customer and the delivery would cost less than $20; or (2) the customer is a silver customer and the delivery would cost less than $10.
- a gold customer might log on to this exemplary system on Thursday, September 27, select several grocery items to be delivered, and then try to schedule an order for Friday, September 28. If the customer tried to schedule a delivery within a delivery wave for which 85% of the delivery capacity of the current delivery wave had already been reserved for current deliveries, the fourth filter would apply and the system would filter from display to the customer any time window for which delivery would cost $20 or more. Similarly, if the customer tried to schedule a delivery within a delivery wave for which only 70% of the delivery capacity of the current delivery wave had already been reserved for current deliveries, the second filter would apply and the system would filter from display to the user any time window for which delivery would cost $30 or more.
- a silver customer might log on to this exemplary system on Thursday, September 27, select several grocery items to be delivered, and then try to schedule an order for Friday, September 28. If the customer tried to schedule a delivery within a delivery wave for which 85% of the delivery capacity of the current delivery wave had already been reserved for current deliveries, the third filter would apply and the system would filter from display to the user any time window for which delivery would cost $10 or more. Similarly, if the customer tried to schedule a delivery within a delivery wave for which only 70% of the delivery capacity of the current delivery wave had already been reserved for current deliveries, the first filter would apply and the system would filter from display to the user any time window for which delivery would cost $30 or more.
Abstract
Description
- This patent relates generally to delivery scheduling systems, and more particularly to systems for scheduling deliveries to be made within specified time windows.
- Distributors often use computer systems to schedule deliveries of goods to their various customers. In the past, stand-alone computer systems located on-site at a distributor's place of business were used for this purpose. To schedule a delivery, a customer would call the distributor on the phone and verbally request a desired day and time range for delivery. Commonly, these time ranges would be relatively broad. For example, a customer might request that the delivery be made sometime between 8:00 am and 12:00 pm on a particular day. After receiving the order, the distributor would inform the customer that the distributor would call the customer back at a later time (usually on the next business day) to confirm the order.
- At the end of each business day, all of the requested orders would be entered into a delivery-scheduling program that was executed on a stand-alone computer system. This computer system would then execute a batch scheduling program to generate a delivery schedule for all of the day's orders. In assembling the delivery schedule, the program would schedule the various deliveries in a way that minimized the time and expense required to complete the deliveries.
- After a customer's requested delivery had been scheduled, the distributor would typically inform the customer by telephone as to generally when the delivery would be made. For example, the distributor might inform the customer that the delivery would arrive between 9:00 am and 1:00 pm on a particular day.
- Because prior art routing and scheduling programs were written to maximize delivery efficiency, the programs often scheduled individual deliveries to be made outside of their requested delivery time-windows or on days other than the requested delivery day. This was generally not problematic because such deliveries were usually made to retailers that were commonly staffed to conduct business (and receive deliveries) during normal business hours throughout the business week. Thus, it was generally not critical that a delivery be made within the requested time period or on a particular day. For example, to a retailer that was fully staffed on weekdays from 8:00 am - 5:00 pm from Monday through Friday, it was usually not a great inconvenience if a delivery were made between 1:00 pm and 5:00 pm on a Wednesday, rather than between 8:00 am and 12:00 pm on a Tuesday, as requested. Either way, an employee would be present to accept the delivery.
- With the increased popularity of the Internet, businesses, such as on-line grocery delivery services, have begun delivering directly to individual consumers. Because such individual consumers have jobs and other commitments that make it difficult for them to wait at home for extended periods of time to receive a delivery, it is essential that distributors have the ability to commit to making a delivery within a narrow time window and to be able to reliably deliver within the promised time window. It is further desirable to be able to instantly confirm that the delivery will be made within a certain time window. Without this convenience and dependability, many customers will not use on-line delivery services. Instead, these customers will simply drive or walk to a retailer to purchase and pick up their needed goods in person.
- Improved versions of traditional routing and scheduling software allow customers to schedule deliveries in real time within relatively narrow time windows. Such software uses a “bucket method” to schedule the deliveries. When configuring this software, a distributor specifies a pre-determined number of deliveries that may be scheduled for each of several delivery time windows on a particular day. As a result, each particular time window is made available to customers until all of the deliveries scheduled for that particular time window have been reserved by customers. The time window is then “closed” to further deliveries.
- Thus, for example, a distributor might specify that five deliveries within a designated area may be scheduled for a 8:00 am-9:00 am, March 31 time window, and that a single truck will be used to make all of these deliveries. In this example, this delivery time window would be made available to all customers until five deliveries had been scheduled to be made within the time window. After five deliveries had been scheduled to be made within the time window, the program would indicate to subsequent customers that the time window was “closed” and, therefore, unavailable.
- Such software is advantageous in that it allows customers to schedule deliveries in real time, and within relatively narrow time windows. However, such software does not promote cost-efficient delivery scheduling. For example, in the above example, if the first four deliveries to be made within the 8:00 am-9:00 am, March 31 time window were scheduled to be made within a half mile of each other, and if the fifth delivery were scheduled to be made 15 miles away from any of the first four deliveries, the distributor might actually lose money making the fifth delivery. This is because the cost associated with driving fifteen miles out of the way to make the fifth delivery might be greater than the profit made from the delivery.
- Furthermore, there might be situations in which a bucket-type delivery scheduling system would not be able to complete all of the deliveries requested for a particular time window. For example, in the example above, if each of the five deliveries that were scheduled to be made within the 8:00 am-9:00 am, March 31 time window were scheduled to be made to locations that were 15 minutes apart from each of the other delivery locations, the travel time between the 5 different destinations would be 75 minutes. Thus, it would be impossible for a single driver to complete all of the deliveries between 8:00 am and 9:00 am, as promised.
- Thus, there is a need in the art for an improved delivery scheduling system that only schedules deliveries within a particular time window if: (1) it is possible to make all scheduled deliveries within the time window; and (2) it makes business sense to make each delivery within the time window.
- The present invention seeks to provide an improved delivery scheduling system that only schedules deliveries within a particular time window if: (1) it is possible to make all scheduled deliveries within the time window; and (2) it makes business sense to make each delivery within the time window. The present invention accomplishes this by providing a system and method for: (1) identifying a time window in which a requested delivery may be made to a customer; (2) determining a cost of delivery that includes the cost of making the requested delivery to the customer within the time window; (3) comparing the cost of delivery with a threshold cost; and (4) responsive to the cost of delivery being less than the threshold cost, indicating that the time window is available for the delivery. Furthermore, the system preferably displays the time window to the customer in response to the cost of delivery being less than the threshold cost.
- In a preferred embodiment of the invention, the system and method are configured for, responsive to the cost of delivery being equal to the threshold cost, indicating that the time window is not available for the delivery. Preferably, the system and method are also configured for, responsive to the delivery cost being greater than the threshold cost, both indicating that the time window is not available for the delivery and withholding the time window from display to the customer. In this preferred embodiment of the invention, the system and method are configured for receiving the threshold cost from a user.
- In a further preferred embodiment of the invention, the time window is associated with a delivery vehicle that is already scheduled to make at least one confirmed delivery within the time widow, and the step of identifying a time window comprises the step of determining whether the delivery vehicle can make both the confirmed delivery and the requested delivery within the time window. The step of identifying the time window also preferably includes the step of determining whether the delivery capacity of the delivery vehicle would be exceeded by the requested delivery.
- Preferably, the cost of delivery referenced above includes the labor costs and transportation costs associated with the delivery, and may also include the vehicle preparation costs, and vehicle loading costs associated with the delivery. The system and method are preferably configured for executing the steps described above for a plurality of time windows.
- In another preferred embodiment of the invention, the step of displaying the time window to the customer comprises displaying the time window to the customer for a predetermined period of time, and the system and method are also configured for executing the steps of: (1) determining an updated cost of delivery, the updated cost of delivery comprising the cost of making the delivery to the customer within the time window; (2) comparing the updated cost of delivery with the threshold cost; and (3) displaying the time window to the customer if the updated cost of delivery is less than the threshold cost. In this embodiment of the invention, the system and method may further be configured for withholding the time window from display to the customer if the updated cost of delivery is greater than the threshold cost or if the updated cost of delivery is equal to the threshold cost.
- Another preferred embodiment of the invention comprises a system and method for performing the steps of: (1) identifying a time window in which a delivery may be made to a customer, the time window being associated with a delivery wave having a delivery wave capacity; (2) comparing a portion of the delivery wave delivery capacity that has been allocated to deliveries with a threshold value; (3) responsive to the portion of the delivery wave delivery capacity that has been allocated to deliveries being greater than the threshold value, performing the steps of: (a) determining a cost of delivery that includes the cost of making the delivery to the customer within the time window; (b) comparing the cost of delivery with a threshold cost; and (c) responsive to the cost of delivery being less than the threshold cost, indicating that the time window is available for the delivery. In this embodiment of the invention, the system and method are preferably configured for, responsive to the cost of delivery being less than the threshold cost, displaying the time window to the customer. Furthermore, in this embodiment of the invention, the system and method are also preferably configured for, in response to the cost of delivery being equal to the threshold cost, indicating that the time window is not available for the delivery.
- A further preferred embodiment of the invention comprises a system and method for performing the steps of: (1) identifying a time window in which a delivery may be made to a customer; (2) identifying a customer classification associated with the customer; (3) determining a cost of delivery, the cost of delivery comprising a cost of making the delivery to the customer within the time window; (4) comparing the cost of delivery with a first threshold cost if the order classification corresponds to a first customer classification; (5) comparing the cost of delivery with a second threshold cost if the order classification corresponds to a second customer classification; (5) indicating that the time window is available for the delivery if either: (a) the cost of delivery is greater than the first threshold cost, and the customer classification corresponds to the first customer classification; or (b) the cost of delivery is greater than the second threshold cost, and the order classification corresponds to the second customer classification. In this embodiment of the invention, the customer classification may correspond to either the size of an order placed by the customer, the customer's financial characteristics, or the customer's order history.
- An additional embodiment of the invention includes a computer-readable medium that includes computer-executable instructions for executing the various steps that the systems and methods described above are configured to perform.
- A further embodiment of the invention comprises a method of determining whether to offer to make a requested delivery within a particular delivery time window, the method comprising the steps of: (1) determining a cost factor associated with making the requested delivery within a particular delivery time window; (2) determining a customer factor associated with a customer requesting the requested delivery; (3) using both the cost factor and the customer factor to determine whether to offer to make the requested delivery within the particular delivery time window. The step of using both the cost factor and the customer factor preferably includes the steps of: (1) identifying a threshold “display window” value; (2) combining the cost factor and the customer factor to derive a combined delivery factor; and (3) in response to the combined delivery factor being greater than the “display window” value, determining to offer to make the requested delivery within the particular delivery time window. This embodiment of the invention preferably includes the step of, in response to the combined delivery factor being less than the “display window” value, determining to not offer to make the requested delivery within the particular delivery time window.
- Alternatively, the step of using both the cost factor and the customer factor may include the steps of: (1) identifying a threshold “display window” value; (2) combining the cost factor and the customer factor to derive a combined delivery factor; and (3) in response to the combined delivery factor being less than the “display window” value, displaying the particular delivery time window. This embodiment of the invention preferably includes the step of, in response to the combined delivery factor being greater than the “display window” value, determining to not offer to make the requested delivery within the particular delivery time window. In a preferred embodiment of the invention, the step of combining the cost factor and the customer factor comprises adding the cost factor and the customer factor.
- Having thus described the invention in general terms, reference will now be made to the accompanying drawings, which are not necessarily drawn to scale, and wherein:
- FIG. 1 is a first block diagram of a system according to one embodiment of the present invention.
- FIG. 2 is a second block diagram of a system according to a preferred embodiment of the present invention.
- FIG. 3 is a block diagram of a Time Window Processing Server according to a preferred embodiment of the invention.
- FIGS. 4A and 4E depict a flowchart that generally illustrates a delivery feasibility module according to the current invention.
- FIGS. 5A and 5B depict a flowchart that generally illustrates a filtering module according to the current invention.
- FIGS. 6A and 6B depict a flowchart that generally illustrates a cost analysis module according to the current invention.
- FIG. 7 is a graphic illustration of an “Add Filter” window according to the current invention.
- FIG. 8 depicts a flowchart that generally illustrates a filtering module according to an alternative embodiment of the current invention.
- FIG. 9 is a graphic illustration of a user login window according to the current invention.
- FIG. 10 is a graphic illustration of a new user sign-up window according to the current invention.
- FIG. 11 is a graphic illustration of a grocery selection window according to the current invention.
- FIG. 12 is a graphic illustration of a “Delivery Times and Dates” time window selection window according to the current invention.
- FIG. 13 is a graphic illustration of an order confirmation and logout window according to the current invention.
- The present invention now will be described more fully hereinafter with reference to the accompanying drawings, in which preferred embodiments of the invention are shown. This invention may, however, be embodied in many different forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the invention to those skilled in the art. Like numbers refer to like elements throughout.
- As will be appreciated by one skilled in the art, the present invention may be embodied as a method, a data processing system, or a computer program product. Accordingly, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the present invention may take the form of a computer program product on a computer-readable storage medium having computer-readable program code means embodied in the storage medium. More particularly, the present invention may take the form of web-implemented computer software. Any suitable computer-readable storage medium may be utilized including hard disks, CD-ROMs, optical storage devices, or magnetic storage devices.
- The present invention is described below with reference to block diagrams and flowchart illustrations of methods, apparatuses (i.e., systems) and computer program products according to an embodiment of the invention. It will be understood that each block of the block diagrams and flowchart illustrations, and combinations of blocks in the block diagrams and flowchart illustrations, respectively, can be implemented by computer program instructions. These computer program instructions may be loaded onto a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions which execute on the computer or other programmable data processing apparatus create means for implementing the functions specified in the flowchart block or blocks.
- These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means that implement the function specified in the flowchart block or blocks. The computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions that execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart block or blocks.
- Accordingly, blocks of the block diagrams and flowchart illustrations support combinations of means for performing the specified functions, combinations of steps for performing the specified functions and program instruction means for performing the specified functions. It will also be understood that each block of the block diagrams and flowchart illustrations, and combinations of blocks in the block diagrams and flowchart illustrations, can be implemented by special purpose hardware-based computer systems that perform the specified functions or steps, or combinations of special purpose hardware and computer instructions.
- System Architecture
- FIG. 1 shows a block diagram of a variable time
window processing system 10 in accordance with a preferred embodiment of the present invention. As may be understood from this figure, the variable timewindow processing system 10 includes acustomer client computer 20, one ormore computer networks 30, aweb server 40, a timewindow processing server 50, and arouter client computer 55. As can be appreciated by one of ordinary skill in the art, the one ormore computer networks 30 facilitate communication between thecustomer client computer 20, theweb server 40, the timewindow processing server 50, and therouter client computer 55. These one ormore computer networks 30 may include any of a variety of types of computer networks such as the Internet, a private intranet, a public switch telephone network (PSTN), or any other type of network known in the art. In a preferred embodiment of the invention shown in FIG. 2, the communication link between thecustomer client computer 20 and theweb server 40 is implemented via theInternet 32 using Internet protocol (IP), and the communication links between theweb server 40, the timewindow processing server 50, and therouter client computer 55 are implemented via a Local Area Network (LAN) 35. - FIG. 3 shows a block diagram of an exemplary embodiment of the time
window processing server 50 of FIGS. 1 and 2. The timewindow processing server 50 includes aprocessor 60 that communicates with other elements within the timewindow processing server 50 via a system interface orbus 61. Also included in the timewindow processing server 50 is a display device/input device 64 for receiving and displaying data. This display device/input device 64 may be, for example, a keyboard or pointing device that is used in combination with a monitor. The timewindow processing server 50 further includesmemory 66, which preferably includes both read only memory (ROM) 65 and random access memory (RAM) 67. The server'sROM 65 is used to store a basic input/output system 26 (BIOS), containing the basic routines that help to transfer information between elements within the timewindow processing server 50. - In addition, the time
window processing server 50 includes at least onestorage device 63, such as a hard disk drive, a floppy disk drive, a CD Rom drive, or optical disk drive, for storing information on various computer-readable media, such as a hard disk, a removable magnetic disk, or a CD-ROM disk. As will be appreciated by one of ordinary skill in the art, each of thesestorage devices 63 is connected to thesystem bus 61 by an appropriate interface. Thestorage devices 63 and their associated computer-readable media provide nonvolatile storage for thepersonal computer 20. It is important to note that the computer-readable media described above could be replaced by any other type of computer-readable media known in the art. Such media include, for example, magnetic cassettes, flash memory cards, digital video disks, and Bernoulli cartridges. - A number of program modules may be stored by the various storage devices and within
RAM 67. Such program modules include anoperating system 80, a delivery feasibility module 77, a filtering module 78, and a cost-analysis module 79. The delivery feasibility module 77, the filtering module 78, and the cost-analysis module 79 control certain aspects of the operation of the timewindow processing server 50, as is described in more detail below, with the assistance of theprocessor 60 and anoperating system 80. - Also located within the time
window processing server 50 is anetwork interface 74, for interfacing and communicating with other elements of a computer network. It will be appreciated by one of ordinary skill in the art that one or more of the timewindow processing server 50 components may be located geographically remotely from other timewindow processing server 50 components. Furthermore, one or more of the components may be combined, and additional components performing functions described herein may be included in the timewindow processing server 50. - Definitions
- As used in this specification, the term “time window” refers to a discrete block of time during which a particular delivery may be scheduled. For example, a delivery may be scheduled to be made within a 9:00 am-10:00 am time window. In this example, the scheduled delivery should be made sometime between 9:00 am and 10:00 am.
- As used in this specification, the term “delivery route” (or, simply, “route”) refers to a series of scheduled deliveries that are performed by a single delivery vehicle.
- As used in this specification, the term “delivery wave” refers to a plurality of routes that scheduled at generally the same time, and usually have common beginning and ending times. A “delivery wave” generally includes a plurality of delivery windows in which deliveries may be scheduled for the various routes within the delivery wave. For example, a delivery wave may extend from 8:00 am-6:00 pm and include 10 hour-long delivery windows such as 8:00 am-9:00 am and 9:00 am-10:00 am.
- As used in this specification, the terms “delivery wave capacity” and “capacity of a delivery wave” refer the maximum amount of goods that may be delivered within a particular delivery wave. This capacity is calculated by adding together the individual capacities of the various delivery trucks that are scheduled to make deliveries within the delivery wave.
- As used in this specification, the term “delivery position” refers to a period of time within a given delivery route during which an additional delivery could possibly be scheduled. This period of time is defined relative to other deliveries already scheduled for the particular delivery route. Thus, for example, for a delivery route for which two deliveries have already been scheduled, three “delivery positions” exist for the route. The first delivery position represents the period of time between the time at which the delivery route is scheduled to begin and the time for which the first delivery is scheduled. The second delivery position represents the period of time between the time at which the first delivery is scheduled to end and the second delivery is scheduled to begin. Similarly, the third delivery position represents the period of time between the time at which the second delivery is scheduled to end and the time at which the delivery route is scheduled to end.
- Brief Overview of System Functionality
- One embodiment of the present invention provides an improved delivery scheduling system that only allows deliveries to be scheduled within a particular time window if the cost of making the delivery within the particular time window would be below a specified threshold cost. The present invention accomplishes this by first asking a customer to specify a desired date of delivery, and then determining how much it would cost to make a requested delivery within each of a pre-determined set of time-delivery windows that are scheduled for the requested day. If the cost of making the delivery within a particular window would be less than a specified threshold cost, the system displays that time window to the customer, so that the customer may schedule a delivery within the time window. If the cost of making the delivery within the time window would be greater than or equal to the specified threshold cost, the system withholds the time window from display to the customer, so that the customer may not schedule a delivery within the time window.
- A preferred embodiment of the invention provides an improved delivery scheduling system that only schedules deliveries within a particular time window if: (1) it is possible to make all scheduled deliveries within the time window; and (2) it makes business sense to make each delivery within the particular time window. In operation, a system according to the present invention first receives a request from a customer that a delivery be made to a particular location on a particular date. The customer makes this request using a graphical user interface, an example of which is shown in FIGS.9-13.
- Next, the system determines which time windows to present for choice by a customer. The system does this by using a
delivery feasibility module 100 to individually analyze each of a pre-determined set of time windows that are scheduled for the requested day. In doing so, thefeasibility module 100 determines whether it would be possible, and whether it would make business sense, to make a requested delivery within that time window. During this process, thefeasibility module 100 updates a “window available” attribute to indicate whether the time window is available to make the requested delivery. In a preferred embodiment of the invention, the graphical user interface withholds from display to the customer any time windows having a “window available” attribute that indicates that the window should not be made available for the delivery. Anexemplary feasibility module 100 is shown in FIGS. 4A and 4B. - Within the
delivery feasibility module 100, the system uses a filtering module 200 (an example of which is shown in FIGS. 5A and 5B) to determine whether it would make business sense to make the delivery within any time windows within which it was determined atstep 144 of the feasibility module that it would be possible to make the required delivery. During this process, thefiltering module 200 identifies any time windows in which it would not make business sense to make the delivery. Thefiltering module 200 then indicates that these time windows should not be made available for the delivery by updating a “filter” attribute of the time window to indicate that the time window should be “filtered” from being offered to the customer. - Thus, if it would be both possible and desirable, from a business perspective, to make the delivery with a given time window, the
feasibility module 100 indicates, via the time window's “window available” attribute, that the time window is available to make the requested delivery. In a preferred embodiment of the invention, the graphical user interface displays to the customer any time windows having a “window available” attribute that indicates that the window should be made available for the requested delivery. - However, if it would not be both possible and desirable, from a business perspective, to make the delivery within a given time window, the
feasibility module 100 indicates, via the time window's “window available” attribute, that the time window should not be made available for the requested delivery. In a preferred embodiment of the invention, the graphical user interface withholds from display any time windows having a “window available” attribute that indicates that the window should not be made available for the delivery. In such a case, the system withholds the time window from display to the customer, so that the customer may not schedule a delivery within the time window. Alternatively, the system may display unavailable time windows in a different color or font to indicate that these time windows are not selectable by the user. - As noted above, the system determines whether it makes business sense to make a requested delivery by determining whether the cost of making the delivery is less than a certain threshold cost, which may be defined to vary based upon the type of customer requesting the delivery, the size of the order to be delivered, or any other factor prescribed by the distributor. For example, the distributor may specify that it would only make business sense to make a delivery having a delivery cost of over $30 if the customer orders $300 worth of goods or more. Similarly, the distributor may specify that it only makes business sense to make a delivery having a delivery cost of over $30 if the customer requesting the delivery orders an average of $500 or more from the distributor per week.
- The
system 10 uses three program modules to determine whether to offer a certain delivery time window to a customer. These modules, which include adelivery feasibility module 100, afiltering module 200, and a cost-analysis module 300, are described in greater detail below. As will be understood by one of ordinary skill in the art, other systems according to the invention could be devised that have more or less than three program modules. - Delivery Feasibility Module
- An exemplary embodiment of a
delivery feasibility module 100 used in the timewindow processing system 10 is illustrated in FIGS. 4A and 4B, which depict the steps performed in computer-executable code to determine whether it would be possible and whether it would make business sense to make a delivery within a particular time window. At beginningstep 102, the system obtains a list of potential time windows for the day on which the delivery is requested. The system then advances to process the first time window atstep 104. Next, the system then determines, atstep 108, whether the particular time window is open for an additional delivery. In doing so, the system determines whether the time window has been manually closed. If so, the window is not open for an additional delivery. - If, at
step 108, the system determines that the time window is open, the system advances to step 110 where it processes the first delivery route within the time window. The system then proceeds to step 112, where it determines whether the delivery vehicle servicing the route has the physical capacity to make the requested delivery. At this step, the system determines whether there is enough physical space on the delivery vehicle to accommodate both the delivery and any other deliveries already scheduled for the route. If so, at step 114, the system advances to process the first delivery position within the route. - As used in this specification, the term “delivery position” refers to a period of time within a given delivery route during which an additional delivery could possibly be scheduled. Thus, for example, for a delivery route for which two deliveries have already been scheduled, three “delivery positions” exist for the route. The first delivery position represents the period of time between the time at which the delivery route is scheduled to begin and the time for which the first delivery is scheduled. The second delivery position represents the period of time between the time at which the first delivery is scheduled to end and the second delivery is scheduled to begin. Similarly, the third delivery position represents the period of time between the time at which the second delivery is scheduled to end and the time at which the delivery route is scheduled to end.
- After advancing to process the first delivery position within the route at step114, the system progresses to step 116 to determine whether it would be possible to make the requested delivery at this delivery position within the geographical and time constraints associated with the delivery position. Thus, for example, in the example above for which two deliveries are already scheduled to be made within the route, the system would perform an analysis to determine whether the delivery could be made within the first delivery position (i.e. the time period between the starting time of the route, and the time that the first delivery is scheduled to begin). If it would be possible to make the delivery within this period of time without being late for, or missing, any other previously-scheduled delivery, the system proceeds to step 118, where it calculates the cost of making the proposed delivery at the current delivery position. In one embodiment of the invention, the system uses the
cost analysis module 300, to calculate this cost. - Next, at
step 120, the system determines whether the cost of making the proposed delivery at this delivery position is lower than a current “lowest cost delivery position” value for the route. If so, atstep 122, the system sets the “lowest cost delivery position” value equal to the cost of making the proposed delivery at this delivery position. This allows the system to keep track of the currently-known lowest cost for making the delivery within the route. - After completing step122 (or after either determining, at
step 116, that it was not possible to make the proposed delivery at the current delivery position within the geographical and time constraints associated with the delivery position, or determining atstep 120 that the cost of making the proposed delivery at the delivery position was lower than the current “lowest cost delivery portion” value for the route), the system proceeds to step 124 where it determines whether all delivery slots for the route have been processed. If not, the system proceeds to step 126 where it advances to process the next delivery position within the route, and then repeats the process described above, beginning atstep 116, for the next delivery position within the route. - If the system determines, at
step 124, that all delivery positions for the route have been processed, the system proceeds to step 128, where it determines whether the lowest cost for which the delivery may be made within the current route is less than any previously determined lowest delivery cost for any other route for the current time window. If so, atstep 130, the system sets the “lowest delivery cost” value for the time window equal to the lowest cost for which the delivery may be made within the route. This allows the system to store in memory the currently known lowest cost for which the delivery may be made within the route. - After completing step130 (or after either determining, at
step 128, that the lowest cost for which the delivery may be made within the current route is not less than any previously determined lowest delivery cost for any other route for the current time window, or determining, atstep 112, that the truck servicing the current route does not have the capacity to make the requested delivery), the system proceeds to step 132, where it determines whether all routes have been processed for the current time window. If not, atstep 134, the system advances to process the next route by repeating the process described above beginning atstep 112. - If the system determines, at
step 132, that all of the routes for the current time window have been processed, the system proceeds to step 136 where it determines whether there is an additional delivery vehicle available to use to start a new route. If so, the system advances to step 138, where it calculates the cost of making the proposed delivery via a new route. The system then proceeds to step 140, where it determines whether the lowest cost for which the delivery may be made within the new route is less than any previously determined delivery cost for any other route. If so, the system advances to step 142 where it sets the “lowest delivery cost” value for the time window equal to the lowest cost for which the delivery may be made within the new route. - After completing step142 (or either after determining, at
step 140, that the lowest cost for which the delivery may be made within the new route is not less than any previously determined delivery cost for any other route, or determining, atstep 136, that there is no additional delivery vehicle available to use to start a new route), the system proceeds to step 144. Atstep 144, the system checks to see whether it had determined that it was possible, under any circumstances, to make the requested delivery within the time window. If not, the system advances to step 146, where it updates a “window available” attribute for the time window to indicate that this time window is not available for this proposed delivery, and then proceeds to step 156, which is discussed in greater detail below. - If the system determines, at
step 144, that it had determined that it was possible to make the requested delivery within the time window, the system advances to step 148, where the system applies any applicable time filters to the time window perfilter module 200. The system then determines, atstep 150, whether the time window has been “filtered” from consideration by any applicable time window filter. If so, the system proceeds to step 152, where it updates a “window available” attribute to indicate that the time window is not available for this proposed delivery. If not, the system executesstep 154, where it updates a “window available” attribute to indicate that the time window is available for this proposed delivery. - After completing
step step 108 that the time window is not open, the system advances to step 156 where it determines whether all applicable time windows have been processed. If not, the system advances to step 106 and processes the next time window beginning atstep 108 as described above. If the system determines, atstep 156, that all applicable time windows have been processed, the system proceeds to step 158, where it passes time window availability information to a web server. - The web server may use this information to determine which time windows to offer to a customer for the requested delivery. For example, the web server may display to a customer all time windows for which the “window available attribute” indicates that the time window is available for the proposed delivery. Similarly, the web server may withhold from display to a customer all time windows for which the “window available attribute” indicates that the time window is not available for the proposed delivery. Thus, in this example, the customer will only be shown time windows for which it would be both possible, and for which it would make business sense, to make the delivery.
- Filtering Module
- An exemplary embodiment of a
filtering module 200 according to the present invention is illustrated in FIGS. 5A and 5B, which depict the steps performed in computer-executable code to determine whether making a delivery within a particular time window makes business sense. At beginningstep 203, the system receives the customer type for which the filter applies. For example, as explained in more detail below, the filter may be defined to only apply to “Gold” type customers, which, for example, order an average of $500 or more from the distributor per week. - The system then proceeds to step205, where the system retrieves the “lowest delivery cost” value for the time window that was determined in
steps 230 and 280 of thedelivery feasibility module 100. The system then advances to step 210, where it identifies a delivery wave (i.e. a block of time during which several delivery routes are scheduled) that contains the time window. Next, atstep 215, the system determines the percentage of the delivery wave's capacity that is already consumed by confirmed deliveries. The system then proceeds to step 220, where it identifies any filters that correspond to the customer's customer type. The system then executesstep 225, where it advances to process the first of these filters. - Next, the system identifies the threshold reserved capacity at which the filter would begin to apply. For example, the filter may be configured to apply only after 80% of the delivery capacity of the delivery wave has been reserved for confirmed deliveries. As discussed in detail below, this allows the system to prevent some types of orders from being scheduled when the delivery window is close to being fully reserved.
- Next, the system executes
step 235, at which the system identifies the threshold delivery cost for the filter. In a preferred embodiment of the invention, if the cost of making a delivery is greater than or equal to this cost, and the filter otherwise applies to the order, the filter will cause the system to indicate that the time window should be withheld from display to the customer. This functionality would be useful, for example, to exclude any time window from display if the cost of making a requested delivery within the time window is $30 or more. -
Steps down menu 310 to specify the type of customer to which the filter applies, and then entering the threshold delivery cost in a threshold deliverycost entry box 320. Finally, the user specifies the percentage of delivery capacity that must be reserved before the filter is to apply by using thethreshold percentage box 325 and the capacity/resources drop-down menu 330. Alternatively, the user may use these two fields to specify that the filter is to apply after a certain percentage of resources (e.g. delivery trucks) have been fully scheduled for delivery. - It is important to note that a customer's customer type may be defined in many different ways. In a preferred embodiment of the invention, customer type is based upon the amount of goods that the customer regularly orders from the distributor. For example, a customer who orders $500 or more worth of goods from the distributor every week on the average may be designated a gold customer. Similarly, a customer who orders between $250 and $499 worth of goods from the distributor every week on the average may be designated a silver customer. By the same token, a customer who orders $249 or less worth of goods from the distributor every week on the average may be designated to be a bronze customer.
- In an alternative embodiment of the invention, customer type is based upon the value of the order placed by the customer. For example, customers placing an order for $500 or more might be considered gold customers, while customers placing an order for between $200 and $499 might be considered silver customers. As will be understood by one of ordinary skill in the art, many other factors (such as the customer's credit rating, financial history, location, the length of the business relationship with the customer, etc. . .) may be used to determine the appropriate customer type for each customer.
- The system then proceeds to step240, where it determines whether the percentage of the delivery wave's capacity that is already set aside for confirmed deliveries is greater than or equal to the threshold “reserved” capacity specified within the time window filter. Thus, if the filter were defined so that it applies when 80% or more of the delivery capacity associated with the delivery wave has been reserved for confirmed deliveries, and if 80% or more of the delivery capacity associated with the delivery wave had already been set aside for other deliveries, the answer to the inquiry posed at
step 230 would be “yes.” However, if 79% or less of the delivery capacity associated with the delivery wave had been set aside for other deliveries, the answer to the inquiry posed atstep 230 would be “no.” - If the percentage of the delivery wave capacity that is already set aside for confirmed deliveries is greater than, or equal to, the threshold capacity specified by the time window filter, the system proceeds to step245, where it determines whether the cost of making the requested delivery (which is represented by the “lowest delivery cost” value for the time window) is greater than or equal to the threshold delivery cost specified within the time window filter. If so, the system proceeds to step 260, where it updates a “filter” attribute of the time window to indicate that the time window should be “filtered” from display to the customer.
- If the system either determines at
step 245 that the cost of making the requested delivery is not greater than or equal to the threshold delivery cost for the time filter, or the system determines, atstep 240, that the percentage of the delivery wave's capacity that is already consumed by confirmed deliveries is not greater than or equal to the threshold “reserved” capacity specified by the time filter, the system proceeds to step 250, where it determines whether all applicable filters have been processed. If so, the system updates a “filter” attribute of the time window to indicate that the time window should not be “filtered” from display to the customer. If not, the system advances to the next applicable filter atstep 255, and then repeats the process described above for the next filter beginning atstep 230. - Alternative Embodiment of the Filtering Module
- An exemplary embodiment of a
filtering module 400 according to an alternative embodiment of the invention is illustrated in FIG. 8. At beginningstep 405, the system receives a customer type for the customer. Next, atstep 410, the system converts the customer type into a numeric customer factor. In a preferred embodiment of the invention, this customer factor ranges from 1-10, with 1 corresponding to the most desirable customers and 10 corresponding to the least desirable customers. For example, in a system having only gold, silver, and bronze customers, a gold customer type might correspond to a customer factor of 1, a silver customer type might correspond to a customer factor of 5, and a bronze customer type might correspond to a customer factor of 10. - Next, at
step 415, the system determines the cost of making the requested delivery within the time window. This determination may be made using the cost analysis module, which is depicted in FIGS. 6A and 6B and discussed below. The system then converts this cost of making the requested delivery into a numerical system factor (which may also be called a “cost factor”) atstep 420. In a preferred embodiment of the invention, such system factors range from 1-10, with 1 corresponding to the lowest-cost deliveries and 10 corresponding to the most expensive deliveries. - In a preferred embodiment of the invention, the system converts the cost of making the requested delivery into a numerical system factor using a conversion table such as the one shown below:
Cost of Delivery Cost Factor $0-10.00 1 $10.01-$20.00 5 $20.01 and above 10 - When using such a conversion table, any cost of delivery that falls within the range of delivery costs in the left-hand field in a particular row in the table is converted into the cost factor that is displayed in the right-hand field that particular row. Thus, a cost of delivery of $15.00 would correspond to a cost factor of 1, and a cost of delivery of $40.00 would correspond to a cost factor of 5. Many variations of such a conversion table may be envisioned by one skilled in the art.
- The system then proceeds to step425, where it determines whether the sum of the system factor and the customer factor is less than a pre-determined threshold “display window” value. If so, the system proceeds to step 430 and updates a “filter” attribute of the time window to indicate that the time window should not be “filtered” from display to the customer. If not, the system proceeds to step 430 and updates a “filter” attribute of the time window to indicate that the time window should be “filtered” from display to the customer.
- For example, a distributor might determine that it does not make business sense to make a delivery within a time window when the sum of the customer factor and the system factor is greater than or equal to 6. Thus, in a situation where the customer factor were 1 and the system factor were 4, the system would display the time window because the sum of the customer factor and the system factor would be less than 6. By the same reasoning, the system would not display a time window for which the customer factor were 5, and the system factor were 6, because the sum of these two values is greater than 6.
- In an alternative embodiment of the invention, relatively high customer values (such as 10) correspond to very good customers, and relatively low customer values (such as 0) correspond to relatively undesirable customers. Also, in this embodiment of the invention, relatively low system factors correspond to relatively high delivery costs, and relatively high system factors correspond to relatively low delivery costs. In this embodiment of the invention, the system determines whether the sum of the system factor and the customer factor is greater than or equal to a pre-determined threshold display value. If so, the system displays the time window to the customer. If not, the system does not display the time window to the customer.
- In a further alternative embodiment of the invention, each factor is weighted before the customer and system factors are added and compared to a threshold display value. For example, such weighting would be useful in a situation where, in determining whether to display a particular time window, delivery cost is considered twice as important as customer type. In such a situation, the cost factor would be multiplied by two before being added to the customer factor, and before the resulting sum is compared with the threshold display value to determine whether to display a particular time window. It should be understood that many alternative mathematical algorithms that include the cost and system factors could be used to determine whether to display a particular time window.
- Cost Analysis Module
- Various methods for determining the cost of making a particular delivery are known in the art. For example, several publicly-available prior art routing and scheduling programs (for example, Roadnet 5000) are capable of determining the cost of making a delivery to a particular customer. Such routing and scheduling programs may be implemented, for example, on a
routing client computer 60. “User's Guide to Roadnet 5000, Routing and Scheduling System, Version 5.6” (Roadnet Technologies, Inc. 1996), and “Roadnet 5000, Operations Guide, Version 6.02” (Roadnet Technologies, Inc. 1997) are incorporated herein by reference. - An exemplary cost analysis module is depicted in FIGS. 6A and 6B. However, it should be understood that numerous variations of such a cost analysis module would come to mind to one of ordinary skill in the art.
- As noted above, an exemplary embodiment of a
cost analysis module 300 according to the present invention is illustrated in FIGS. 6A and 6B. These figures depict the steps performed in computer-executable code to determine the cost of making a particular delivery within a particular time window. At beginningstep 305, the system determines the time that would be required to make the delivery, as is well known in the art. For example, the system may calculate this time by adding together: (1) the estimated travel time associated with the delivery; (2) any estimated delays associated with making the delivery; and (3) the time that it would take to load and unload the items to be delivered. - Next, at
step 310, the system determines the driver's standard wages associated with the delivery. The system does this by multiplying the amount of delivery time for which the driver would be paid the driver's standard hourly wage by the driver's standard hourly wage. The system then determines, atstep 315, the driver's overtime wages that are associated with the delivery. The system does this by multiplying the amount of delivery time for which a driver would be paid the driver's overtime hourly wage by the drivers overtime hourly wage. - The system then executes
steps - Next, at
step 345, the system determines whether it would be possible to make the proposed delivery without adding a new truck. Such a determination is made in a manner known in the prior art (e.g. the Roadnet 5000 routing and scheduling program.) If so, the system proceeds to step 355. If not, the system first determines the costs associated with adding a new truck to accommodate the delivery and then proceeds to step 355. Atstep 355, the system determines any other miscellaneous costs associated with making the proposed delivery. Finally, atstep 360, the system calculates the total costs associated with making the delivery by adding together any costs identified insteps - Operation of a System According to a Preferred Embodiment of the Invention
- To use a system according to a preferred embodiment of the invention, a distributor first defines a series of filters that apply to the various time windows as described above in reference to the filtering module. After the various filters have been defined, a customer may enter the system by using the
customer client computer 20 to log on to the distributor's web site. An exemplary “login”window 500 according to a preferred embodiment of the invention is shown in FIG. 9. While this preferred embodiment is described below in relation to a routing and scheduling system for grocery delivery, it could also be used in many other contexts, such as home video delivery and laundry delivery. - As may be understood from FIG. 9, the user logs onto the website by entering the customer's user identification code in a “USER ID”
Box 510 and the customer's password in a “Password”Box 520. First time shoppers enter the system using a “first time shopper”key 530, which takes them to a new user sign-upwindow 600, an example of which is shown in FIG. 10. As may be understood from this figure, the new user sign-upwindow 600 allows a new user to define a User ID and password that are associated with their name, address, and e-mail address and provide a means of payment. This information is then stored in a customer data database for later reference. - After the customer logs onto the system, the customer may shop for groceries by browsing through various
grocery selection windows 700. An example of a grocery selection window according to a preferred embodiment of the invention is shown in FIG. 11. As may be understood from this figure, the user may selectvarious grocery items 710 by specifying the quantity of groceries desired in thequantity box 720, and then selecting a “bag it”key 730. Selecting the “bag it” key 730 adds the selected item to a list of ordereditems 740 that is displayed at the bottom of thegrocery selection window 700. At any time, the customer may press a “check out”button 750 to schedule a time for the delivery and/or the confirm the delivery. - After selecting the “check out”
button 750, the system requests the user to specify a day on which the delivery is to be made. After the user selects an appropriate delivery day, the system determines which, if any, time windows are available for the particular day. The system does this by first identifying any time windows scheduled for the requested day, and then determining, for each individual time window, whether it would be possible, and whether it would make business sense, to schedule the delivery for the given time window. In a preferred embodiment of the invention, the system withholds from display any individual time windows for which a “window available” attribute indicates that the time window is not “available” for the proposed delivery. As noted above, a time windowdelivery feasibility module 100 will determine that a time window is unavailable if the time window if: (1) it would not be possible to make the delivery within the individual time window; or (2) it would not make business sense to make the delivery within the individual time window. The system displays allother time windows 810 to the user on a “Delivery Times and Dates”selection window 800, an example of which is shown in FIG. 12. (In FIG. 12, the 12:00 pm-1:00 pm time window has been omitted from display because it would either not be possible, or it would not make business sense to make the delivery within the time window.) - The customer may then select a convenient time window for the delivery by activating a
radio button 820 that corresponds to the desired time window. After selecting a time window for delivery, the customer may then either reserve the time window and continue shopping by selecting a “reserve order”button 840, or move on to a confirmation andlogout window 900 by selecting a “place order”button 830. An exemplary confirmation andlogout window 900 is shown in FIG. 13. On the confirmation andlogout window 900, the user may review the order and log off of the system by selecting a “logout”button 910. - If the user chooses to reserve the time window and continue shopping, the system reserves the time window so that no other customers may schedule deliveries within this time window while the time window is reserved. The customer may, thus, continue shopping with the assurance that, when the customer is finished shopping, they can confirm the order for delivery within the reserved time window. Thus, in this case, when the customer selects the “check out” button after shopping, the customer is merely asked to confirm that they still would like the delivery to be made within the reserved time window. If so, the system confirms and schedules the delivery.
- In a preferred embodiment of the invention, the system is configured to only reserve the time window for a certain, predetermined amount of time. If the customer does not confirm the delivery within this period of the time, the system releases the time window from its reserved status so that it is made available to other customers. In such a situation, when the user selects the “check out”
button 750 after the reserved time window has been released to other customers, the system again determines, based on current conditions, whether it would: (1) be possible to make the delivery within the formerly reserved time window; and (2) make business sense to make the delivery within the formerly reserved time window. The system determines whether it would make business sense to make the delivery within the time window in the manner discussed above using the current system data to calculate, for example, an updated cost of delivery associated with making the delivery within the requested time window. - If both of the above conditions are satisfied, the system merely asks the customer to confirm that they would still like the delivery to be made within the formerly reserved time window. If either one of the conditions is not satisfied (i.e. under current conditions, it would no longer be possible, and/or it would not be desirable from a business perspective, to make the delivery) the system does not display the formerly-reserved time window. Rather, the system offers the customer several alternative time windows in which it would be both possible, and desirable from a business perspective, to make the delivery. The user may then select one of the alternative time windows, confirm the delivery, and log off of the system.
- In a further preferred embodiment of the invention, the system runs an optimization routine to optimize a delivery route immediately after each new delivery is added to the route. To do this, the system conducts a routing analysis in which the route is optimized to minimize the cost and/or time associated with making the deliveries. Such a routing analysis may be performed, for example, using a commercially available routing and scheduling program, such as Roadnet 5000, that is implemented on a
routing client computer 60. This provides for a system that dynamically optimizes each route in real time as the route changes. - As a result, at any given point in time, each route should be configured to complete its various deliveries along a route that has been developed to maximize efficiency and reduce the costs associated with making the various deliveries.
- Exemplary Grocery Delivery System
- In order to further illustrate possible implementations of the invention, an exemplary grocery delivery system according to the present invention is described below. In this system, only two customer types have been defined by the distributor. The distributor has defined gold customers as customers who, on the average, order $500 or more worth of groceries from the distributor per week. Similarly, the distributor has defined silver customers to be customers who, on the average, order less than $500 worth of groceries from the distributor per week.
- The distributor does not want to take any orders for which delivery costs would be $30 or more. To accomplish this, the distributor defines two different filters. First, using an entry screen such as the screen shown in FIG. 7, the distributor defines a first filter that specifies that, when 0% or more of the capacity of a delivery wave is occupied with confirmed deliveries, the system should not offer silver customers any time windows for which delivery costs would be $30 or more. Additionally, the distributor defines a second filter that specifies that, when 0% or more of the capacity of a delivery wave is occupied with confirmed deliveries, the system should not offer gold customers any time windows for which delivery costs would be $30 or more. These filters work together to prevent the display of any time windows to any customer for which delivery costs would be $30 or more.
- The distributor also wishes to avoid adding additional orders established near a cut-off time for accepting orders for the next delivery day, but would be willing to add such orders if the delivery costs are relatively low. Also, the distributor would be more willing to add such a delivery for a very good customer (i.e. a gold customer), than for a standard customer (i.e. a silver customer). To accomplish these goals, the distributor defines two additional filters. First, the distributor defines a third filter that specifies that, when 80% or more of the capacity of a delivery wave is occupied with confirmed deliveries, the system should not offer the time window to silver customers if the delivery costs associated with delivering within the window would be $10 or more. Additionally, the distributor defines a fourth filter that specifies that, when 80% or more of the delivery capacity of the delivery wave is occupied with confirmed deliveries, the system should not offer the time window to gold customers if the delivery costs associated with delivering within the window would be $20 or more. Thus, after 80% of the delivery capacity of a given delivery wave has been reserved for other deliveries, the system will only schedule a delivery if: (1) the customer is a gold customer and the delivery would cost less than $20; or (2) the customer is a silver customer and the delivery would cost less than $10.
- In one example, a gold customer might log on to this exemplary system on Thursday, September 27, select several grocery items to be delivered, and then try to schedule an order for Friday, September 28. If the customer tried to schedule a delivery within a delivery wave for which 85% of the delivery capacity of the current delivery wave had already been reserved for current deliveries, the fourth filter would apply and the system would filter from display to the customer any time window for which delivery would cost $20 or more. Similarly, if the customer tried to schedule a delivery within a delivery wave for which only 70% of the delivery capacity of the current delivery wave had already been reserved for current deliveries, the second filter would apply and the system would filter from display to the user any time window for which delivery would cost $30 or more.
- In another example, a silver customer might log on to this exemplary system on Thursday, September 27, select several grocery items to be delivered, and then try to schedule an order for Friday, September 28. If the customer tried to schedule a delivery within a delivery wave for which 85% of the delivery capacity of the current delivery wave had already been reserved for current deliveries, the third filter would apply and the system would filter from display to the user any time window for which delivery would cost $10 or more. Similarly, if the customer tried to schedule a delivery within a delivery wave for which only 70% of the delivery capacity of the current delivery wave had already been reserved for current deliveries, the first filter would apply and the system would filter from display to the user any time window for which delivery would cost $30 or more.
- Conclusion
- Many modifications and other embodiments of the invention will come to mind to one skilled in the art to which this invention pertains having the benefit of the teachings presented in the foregoing descriptions and the associated drawings. Therefore, it is to be understood that the invention is not to be limited to the specific embodiments disclosed and that modifications and other embodiments are intended to be included within the scope of the appended claims. Although specific terms are employed herein, they are used in a generic and descriptive sense only and not for purposes of limitation.
Claims (78)
Priority Applications (4)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US09/811,375 US6701299B2 (en) | 2001-03-16 | 2001-03-16 | Real-time delivery feasibility analysis systems and methods |
AU2002255829A AU2002255829A1 (en) | 2001-03-16 | 2002-03-18 | Real-time delivery feasibility analysis systems and methods |
PCT/US2002/008489 WO2002075500A2 (en) | 2001-03-16 | 2002-03-18 | Real-time delivery feasibility analysis systems and methods |
MXPA03008347A MXPA03008347A (en) | 2001-03-16 | 2002-03-18 | Real-time delivery feasibility analysis systems and methods. |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US09/811,375 US6701299B2 (en) | 2001-03-16 | 2001-03-16 | Real-time delivery feasibility analysis systems and methods |
Publications (2)
Publication Number | Publication Date |
---|---|
US20020147654A1 true US20020147654A1 (en) | 2002-10-10 |
US6701299B2 US6701299B2 (en) | 2004-03-02 |
Family
ID=25206375
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US09/811,375 Expired - Lifetime US6701299B2 (en) | 2001-03-16 | 2001-03-16 | Real-time delivery feasibility analysis systems and methods |
Country Status (4)
Country | Link |
---|---|
US (1) | US6701299B2 (en) |
AU (1) | AU2002255829A1 (en) |
MX (1) | MXPA03008347A (en) |
WO (1) | WO2002075500A2 (en) |
Cited By (35)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20020138293A1 (en) * | 2000-07-06 | 2002-09-26 | Hiroshi Kawahara | Transaction adjusting device |
US20040030604A1 (en) * | 2002-08-07 | 2004-02-12 | United Parcel Service Of America, Inc. | Parcel or service delivery with partially scheduled time windows |
US20040102983A1 (en) * | 2002-11-27 | 2004-05-27 | Carlson Kent R. | Appointment and load-leveling system |
US20050049942A1 (en) * | 2002-10-15 | 2005-03-03 | Richard Dominique M. | Method for forecasting consumption and generating optimal delivery schedules for vehicles involved in delivering propane and other consumables to end consumers |
US20060069601A1 (en) * | 2001-08-10 | 2006-03-30 | United Parcel Service Of America, Inc. | Systems and methods for scheduling reoccurring deliveries and pickups |
US20080294474A1 (en) * | 2001-04-13 | 2008-11-27 | United States Postal Services | Manifest delivery system and method |
US20090144109A1 (en) * | 2007-10-30 | 2009-06-04 | Electrolux Home Products, Inc. | Method and apparatus for monitoring an order status |
WO2010027469A1 (en) * | 2008-09-04 | 2010-03-11 | United Parcel Service Of America, Inc. | Determining vehicle visit costs to a geographic area |
US20100094769A1 (en) * | 2008-09-04 | 2010-04-15 | United Parcel Service Of America, Inc. | Vehicle routing and scheduling systems |
US20100094688A1 (en) * | 2008-09-04 | 2010-04-15 | United Parcel Service Of America, Inc. | Driver training systems |
US20100100315A1 (en) * | 2008-09-04 | 2010-04-22 | United Parcel Service Of America, Inc. | Determining Speed Parameters In A Geographic Area |
US7716083B1 (en) * | 2004-02-13 | 2010-05-11 | Fine Food-To-Go, Inc. | Apparatus and method for delivering freshly-prepared fine food |
US20100235210A1 (en) * | 2009-03-11 | 2010-09-16 | United Parcel Service Of America, Inc. | Scheduled delivery service systems, apparatuses, methods, and computer programs embodied on computer-readable media |
US20130138330A1 (en) * | 2011-11-25 | 2013-05-30 | Jiefeng Xu | System and method to optimize mass transport vehicle routing based on ton-mile cost information |
US20140095350A1 (en) * | 2012-10-02 | 2014-04-03 | Wal-Mart Stores, Inc. | Method And System To Facilitate Same Day Delivery Of Items To A Customer |
US20140214715A1 (en) * | 2013-01-30 | 2014-07-31 | Command Alkon Incorporated | Scheduling system and method for distribution of perishable loads of pre-mixed concrete to multiple sites |
US20150100365A1 (en) * | 2013-10-07 | 2015-04-09 | Elemica, Inc. | Constraint optimization method and system for supply chain management |
US20160148152A1 (en) * | 2014-04-24 | 2016-05-26 | Toshiba Tec Kabushiki Kaisha | Shopping supporting system |
US10304028B2 (en) | 2008-12-19 | 2019-05-28 | United Parcel Service Of America, Inc. | Trailer utilization systems, methods, computer programs embodied on computer-readable media, and apparatuses |
US10346784B1 (en) | 2012-07-27 | 2019-07-09 | Google Llc | Near-term delivery system performance simulation |
US10387822B1 (en) | 2013-02-07 | 2019-08-20 | United Parcel Service Of America, Inc. | Systems and methods for synchronized delivery |
US20200143319A1 (en) * | 2018-11-01 | 2020-05-07 | Walmart Apollo, Llc | Systems and methods for determining delivery time and route assignments |
US10664793B1 (en) * | 2019-03-18 | 2020-05-26 | Coupang Corp. | Systems and methods for automatic package tracking and prioritized reordering |
AU2020264260A1 (en) * | 2019-10-25 | 2021-05-13 | Coupang Corp. | Systems and methods for automatic package reordering using delivery wave systems |
US11144870B2 (en) * | 2015-09-21 | 2021-10-12 | United Parcel Service Of America, Inc. | Systems and methods for reserving space in carrier vehicles to provide on demand delivery services |
US11151507B2 (en) * | 2019-03-18 | 2021-10-19 | Coupang Corp. | Systems and methods for automatic package reordering using delivery wave systems |
US11257023B1 (en) * | 2019-12-13 | 2022-02-22 | Amazon Technologies, Inc. | Enhanced delivery option interfaces |
US11455581B2 (en) * | 2018-06-11 | 2022-09-27 | Palantir Technologies Inc. | Methods and systems for providing a user interface for managing parts production and delivery statuses |
US11475395B2 (en) | 2018-01-19 | 2022-10-18 | Walmart Apollo, Llc | Systems and methods for combinatorial resource optimization |
US20220351107A1 (en) * | 2021-04-29 | 2022-11-03 | Shopify Inc. | Automated request fulfilment processing |
US11526831B1 (en) * | 2019-12-13 | 2022-12-13 | Amazon Technologies, Inc. | Enhanced delivery option interfaces |
US20230111072A1 (en) * | 2020-06-30 | 2023-04-13 | Asahi Kasei Kabushiki Kaisha | Device, method, and non-transitory computer readable medium |
US20230169415A1 (en) * | 2018-01-19 | 2023-06-01 | Walmart Apollo, Llc | Systems and methods for combinatorial resource optimization |
US11928641B2 (en) * | 2020-09-30 | 2024-03-12 | International Business Machines Corporation | Self adaptive delivery based on simulated disruption |
US11948185B2 (en) | 2020-09-25 | 2024-04-02 | Walmart Apollo, Llc | Automatically merging pickup and delivery time slots from nearby stores |
Families Citing this family (90)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20010047287A1 (en) * | 2000-03-31 | 2001-11-29 | Simon Jacobs | Finding technique for a scheduling system |
US7150017B1 (en) * | 2000-08-29 | 2006-12-12 | International Business Machines Corporation | System and method for scheduling digital information transmission and retransmission on a network during time slots |
US7403994B1 (en) * | 2000-08-29 | 2008-07-22 | International Business Machines Corporation | Method of doing business over a network by transmission and retransmission of digital information on a network during time slots |
US8781873B2 (en) * | 2001-04-02 | 2014-07-15 | Siebel Systems, Inc. | Method and system for scheduling activities |
US7313530B2 (en) * | 2001-04-10 | 2007-12-25 | General Electric Company | Methods and systems for generating and displaying the capacity of a delivery management system |
US20020165747A1 (en) * | 2001-05-01 | 2002-11-07 | The Boeing Company | Supply chain visibility system and method |
US7353181B2 (en) * | 2001-08-15 | 2008-04-01 | Hewlett-Packard Development Company, L.P. | Allocating freight haulage jobs |
US20030036938A1 (en) * | 2001-08-16 | 2003-02-20 | International Business Machines Corporation | Method and system for delivery of products within a predetermined time period |
US20030040944A1 (en) * | 2001-08-22 | 2003-02-27 | Hileman Ryan M. | On-demand transportation system |
US20030125963A1 (en) * | 2001-12-27 | 2003-07-03 | Koninklijke Philips Electronics N.V. | Wireless interactive rendezvous system for delivering goods and services |
US7124098B2 (en) * | 2002-10-07 | 2006-10-17 | The Kroger Company | Online shopping system |
US20040133446A1 (en) * | 2002-11-01 | 2004-07-08 | United Parcel Service Of America, Inc. | Alternate delivery location methods and systems |
CA2520212A1 (en) * | 2003-04-15 | 2004-10-28 | United Parcel Service Of America, Inc. | Rush hour modelling for routing and scheduling |
US6934594B2 (en) * | 2003-07-18 | 2005-08-23 | Dell Products L.P. | System for determining carrier service using logistics considerations |
US20050015167A1 (en) * | 2003-07-18 | 2005-01-20 | Searcy Allison Fay | Synchronized production with dynamic logistics routing |
US7853491B2 (en) * | 2004-03-08 | 2010-12-14 | Sap Ag | Purchase orders based on purchasing list, capacity plans, assortment plans, and area spread assortment plans |
US8370184B2 (en) * | 2004-03-08 | 2013-02-05 | Sap Aktiengesellschaft | System and method for assortment planning |
US7693749B2 (en) * | 2004-03-08 | 2010-04-06 | Sap Ag | System and computer product for managing purchase orders |
US7660742B2 (en) * | 2004-03-08 | 2010-02-09 | Sap Aktiengesellschaft | Method of and system for processing purchase orders |
US7752067B2 (en) * | 2004-03-08 | 2010-07-06 | Sap Aktiengesellschaft | System and method for assortment planning |
US7805335B2 (en) * | 2004-03-08 | 2010-09-28 | Sap Ag | Purchase list having status indicators |
US7739203B2 (en) * | 2004-03-08 | 2010-06-15 | Sap Aktiengesellschaft | Method and system for classifying retail products and services using price band categories |
US8423428B2 (en) * | 2004-03-08 | 2013-04-16 | Sap Ag | Method for allocation of budget to order periods and delivery periods in a purchase order system |
US7983962B2 (en) * | 2004-03-08 | 2011-07-19 | Sap Aktiengesellschaft | Method and system for purchase order data entry |
US7742948B2 (en) * | 2004-03-08 | 2010-06-22 | Sap Aktiengesellschaft | Method of and system for allocating an OTB-relevant purchasing contract |
US7813949B2 (en) | 2004-03-08 | 2010-10-12 | Sap Ag | Method and system for flexible budgeting in a purchase order system |
US8050956B2 (en) * | 2004-03-08 | 2011-11-01 | Sap Ag | Computer-readable medium, program product, and system for providing a schedule bar with event dates to monitor procurement of a product |
US7647250B2 (en) * | 2004-03-08 | 2010-01-12 | Sap Ag | Method and program product for event monitoring |
US7343315B2 (en) * | 2004-03-08 | 2008-03-11 | Sap Aktiengesellschaft | System and method of efficient scheduling and processing of purchase orders |
US8392231B2 (en) * | 2004-03-08 | 2013-03-05 | Sap Aktiengesellschaft | System and method for performing assortment definition |
US8108270B2 (en) * | 2004-03-08 | 2012-01-31 | Sap Ag | Method and system for product layout display using assortment groups |
US8027886B2 (en) * | 2004-03-08 | 2011-09-27 | Sap Aktiengesellschaft | Program product for purchase order processing |
US8639548B2 (en) * | 2004-03-08 | 2014-01-28 | Sap Aktiengesellschaft | System and method for assortment planning |
US8788372B2 (en) | 2004-03-08 | 2014-07-22 | Sap Aktiengesellschaft | Method and system for classifying retail products and services using characteristic-based grouping structures |
US7831487B2 (en) | 2004-03-08 | 2010-11-09 | Sap Ag | Method and system for scheduling purchase orders |
US8050990B2 (en) * | 2004-03-08 | 2011-11-01 | Sap Ag | Method of and system for generating purchase orders using an auction process |
US20050197911A1 (en) * | 2004-03-08 | 2005-09-08 | Sap Aktiengesellschaft | Method and system for automated contract determination |
US8285584B2 (en) | 2004-03-08 | 2012-10-09 | Sap Ag | System and method for performing assortment planning |
US8046273B2 (en) * | 2004-03-08 | 2011-10-25 | Sap Ag | System and method for purchase order creation, procurement, and controlling |
US8655697B2 (en) * | 2004-04-16 | 2014-02-18 | Sap Aktiengesellschaft | Allocation table generation from assortment planning |
US20060059031A1 (en) * | 2004-08-06 | 2006-03-16 | Sap Aktiengesellschaft | Risk management |
WO2006041557A2 (en) * | 2004-10-07 | 2006-04-20 | Kenan Advantage Group, Inc. | Server-based systems and methods for processing fuel orders |
US20090070175A1 (en) * | 2004-10-07 | 2009-03-12 | Kenan Advantage Group, Inc. | Mobile-Based Systems And Methods For Processing Fuel Orders |
US7624024B2 (en) * | 2005-04-18 | 2009-11-24 | United Parcel Service Of America, Inc. | Systems and methods for dynamically updating a dispatch plan |
JP2008543695A (en) * | 2005-05-09 | 2008-12-04 | ユナイテッド パーセル サービス オブ アメリカ インコーポレイテッド | System and method for routing and scheduling |
US20060282321A1 (en) * | 2005-05-19 | 2006-12-14 | Greenhorizons Group Of Farms Ltd. | Method and system for bulk soil marketing, order entry and delivery |
EP2605196A1 (en) * | 2005-06-21 | 2013-06-19 | United Parcel Service Of America, Inc. | Systems and Methods for Providing Personalized Delivery Services |
US7765131B2 (en) * | 2006-06-20 | 2010-07-27 | United Parcel Service Of America, Inc. | Systems and methods for providing personalized delivery services |
US7724890B1 (en) | 2005-09-07 | 2010-05-25 | Sap Ag | Focused retrieval of selected data in a call center environment |
JP4785491B2 (en) * | 2005-10-19 | 2011-10-05 | 富士通株式会社 | Supply plan management method and supply plan management program |
US8484554B2 (en) * | 2006-08-31 | 2013-07-09 | Sap Ag | Producing a chart |
US8255870B2 (en) * | 2006-08-31 | 2012-08-28 | Sap Aktiengesellschaft | Application access for support users |
US7676443B2 (en) * | 2006-11-17 | 2010-03-09 | Sap Ag | System and method for processing data elements in retail sales environment |
US7548900B2 (en) * | 2006-11-30 | 2009-06-16 | Sap Ag | Systems and methods for data management |
US7775431B2 (en) * | 2007-01-17 | 2010-08-17 | Metrologic Instruments, Inc. | Method of and apparatus for shipping, tracking and delivering a shipment of packages employing the capture of shipping document images and recognition-processing thereof initiated from the point of shipment pickup and completed while the shipment is being transported to its first scanning point to facilitate early customs clearance processing and shorten the delivery time of packages to point of destination |
US8099337B2 (en) | 2007-06-19 | 2012-01-17 | Sap Ag | Replenishment planning management |
US20090006152A1 (en) * | 2007-06-29 | 2009-01-01 | Caterpillar Inc. | System and method for estimating a new content level in service agreements |
US7730051B2 (en) | 2007-07-23 | 2010-06-01 | Sap Aktiengesellschaft | System and method for embedded expression assignment |
US7809707B2 (en) * | 2007-07-23 | 2010-10-05 | Sap Ag | System and method for identifying element usage in a deep element structure |
US7730052B2 (en) | 2007-07-23 | 2010-06-01 | Sap Aktiengesellschaft | System and method for providing a virtual item context |
US8306838B2 (en) * | 2007-08-30 | 2012-11-06 | Sap Aktiengeselleschaft | System and method for affirmative fulfillment of an order based on same day material availability during operating hours |
JP4801758B2 (en) * | 2009-06-02 | 2011-10-26 | 富士通株式会社 | Electronic equipment and reinforcement parts |
US8429019B1 (en) | 2009-10-29 | 2013-04-23 | Amazon Technologies, Inc. | System and method for scheduled delivery of shipments with multiple shipment carriers |
US20120303538A1 (en) | 2011-05-25 | 2012-11-29 | United Parcel Service Of America, Inc. | Customer controlled management of shipments |
US20120303541A1 (en) | 2011-05-25 | 2012-11-29 | United Parcel Service Of America, Inc. | Customer controlled management of shipments |
JP5523433B2 (en) * | 2011-11-28 | 2014-06-18 | 楽天株式会社 | Information processing apparatus, information processing method, and information processing program |
US9916557B1 (en) | 2012-12-07 | 2018-03-13 | United Parcel Service Of America, Inc. | Systems and methods for item delivery and pick-up using social networks |
US10387824B2 (en) | 2012-12-21 | 2019-08-20 | United Parcel Service Of America, Inc. | Systems and methods for delivery of an item |
US11144872B2 (en) | 2012-12-21 | 2021-10-12 | United Parcel Service Of America, Inc. | Delivery to an unattended location |
CA2900041C (en) | 2013-02-01 | 2020-04-21 | United Parcel Service Of America, Inc. | Systems and methods for parcel delivery to alternate delivery locations |
US10163119B1 (en) | 2013-02-07 | 2018-12-25 | United Parcel Service Of America, Inc. | Systems and methods for synchronized delivery |
US20140279658A1 (en) | 2013-03-12 | 2014-09-18 | United Parcel Service Of America, Inc. | Systems and methods of suggesting attended delivery/pickup locations |
US20150066795A1 (en) | 2013-08-30 | 2015-03-05 | United Parcel Service Of America, Inc. | Systems, methods, and computer program products for providing a customized content exchange platform between two or more parties |
US20150081587A1 (en) | 2013-09-13 | 2015-03-19 | United Parcel Service Of America, Inc. | Customer controlled management of shipments |
US10664787B2 (en) | 2013-10-09 | 2020-05-26 | United Parcel Service Of America, Inc. | Customer controlled management of shipments |
CN106104523A (en) | 2013-10-14 | 2016-11-09 | 统包裹服多美国有限公司 | For for example confirming the system and method for the identity of individual at locker group |
US10002340B2 (en) | 2013-11-20 | 2018-06-19 | United Parcel Service Of America, Inc. | Concepts for electronic door hangers |
US20150178678A1 (en) * | 2013-12-20 | 2015-06-25 | Wal-Mart Stores, Inc. | Product delivery systems and methods |
CN114358693B (en) | 2014-02-16 | 2023-01-10 | 美国联合包裹服务公司 | Determining delivery location and time based on recipient's schedule or location |
US10733563B2 (en) | 2014-03-13 | 2020-08-04 | United Parcel Service Of America, Inc. | Determining alternative delivery destinations |
US9336509B1 (en) | 2014-03-27 | 2016-05-10 | Amazon Technologies, Inc. | Crossdocking transshipments without sortation |
US9911087B1 (en) | 2014-09-18 | 2018-03-06 | Servicenow, Inc. | System and method for efficient travel time and route computation |
CN107077657A (en) | 2014-10-20 | 2017-08-18 | 美国联合包裹服务公司 | Promote the system and method for article buying |
US10410164B2 (en) | 2014-11-14 | 2019-09-10 | United Parcel Service Of America, Inc | Systems and methods for facilitating shipping of parcels |
WO2016077807A2 (en) | 2014-11-14 | 2016-05-19 | United Parcel Service Of America, Inc. | Systems and methods for facilitating shipping of parcels for returning items |
CN107278312B (en) | 2015-01-19 | 2021-02-02 | 清楚目的地有限公司 | System and method for managing and optimizing delivery networks |
US10600022B2 (en) | 2016-08-31 | 2020-03-24 | United Parcel Service Of America, Inc. | Systems and methods for synchronizing delivery of related parcels via a computerized locker bank |
US11068832B1 (en) * | 2018-08-31 | 2021-07-20 | VuTrans Solutions LLC | System and method for identifying freight capacity |
US11501247B1 (en) | 2019-08-13 | 2022-11-15 | Grubhub Holdings Inc. | Optimizing delivery routing using machine learning systems |
CN114996261B (en) * | 2022-08-05 | 2022-10-28 | 深圳市深蓝信息科技开发有限公司 | AIS data-based duplicate removal method and device, terminal equipment and storage medium |
Family Cites Families (15)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5168451A (en) * | 1987-10-21 | 1992-12-01 | Bolger John G | User responsive transit system |
US5310997A (en) | 1992-09-10 | 1994-05-10 | Tandy Corporation | Automated order and delivery system |
US5758313A (en) | 1992-10-16 | 1998-05-26 | Mobile Information Systems, Inc. | Method and apparatus for tracking vehicle location |
US5809479A (en) | 1994-07-21 | 1998-09-15 | Micron Technology, Inc. | On-time delivery, tracking and reporting |
JPH08106493A (en) * | 1994-10-07 | 1996-04-23 | Hitachi Ltd | Method and system for planning delivery |
US5541848A (en) | 1994-12-15 | 1996-07-30 | Atlantic Richfield Company | Genetic method of scheduling the delivery of non-uniform inventory |
US5615121A (en) | 1995-01-31 | 1997-03-25 | U S West Technologies, Inc. | System and method for scheduling service providers to perform customer service requests |
US5692125A (en) | 1995-05-09 | 1997-11-25 | International Business Machines Corporation | System and method for scheduling linked events with fixed and dynamic conditions |
US5922040A (en) | 1995-05-17 | 1999-07-13 | Mobile Information System, Inc. | Method and apparatus for fleet management |
JPH10162065A (en) | 1996-11-28 | 1998-06-19 | Hitachi Ltd | Delivery management system |
US6073110A (en) | 1997-07-22 | 2000-06-06 | Siemens Building Technologies, Inc. | Activity based equipment scheduling method and system |
US5970466A (en) | 1997-10-06 | 1999-10-19 | Impromed, Inc. | Graphical computer system and method for appointment scheduling |
JP2000020386A (en) * | 1998-06-30 | 2000-01-21 | Hitachi Ltd | Information system |
CN1639716A (en) | 2000-03-28 | 2005-07-13 | 邮票商业公司 | Apparatus, systems and methods for online, multi-parcel, multi-carrier, multi-service parcel returns shipping management |
US6240362B1 (en) | 2000-07-10 | 2001-05-29 | Iap Intermodal, Llc | Method to schedule a vehicle in real-time to transport freight and passengers |
-
2001
- 2001-03-16 US US09/811,375 patent/US6701299B2/en not_active Expired - Lifetime
-
2002
- 2002-03-18 MX MXPA03008347A patent/MXPA03008347A/en unknown
- 2002-03-18 WO PCT/US2002/008489 patent/WO2002075500A2/en not_active Application Discontinuation
- 2002-03-18 AU AU2002255829A patent/AU2002255829A1/en not_active Abandoned
Cited By (66)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7587328B2 (en) * | 2000-07-06 | 2009-09-08 | Lng Japan Corporation | Transaction adjusting device |
US20020138293A1 (en) * | 2000-07-06 | 2002-09-26 | Hiroshi Kawahara | Transaction adjusting device |
US8676595B2 (en) | 2001-04-13 | 2014-03-18 | United States Postal Service | Manifest delivery system and method |
US7996333B2 (en) * | 2001-04-13 | 2011-08-09 | United States Postal Service | Manifest delivery system and method |
US20080294474A1 (en) * | 2001-04-13 | 2008-11-27 | United States Postal Services | Manifest delivery system and method |
US20060069601A1 (en) * | 2001-08-10 | 2006-03-30 | United Parcel Service Of America, Inc. | Systems and methods for scheduling reoccurring deliveries and pickups |
US7860738B2 (en) * | 2001-08-10 | 2010-12-28 | United Parcel Service Of America, Inc. | Systems and methods for scheduling reoccurring deliveries and pickups |
US7233907B2 (en) | 2002-08-07 | 2007-06-19 | United Parcel Service Of America, Inc. | Parcel or service delivery with partially scheduled time windows |
US20040030604A1 (en) * | 2002-08-07 | 2004-02-12 | United Parcel Service Of America, Inc. | Parcel or service delivery with partially scheduled time windows |
WO2004015518A3 (en) * | 2002-08-07 | 2004-08-19 | United Parcel Service Inc | Parcel or service delivery with partially scheduled time windows |
US20050049942A1 (en) * | 2002-10-15 | 2005-03-03 | Richard Dominique M. | Method for forecasting consumption and generating optimal delivery schedules for vehicles involved in delivering propane and other consumables to end consumers |
US7676404B2 (en) * | 2002-10-15 | 2010-03-09 | Rmr Associates Llc | Method for forecasting consumption and generating optimal delivery schedules for vehicles involved in delivering propane and other consumables to end consumers |
US7359864B2 (en) * | 2002-11-27 | 2008-04-15 | Carlson Kent R | Method of scheduling appointments |
US20040102983A1 (en) * | 2002-11-27 | 2004-05-27 | Carlson Kent R. | Appointment and load-leveling system |
US7716083B1 (en) * | 2004-02-13 | 2010-05-11 | Fine Food-To-Go, Inc. | Apparatus and method for delivering freshly-prepared fine food |
US8160971B2 (en) * | 2007-10-30 | 2012-04-17 | Electrolux Home Products, Inc. | Method and apparatus for monitoring an order status |
US20090144109A1 (en) * | 2007-10-30 | 2009-06-04 | Electrolux Home Products, Inc. | Method and apparatus for monitoring an order status |
US20100100315A1 (en) * | 2008-09-04 | 2010-04-22 | United Parcel Service Of America, Inc. | Determining Speed Parameters In A Geographic Area |
US8380640B2 (en) | 2008-09-04 | 2013-02-19 | United Parcel Service Of America, Inc. | Driver training systems |
US20100100507A1 (en) * | 2008-09-04 | 2010-04-22 | United Parcel Service Of America, Inc. | Determining Vehicle Visit Costs To A Geographic Area |
US20100094688A1 (en) * | 2008-09-04 | 2010-04-15 | United Parcel Service Of America, Inc. | Driver training systems |
US20110196644A1 (en) * | 2008-09-04 | 2011-08-11 | Davidson Mark J | Determining speed parameters in a geographic area |
US20100094769A1 (en) * | 2008-09-04 | 2010-04-15 | United Parcel Service Of America, Inc. | Vehicle routing and scheduling systems |
US8219312B2 (en) | 2008-09-04 | 2012-07-10 | United Parcel Service Of America, Inc. | Determining speed parameters in a geographic area |
US8719183B2 (en) | 2008-09-04 | 2014-05-06 | United Parcel Service Of America, Inc. | Geofenced based back-up limits |
US8407152B2 (en) | 2008-09-04 | 2013-03-26 | United Parcel Service Of America, Inc. | Commercial and residential backups |
US8423287B2 (en) | 2008-09-04 | 2013-04-16 | United Parcel Service Of America, Inc. | Determining speed parameters in a geographic area |
US9128809B2 (en) | 2008-09-04 | 2015-09-08 | United Parcel Service Of America, Inc. | Determining speed parameters in a geographic area |
US8649969B2 (en) | 2008-09-04 | 2014-02-11 | United Parcel Service Of America, Inc. | Determining speed parameters in a geographic area |
WO2010027469A1 (en) * | 2008-09-04 | 2010-03-11 | United Parcel Service Of America, Inc. | Determining vehicle visit costs to a geographic area |
US10453004B2 (en) | 2008-09-04 | 2019-10-22 | United Parcel Service Of America, Inc. | Vehicle routing and scheduling systems |
US10304028B2 (en) | 2008-12-19 | 2019-05-28 | United Parcel Service Of America, Inc. | Trailer utilization systems, methods, computer programs embodied on computer-readable media, and apparatuses |
US20100235210A1 (en) * | 2009-03-11 | 2010-09-16 | United Parcel Service Of America, Inc. | Scheduled delivery service systems, apparatuses, methods, and computer programs embodied on computer-readable media |
US20130138330A1 (en) * | 2011-11-25 | 2013-05-30 | Jiefeng Xu | System and method to optimize mass transport vehicle routing based on ton-mile cost information |
US10346784B1 (en) | 2012-07-27 | 2019-07-09 | Google Llc | Near-term delivery system performance simulation |
US20140095350A1 (en) * | 2012-10-02 | 2014-04-03 | Wal-Mart Stores, Inc. | Method And System To Facilitate Same Day Delivery Of Items To A Customer |
US10127517B2 (en) * | 2012-10-02 | 2018-11-13 | Walmart Apollo, Llc | Method and system to facilitate same day delivery of items to a customer |
US20140214715A1 (en) * | 2013-01-30 | 2014-07-31 | Command Alkon Incorporated | Scheduling system and method for distribution of perishable loads of pre-mixed concrete to multiple sites |
US11164141B1 (en) | 2013-02-07 | 2021-11-02 | United Parcel Service Of America, Inc. | Systems and methods for synchronized delivery |
US10387822B1 (en) | 2013-02-07 | 2019-08-20 | United Parcel Service Of America, Inc. | Systems and methods for synchronized delivery |
US11367040B1 (en) * | 2013-02-07 | 2022-06-21 | United Parcel Service Of America, Inc. | Systems and methods for synchronized delivery |
US10706384B1 (en) | 2013-02-07 | 2020-07-07 | United Parcel Service Of America, Inc. | Systems and methods for synchronized delivery |
US10796270B1 (en) | 2013-02-07 | 2020-10-06 | United Parcel Service Of America, Inc. | Systems and methods for synchronized delivery |
US11816626B2 (en) | 2013-02-07 | 2023-11-14 | United Parcel Service Of America, Inc. | Systems and methods for synchronized delivery |
US20150100365A1 (en) * | 2013-10-07 | 2015-04-09 | Elemica, Inc. | Constraint optimization method and system for supply chain management |
US20160148152A1 (en) * | 2014-04-24 | 2016-05-26 | Toshiba Tec Kabushiki Kaisha | Shopping supporting system |
US11941575B2 (en) | 2015-09-21 | 2024-03-26 | United Parcel Service Of America, Inc. | Systems and methods for reserving space in carrier vehicles to provide on demand delivery services |
US11144870B2 (en) * | 2015-09-21 | 2021-10-12 | United Parcel Service Of America, Inc. | Systems and methods for reserving space in carrier vehicles to provide on demand delivery services |
US20230169415A1 (en) * | 2018-01-19 | 2023-06-01 | Walmart Apollo, Llc | Systems and methods for combinatorial resource optimization |
US11475395B2 (en) | 2018-01-19 | 2022-10-18 | Walmart Apollo, Llc | Systems and methods for combinatorial resource optimization |
US11922343B2 (en) * | 2018-01-19 | 2024-03-05 | Walmart Apollo, Llc | Systems and methods for combinatorial resource optimization |
US11455581B2 (en) * | 2018-06-11 | 2022-09-27 | Palantir Technologies Inc. | Methods and systems for providing a user interface for managing parts production and delivery statuses |
US20200143319A1 (en) * | 2018-11-01 | 2020-05-07 | Walmart Apollo, Llc | Systems and methods for determining delivery time and route assignments |
US11615368B2 (en) * | 2018-11-01 | 2023-03-28 | Walmart Apollo, Llc | Systems and methods for determining delivery time and route assignments |
US11810045B2 (en) * | 2019-03-18 | 2023-11-07 | Coupang, Corp. | Systems and methods for automatic package reordering using delivery wave systems |
US20210406811A1 (en) * | 2019-03-18 | 2021-12-30 | Coupang Corp. | Systems and methods for automatic package reordering using delivery wave systems |
US10664793B1 (en) * | 2019-03-18 | 2020-05-26 | Coupang Corp. | Systems and methods for automatic package tracking and prioritized reordering |
US11151507B2 (en) * | 2019-03-18 | 2021-10-19 | Coupang Corp. | Systems and methods for automatic package reordering using delivery wave systems |
TWI795676B (en) * | 2019-10-25 | 2023-03-11 | 南韓商韓領有限公司 | Computer implemented system and method for automated reshipment scheduling |
AU2020264260A1 (en) * | 2019-10-25 | 2021-05-13 | Coupang Corp. | Systems and methods for automatic package reordering using delivery wave systems |
US11526831B1 (en) * | 2019-12-13 | 2022-12-13 | Amazon Technologies, Inc. | Enhanced delivery option interfaces |
US11257023B1 (en) * | 2019-12-13 | 2022-02-22 | Amazon Technologies, Inc. | Enhanced delivery option interfaces |
US20230111072A1 (en) * | 2020-06-30 | 2023-04-13 | Asahi Kasei Kabushiki Kaisha | Device, method, and non-transitory computer readable medium |
US11948185B2 (en) | 2020-09-25 | 2024-04-02 | Walmart Apollo, Llc | Automatically merging pickup and delivery time slots from nearby stores |
US11928641B2 (en) * | 2020-09-30 | 2024-03-12 | International Business Machines Corporation | Self adaptive delivery based on simulated disruption |
US20220351107A1 (en) * | 2021-04-29 | 2022-11-03 | Shopify Inc. | Automated request fulfilment processing |
Also Published As
Publication number | Publication date |
---|---|
WO2002075500A3 (en) | 2004-02-12 |
AU2002255829A1 (en) | 2002-10-03 |
US6701299B2 (en) | 2004-03-02 |
WO2002075500A2 (en) | 2002-09-26 |
MXPA03008347A (en) | 2003-12-11 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US6701299B2 (en) | Real-time delivery feasibility analysis systems and methods | |
US8195494B2 (en) | Method and system of delivering items using overlapping delivery windows | |
US6985871B2 (en) | Systems and methods for scheduling reoccurring deliveries and pickups | |
KR101713155B1 (en) | System and method of dealing rental car via price adjustment | |
US7233907B2 (en) | Parcel or service delivery with partially scheduled time windows | |
US7801807B2 (en) | Computer implemented automated credit application analysis and decision routing system | |
KR100814895B1 (en) | Computer-implemented system and method for booking airline travel itineraries | |
AU720436B2 (en) | Automated system for identifying alternate low-cost travel arrangements | |
CA2455119C (en) | System and method for managing inventory | |
US20070192229A1 (en) | Transaction management system and method | |
US20040138992A1 (en) | Computer implemented automated credit application analysis and decision routing system | |
US20010047293A1 (en) | System, method and article of manufacture to optimize inventory and inventory investment utilization in a collaborative context | |
US20090024423A1 (en) | System and Method for Automated Vehicle Tracking | |
CA2455302A1 (en) | System and method for managing reservation requests for one or more inventory items | |
Torres et al. | Vehicle routing with stochastic supply of crowd vehicles and time windows | |
US7457766B1 (en) | Methods and systems for determining daily weighting factors for use in forecasting daily product sales | |
US7533037B1 (en) | Methods and systems for forecasting daily product sales | |
US20200294172A1 (en) | Adaptive resource allocation | |
JP6809718B2 (en) | Information processing device | |
US20050144030A1 (en) | System and method for territory based commission attribution | |
Blankenvoorde | Optimization of the order-to-cash process. | |
JP2002207860A (en) | Method for supporting sales action based on information | |
US20080126142A1 (en) | Promotional in-store demonstration coordination system and method | |
US20030125979A1 (en) | Method for flexible definition and retrieval of behavioral data applicable to multiple participating parties | |
Obermair | Logistics challenges in omni-channel grocery retailing |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: UNITED PARCEL SERVICE OF AMERICA, INC., GEORGIA Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:KRAISSER, CLIFTON BRIAN;CUCCHIARA, VINCENT;SIMON, STEPHEN PATRICK;AND OTHERS;REEL/FRAME:012097/0009 Effective date: 20010716 |
|
STCF | Information on status: patent grant |
Free format text: PATENTED CASE |
|
FPAY | Fee payment |
Year of fee payment: 4 |
|
REMI | Maintenance fee reminder mailed | ||
AS | Assignment |
Owner name: ROADNET TECHNOLOGIES, INC., MARYLAND Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:UNITED PARCEL SERVICE OF AMERICA, INC;REEL/FRAME:025816/0361 Effective date: 20101231 |
|
FPAY | Fee payment |
Year of fee payment: 8 |
|
AS | Assignment |
Owner name: GENERAL ELECTRIC CAPITAL CORPORATION, AS AGENT, IL Free format text: SECURITY AGREEMENT;ASSIGNOR:ROADNET TECHNOLOGIES, INC.;REEL/FRAME:030471/0131 Effective date: 20130522 |
|
AS | Assignment |
Owner name: ROADNET TECHNOLOGIES, INC., MARYLAND Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:GENERAL ELECTRIC CAPITAL CORPORATION;REEL/FRAME:031889/0779 Effective date: 20131219 |
|
FPAY | Fee payment |
Year of fee payment: 12 |
|
AS | Assignment |
Owner name: ROYAL BANK OF CANADA, AS COLLATERAL AGENT, CANADA Free format text: SECURITY INTEREST;ASSIGNORS:ROADNET HOLDINGS CORPORATION;ROADNET TECHNOLOGIES, INC.;REEL/FRAME:037049/0798 Effective date: 20131219 Owner name: ROYAL BANK OF CANADA, AS COLLATERAL AGENT, CANADA Free format text: SECURITY INTEREST;ASSIGNORS:ROADNET HOLDINGS CORPORATION;ROADNET TECHNOLOGIES, INC.;REEL/FRAME:037049/0626 Effective date: 20131219 |
|
AS | Assignment |
Owner name: BARCLAYS BANK PLC, NEW YORK Free format text: SECURITY INTEREST;ASSIGNOR:ROADNET TECHNOLOGIES, INC.;REEL/FRAME:045352/0742 Effective date: 20180323 Owner name: ROADNET HOLDINGS CORPORATION, TEXAS Free format text: RELEASE OF FIRST LIEN SECURITY AGREEMENT OF REEL/FRAME 037049/0626;ASSIGNOR:ROYAL BANK OF CANADA;REEL/FRAME:045727/0417 Effective date: 20180323 Owner name: ROADNET TECHNOLOGIES INC., TEXAS Free format text: RELEASE OF FIRST LIEN SECURITY AGREEMENT OF REEL/FRAME 037049/0626;ASSIGNOR:ROYAL BANK OF CANADA;REEL/FRAME:045727/0417 Effective date: 20180323 Owner name: ROADNET TECHNOLOGIES INC., TEXAS Free format text: RELEASE OF SECOND LIEN SECURITY AGREEMENT OF REEL/FRAME 037049/0626;ASSIGNOR:ROYAL BANK OF CANADA;REEL/FRAME:045921/0001 Effective date: 20180323 Owner name: ROADNET HOLDINGS CORPORATION, TEXAS Free format text: RELEASE OF SECOND LIEN SECURITY AGREEMENT OF REEL/FRAME 037049/0626;ASSIGNOR:ROYAL BANK OF CANADA;REEL/FRAME:045921/0001 Effective date: 20180323 |
|
AS | Assignment |
Owner name: CREDIT SUISSE AG, CAYMAN ISLANDS BRANCH, NEW YORK Free format text: SECOND LIEN PATENT SECURITY AGREEMENT;ASSIGNOR:ROADNET TECHNOLOGIES, INC.;REEL/FRAME:054252/0542 Effective date: 20201001 |
|
AS | Assignment |
Owner name: ROADNET TECHNOLOGIES, INC., TEXAS Free format text: SECURITY INTEREST RELEASE (REEL/FRAME: 045352/0742);ASSIGNOR:BARCLAYS BANK PLC, AS GRANTEE;REEL/FRAME:056516/0682 Effective date: 20210604 Owner name: ROADNET TECHNOLOGIES, INC., TEXAS Free format text: SECURITY INTEREST RELEASE (REEL/FRAME: 054252/0542);ASSIGNOR:CREDIT SUISSE AG, CAYMAN ISLANDS BRANCH, AS GRANTEE;REEL/FRAME:056518/0765 Effective date: 20210604 |
|
AS | Assignment |
Owner name: ALTER DOMUS (US) LLC, AS COLLATERAL AGENT, ILLINOIS Free format text: SECOND LIEN PATENT SECURITY AGREEMENT;ASSIGNORS:OMNITRACS, LLC;ROADNET TECHNOLOGIES, INC.;SMARTDRIVE SYSTEMS, INC.;AND OTHERS;REEL/FRAME:056598/0059 Effective date: 20210604 Owner name: GOLDMAN SACHS LENDING PARTNERS LLC, AS COLLATERAL AGENT, NEW YORK Free format text: FIRST LIEN PATENT SECURITY AGREEMENT;ASSIGNORS:OMNITRACS, LLC;ROADNET TECHNOLOGIES, INC.;SMARTDRIVE SYSTEMS, INC.;AND OTHERS;REEL/FRAME:056601/0630 Effective date: 20210604 |
|
AS | Assignment |
Owner name: ALTER DOMUS (US) LLC, AS COLLATERAL AGENT, ILLINOIS Free format text: CORRECTIVE ASSIGNMENT TO CORRECT THE INCORRECT PATENT NUMBER D856640 PREVIOUSLY RECORDED ON REEL 056598 FRAME 0059. ASSIGNOR(S) HEREBY CONFIRMS THE SECOND LIEN PATENT SECURITY AGREEMENT;ASSIGNORS:OMNITRACS, LLC;ROADNET TECHNOLOGIES, INC.;SMARTDRIVE SYSTEMS, INC.;AND OTHERS;REEL/FRAME:058175/0775 Effective date: 20210604 Owner name: GOLDMAN SACHS LENDING PARTNERS LLC, AS COLLATERAL AGENT, NEW YORK Free format text: CORRECTIVE ASSIGNMENT TO CORRECT THE INCORRECT PATENT NUMBER D856640 PREVIOUSLY RECORDED ON REEL 056601 FRAME 0630. ASSIGNOR(S) HEREBY CONFIRMS THE FIRST LIEN PATENT SECURITY AGREEMENT;ASSIGNORS:OMNITRACS, LLC;ROADNET TECHNOLOGIES, INC.;SMARTDRIVE SYSTEMS, INC.;AND OTHERS;REEL/FRAME:058174/0907 Effective date: 20210604 |