WO2016077677A1 - Business fleet scheduling and transport logistics - Google Patents

Abstract

Methods and systems for business fleet schedule and transport logistics are presented. The invention includes processes for collecting and aggregating employee driver, product, and client availability data; using public and commercial application programming interfaces (API's) to collect route information between each node, such as traffic, weather, distance, speed limits; using collected route information to best determine each segment between nodes of each employee driver's route, based on the employee driver's skills and availability; and scheduling and disseminating the routes to the employee driver, client, and product (or product manager) in a timely manner.

Description

BUSINESS FLEET SCHEDULING AND TRANSPORT LOGISTICS

CROSS-REFERENCE TO RELATED APPLICATIONS

[001] The present application claims the benefit of U.S. Provisional Application Ser. No.

62/080,172 filed on November 14, 2014, specification of which is herein incorporated by reference for completeness of disclosure.

FIELD OF THE INVENTION

[002] This invention relates generally to the field of computer networked data dissemination and logistical support.

BACKGROUND

[003] Businesses that operate a large fleet of mobile employee drivers to either 1) pick up products from multiple sources and deliver them to a single product consumer or 2) pick up products from a single source and deliver them to multiple product consumers typically need coordinate the entering and aggregation of employee driver schedules, the analysis of the surrounding geographic region of each employee driver - including but not limited to highways, surface streets, and their traffic conditions - and disseminate the employee driver schedules and route information in order to produce cost-efficient routing logistics for the entire fleet.

BRIEF SUMMARY

[004] The present inventions relates to a computer application capable of collecting and aggregating employee driver, product, and client availability data; using public and commercial application programming interfaces (API's) to collect route information between each node, such as traffic, weather, distance, speed limits; using collected route information to best determine each segment between nodes of each employee driver's route; and disseminating the routes to each employee driver, client, and product (or product manager) in a timely manner.

[005] In one or more embodiments, the system obtains delivery fleet's availabilities, client availabilities, and product availabilities and uses the aggregated information for scheduling delivery tasks.

[006] In one or more embodiments, a delivery fleet's availabilities may include data, e.g.

availability hours; biographic information of each employee driver; geolocation information of each employee driver; resources available to each employee driver (e.g. vehicle); skill; etc. Each delivery fleet employee driver may enter availability dates and other parameters using a graphical user interface (GUI) on any kind of networked device such as a desktop computer, tablet, phablet, wearable, smartphone, computer system in the delivery vehicle; etc.

[007] In one or more embodiments, a client's (or consumer) availabilities may include data such as available days for delivery; delivery restrictions, such as the maximum number of deliveries per day or per week; time of day deliveries can be made, maximum distance each delivery can be from a given point, etc. The client may enter availability dates and other parameters using a graphical user interface (GUI) on any kind of networked device such as a desktop computer, tablet, phablet, wearable, smartphone, etc.

[008] In one or more embodiments, product availabilities, i.e. all available dates for the product pickup, may be computed based on the delivery fleet's availabilities; consumer/client availabilities; product geolocation; and other attributes. The product availabilities in some embodiments depends on computation of routing for delivery vehicles that fits within the restrictions set by the delivery fleet's availabilities and consumer/client availabilities. The product availabilities may be displayed to a product manager for selection of a delivery date from the list of available dates, or may be provided to an automated system for automatic selection of a delivery date.

[009] In one or more embodiments, utilizing a computer application, analysis of data may be used to determine most efficient routes for delivery vehicles to travel. Certain examples include routing that may take into consideration multiple product sources and also routing that may take into consideration the product consumer. Example routing determinations may also be applied to the reverse model, where there is generally one source of product, for example in a warehouse, and multiple product consumers.

[0010] In one or more embodiments, factors that may go into routing decisions may include but are not limited to, scheduling availability for the vehicles in the fleet, skill level of the fleet employee drivers, number and location of products, availability of products, number and location of product consumers, time of day, day of the week, day of year, road conditions, traffic, weather, speed limits, and payload for the delivery vehicles.

[0011] Once the fleet's routes have been determined, the drive information may be disseminated to the appropriate employee drivers in a timely manner, e.g. on a periodic basis, or as conditions change. The client and the source of the product (or product manager) may also receive information about the routes.

[0012] Thus, the system disclosed here is able to accumulate various schedules from various fleet delivery employee drivers, aggregate and save the data and use it to coordinate proper and prompt delivery of any of various products or services over any geographical area. The system can be used to adjust delivery based on updates from the delivery fleet and/or customers as well as adjust based on outside influences such as traffic and weather.

[0013] Systems and methods here include ways to schedule including using a computer server in communication with a data storage and a network for receiving information regarding driver availability times and scheduled geolocations during the driver availability times, over the network, receiving information regarding a client needing service including the client geolocation and client availability times to be serviced, over the network, determining a route and a corresponding route distance for a plurality of possible routes from the driver scheduled geolocations and the client needing service geolocation, during the driver availability times, determining a duration to travel each route distance, including driving factors received over the network, identifying a list of possible delivery times when the driver can travel from one of the scheduled geolocations to the client geolocation using the determined routes and determined duration to travel each route, and compiling the possible delivery times that match the client availability times.

[0014] In certain embodiments, the driving factors include at least one of time of day, traffic, construction, and weather. And certain embodiments further comprise sending to a wireless user device of the driver over the network, the client geolocation, the compiled list of possible delivery times that match the client availability times, and the determined route to the client geolocation; and receiving an image from the wireless user device over the network, of a bar code obtained at the client. In certain embodiments, the driving factors includes consideration of at least one of, biographic information of the driver, skill level of the driver, and resources available to the driver.

[0015] In some examples, by the computer server, receiving information regarding a product availability and geolocation of the product. And in some examples, the delivery restrictions include one or more of the maximum number of deliveries per day or per week, time of day deliveries can be made, and maximum distance each delivery can be from a given point. [0016] In some examples, availabilities include hours each driver is available for driving. Some examples include receiving updated geolocation of the driver, adjusting the plurality of routes and duration to travel each route distance according to the updated driver geolocation. And some examples have by the server, receiving updated availability times of the driver, adjusting the list of possible delivery times, based on the updated availability times of the driver.

BRIEF DESCRIPTION OF THE DRAWINGS

[0017] The above and other aspects, features and advantages of the invention will be more apparent from the following more particular description thereof, presented in conjunction with the following drawings wherein:

[0018] FIG. 1 is an illustration of an example system architecture in accordance with one or more embodiments of the present invention.

[0019] FIG. 2A shows an example graphical user interface for a mobile application that receives employee driver availability and transmits that information to a computer database in accordance with one or more embodiments of the present invention.

[0020] FIG. 2B shows another graphical user interface example for a mobile application that receives employee driver availability and transmits that information to a computer database in accordance with one or more embodiments of the present invention.

[0021] FIG. 3 shows a graphical user interface example for an application that receives client availability and transmits that information to a computer database in accordance with one or more embodiments of the present invention.

[0022] FIG. 4 shows another graphical user interface example for an application that receives client availability and transmits that information to a computer database in accordance with one or more embodiments of the present invention.

[0023] FIG. 5 shows a graphical user interface example for an application that receives product availability and other information, and transmits that information to a computer database in accordance with one or more embodiments of the present invention.

[0024] FIG. 6 shows another graphical user interface example for an application that receives product availability and other route information, and transmits that information to a computer database in accordance with one or more embodiments of the present invention.

[0025] FIG. 7A schematically shows an example system for collecting employee driver, client, and product availabilities, analyzing route conditions to determine the best route for each employee driver's product pickup route, and storing those routes in a database for later dissemination in accordance with one or more embodiments of the present invention.

[0026] FIG. 7B schematically shows a continuation of 7 A example system for collecting employee driver, client, and product availabilities, analyzing route conditions to determine the best route for each employee driver's product pickup route, and storing those routes in a database for later dissemination in accordance with one or more embodiments of the present invention.

[0027] FIG. 7C schematically shows a continuation of 7A example system for collecting employee driver, client, and product availabilities, analyzing route conditions to determine the best route for each employee driver's product pickup route, and storing those routes in a database for later dissemination in accordance with one or more embodiments of the present invention.

[0028] FIG. 7D schematically shows a continuation of 7A example system for collecting employee driver, client, and product availabilities, analyzing route conditions to determine the best route for each employee driver's product pickup route, and storing those routes in a database for later dissemination in accordance with one or more embodiments of the present invention.

[0029] FIG. 8 is an example flow diagram for collecting employee driver, client, and product availability, analyzing route conditions to determine the best route for each employee driver, and storing those routes in a database for later dissemination in accordance with one or more embodiments of the present invention.

[0030] FIG. 9 shows an example graphical user interface of the master scheduler backend, which shows all employee driver availabilities, client availabilities, and pickup routes currently scheduled. Additionally, it may be used as another way of scheduling product pickup routes for products that are already located in the database in accordance with one or more embodiments of the present invention.

[0031] FIG. 10 shows a detailed view of part of FIG. 9, more specifically, the calendar graphical user interface that displays how many employee drivers have available schedules on a particular day in accordance with one or more embodiments of the present invention.

[0032] FIG. 11 shows a detailed view of part of FIG. 9, more specifically, the map and availability graphical user interface that displays where on the globe each fleet employee driver is located, as well each employee driver's availability and any currently scheduled product pickups in accordance with one or more embodiments of the present invention.

[0033] FIG. 12 shows an example graphical user interface that appears when certain elements are clicked on the master scheduler. The modal displays more detailed information about an employee driver's currently scheduled product pickup, such as the address, time of appointment, travel route, and trip duration in accordance with one or more embodiments of the present invention.

[0034] FIG. 13 shows another example graphical user interface that appears when certain elements are clicked on the master scheduler. The modal displays more detailed information about an employee driver's currently available time block and allows a user to select a product from the database and manually add it to an employee driver's deliveries in accordance with one or more embodiments of the present invention.

[0035] FIG. 14A shows an example graphical user interface that disseminates the employee driver schedule and product pickup route information, as well as other information about the route or pickup, which can be displayed on a tablet, mobile phone, and laptop while in the field. Additionally, the GUI may be used to update the master scheduler with information about status of the product pickup, traffic information, GPS location, etc. in accordance with one or more embodiments of the present invention.

[0036] FIG. 14B shows a continuation of FIG 14A graphical user interface that disseminates the employee driver schedule and product pickup route information, as well as other information about the route or pickup, which can be displayed on a tablet, mobile phone, and laptop while in the field. Additionally, the GUI may be used to update the master scheduler with information about status of the product pickup, traffic information, GPS location, etc. in accordance with one or more embodiments of the present invention.

[0037] FIG. 15 shows an example graphical user interface that disseminates the delivery schedule to the client (or consumer of the product), as well as other information about the product or delivery schedule in accordance with one or more embodiments of the present invention.

[0038] FIG. 16 shows an example email message that disseminates the product pickup time to the product, or donor (biological product) in this embodiment, as well as other information, in accordance with one or more embodiments of the present invention.

DETAILED DESCRIPTION

[0039] The present invention comprising systems and methods for business fleet scheduling and transport logistics will now be described. In the following exemplary description numerous specific details are set forth in order to provide a more thorough understanding of embodiments of the invention. It will be apparent, however, to an artisan of ordinary skill that the present invention may be practiced without incorporating all aspects of the specific details described herein. Furthermore, although steps or processes are set forth in an exemplary order to provide an understanding of one or more systems and methods, the exemplary order is not meant to be limiting. One of ordinary skill in the art would recognize that the steps or processes may be performed in a different order, and that one or more steps or processes may be performed simultaneously or in multiple process flows without departing from the spirit or the scope of the invention. In other instances, well-known data structures, timing protocols, software operations, procedures, components, specific features, quantities, or measurements well known to those of ordinary skill in the art have not been described in detail so as not to obscure the invention. It should be noted that although examples of the invention are set forth herein, the claims, and the full scope of any equivalents, are what define the metes and bounds of the invention.

[0040] For a better understanding of the disclosed embodiment, its operating advantages, and the specified object attained by its uses, reference should be made to the accompanying drawings and descriptive matter in which there are illustrated exemplary disclosed embodiments. The disclosed embodiments are not intended to be limited to the specific forms set forth herein. It is understood that various omissions and substitutions of equivalents are contemplated as circumstances may suggest or render expedient, but these are intended to cover the application or implementation.

[0041] Overview

[0042] Embodiments here relate generally to the networked dissemination of accumulated business fleet availability and geolocation data, product consumer availability and geolocation data, and/or product source availability and geolocation data in a computer database.

Alternatively or additionally, certain embodiments employ a computer application and/or computer instructions executed by a processor and/or software.

[0043] Alternatively or additionally, certain embodiments utilize a computer application, analysis of data may be used to determine most efficient routes for delivery vehicles to travel. Alternatively or additionally, certain examples include routing that may take into consideration multiple product sources and also routing that may take into consideration the product consumer. Example routing determinations may also be applied to the reverse model, where there is generally one source of product, for example in a warehouse, and multiple product consumers. [0044] Alternatively or additionally, example factors that may go into routing decisions may include but are not limited to, scheduling availability for the vehicles in the fleet, skill level of the fleet employee driver, number and location of products, availability of products, number and location of product consumers, resource availability for the fleet and driving factors such as time of day, day of the week, day of year, road conditions, traffic, weather, speed limits, and payload for the delivery vehicles.

[0045] Once the fleet's routes have been determined, alternatively or additionally, the drive information may be disseminated to each employee driver deliverer in a timely manner on a periodic basis such as daily, or more frequently as conditions change. The client and the source of the product (or product manager) may also receive information about the routes.

[0046] Example Fleet Network

[0047] FIG. 1 is an illustrative example of a computer network which may be used to support certain embodiments described herein. In the illustration, any kind of mobile device 108 may be used by an employee driver of a delivery fleet, e.g. 102, 102a, 102b, to communicate either by short range radio such as 802.11 Wi-Fi 111 and/or by cellular network (3g/4g/4g/EDGE) 110 with a network tower 112 to the central master scheduler 116, which is coupled to a data network 118, e.g. the internet, by interface 120. Example mobile devices may be, but are not limited to smartphones; tablet computers; phablets; laptops; wearables such as glasses, watches, and bracelets; and computer systems and displays in the automotive vehicles themselves.

[0048] Through such mobile devices, 108, any of various users can interact with the master scheduler system 116 as described herein and inform and update the system with available schedule information in order for the master scheduler administrator to have information regarding the example delivery fleet. With that information, the master scheduler can plan delivery assignments to the available fleet vehicles, update delivery assignments, change delivery assignments, and add and release number of delivery vehicles, etc.

[0049] Such analysis and assignments may be completed on any of various systems described here, for example through any of various back end servers 119 and associated data storage, either local data storage 121 and/or networked or cloud storage 117, such as Amazon RDS. Through the network, these back end servers 119 can calculate updated route information of the one or more delivery vehicles, e.g. 102, 102a, 102b, and also track the geographic location of each vehicle as it moves. The back end servers 119 can also push updated delivery assignments and details to one or more vehicles, e.g. 102, 102a, 102b, as needed. [0050] Further, mobile devices 108 may be used by the employee drivers to communicate with the back end servers 119 to view the master schedule or route information, update the master schedule with new availabilities 109, adjust and assign existing or new product pickups to the delivery employee drivers, etc.

[0051] In practice, one or more clients/customers 122 may be the target of delivery, for example. In such an example, a fleet of delivery vehicles, e.g. 102, 102a, 102b, may be used to deliver goods 106. Such delivery vehicles may include location systems such as global positioning systems GPS which relay their location information 104 back to the master scheduler system 116 periodically. By doing so, the master system administrator/scheduler 116 can be aware of the location of the members of the fleet, e.g. 102, 102a, 102b, and also help coordinate deliveries 106 that may be extra, late, missing, etc. The master scheduler can also push updated delivery assignments, route information and traffic information to the delivery employee drivers 102, 102a, 102b for display on a graphical user interface on their mobile devices. For example, if one employee driver vehicle, e.g. 102a, is stuck in traffic but another employee driver vehicle, e.g. 102b, is finished early with a delivery or pick up, the master scheduler can see that information in real time and push 102a's pick up to the free vehicle 102b.

[0052] Alternatively or additionally, the client 122, upon receipt of the goods or upon pickup of the goods, may update the system that the goods are delivered and/or picked up through various ways such as a mobile scanning system 124, such as a bar code, icon, quick response code or other type scanner. In certain example embodiments, a smart phone camera or other mobile device camera could also be used to capture an image of a bar code and update the system accordingly. Additionally, or alternatively, the client 122 may update the master schedule 116 with new availabilities or delivery restrictions 125. Additionally or alternatively, a digital signature may be used to signify receipt or pickup. Such a digital signature may be captured on a smartphone or tablet or any computing device and sent to the master schedule 116 for inclusion into a file for the client or product, and/or could be used to signify that the delivery and/or drop off was successful.

[0053] The product (or product manager) 128, upon pickup of the sample by the employee driver, may update the system that the product(s) have been picked up through various ways such as the mobile user devices 128 and/or a scanning system 131, such as a bar code scanner. In certain example embodiments, an application running on a smart phone could be used with the smart phone camera or other mobile device camera to capture an image of a bar code and update the system accordingly. Additionally, the product (or product manager) 128 may update the master schedule 116 with new pickup times or delivery restrictions 131.

[0054] Alternatively or additionally, when the client 122, product (or product manager) 128, or employee driver 108 is communicating data with the master scheduler, an application programming interface may be used to convert the data into a format recognizable by the master scheduler local database 121, the master scheduler server 119, or cloud database 117. Although similar in design, each may be unique. One API 126 is utilized by all clients; one API 132 by all products (or product manager); and one API 114 by all employee drivers.

[0055] It should be noted that the systems and method examples described here are not limited to delivery and pickup of certain products or things. Additionally, the scheduling activities, coordination, and analysis is not limited either. In certain example embodiments, the scheduling could be for a person driving a delivery vehicle to transport a physical item from place to place. Examples of such may include a truck driver's scheduling to deliver groceries at certain times to a consumer or store or warehouse. It could be the scheduling for a driver of phlebotomy samples from a donor to a storage facility or laboratory. It could be scheduling for a driver of medical devices to consumer's places of residence. It could be scheduling to conduct a car service, such as a taxi or ride share system. It could be scheduling to deliver goods such as same day internet shopping and shipping from a store or warehouse to the consumer's place of residence. Any scheduling of a person's time and the route between his or her deliveries and pickups could be determined using the systems and methods disclosed here.

[0056] It should also be noted that the term delivery vehicle is not intended to be limiting. Any of various vehicles including trucks, cars, vans, tractor trailers, airplanes, ships, bicycles, scooters, and/or motorcycles could be used. Additionally, in certain example embodiments, human movement without a vehicle may be used as well.

[0057] Example Scheduling GUIs

[0058] FIG. 2A, FIG. 2B, FIG. 3, FIG. 4, FIG. 5, and FIG. 6 depict example computer application graphical user interfaces (GUI) capable of interfacing with a user of a networked computer device. The GUIs may be presented from applications running locally on the user device, or could be browser interfaces to back end systems such as the master scheduler as described herein. The system can then allow collecting and aggregating employee driver, product, and client availabilities and transmitting that data to a storage system such as a cloud database. More specifically, FIG. 2A and FIG. 2B depict example embodiments of a computer application GUI that relates to the collection of employee driver availabilities.

[0059] FIG. 3 and FIG. 4 depict example embodiments of a computer application GUI that relate to the collection of client availabilities.

[0060] FIG. 5 and FIG. 6 depict example embodiments of a computer application GUI that relate to the collection of product availability dates.

[0061] Employee driver Availability Examples

[0062] In the example screenshot of FIG. 2A, a company employee driver can utilize an electronic communication device, e.g. a wireless smart device, to access the back end system. Once logged in, the system can populate an application presenting a GUI on the wireless user device with input buttons or input fields for an employee driver to enter his or her availabilities.

[0063] In FIG. 2A, the employee driver could set availability blocks of time by the application and the system. The employee driver could scroll through a calendar using a next week 202 and previous week 207 buttons to find the week they are looking to populate with availability information. The example in FIG. 2A of showing a one week block is not intended to be limiting. Any segment of time could be shown in the screen to allow the employee driver to fill in availability times. A week, a month, part of a week, a weekend, a two week span, or any time could be used.

[0064] Alternatively or additionally, once the employee driver finds the display of the dates they wish to populate, the particular date 205 could be located and the plus symbol button 204 could be selected. Upon selecting the plus symbol button 204 for a particular date, a time menu 206 could be displayed, just for that date. These time menus 206 could allow for the employee driver to select a start and end time that they are available. Then, once selected, the employee driver could select the Add button 203 to cause the device to upload the time entry to the system. The smartphone could then upload that information to the system to update the master calendar system.

[0065] In the example of FIG. 2A, only one block of time is entered to be available. In certain example embodiments, multiple blocks of time could be entered, each with its own start and end dates. In certain example embodiments, the start and end dates could stretch over multiple days, and not be limited to one particular calendar date. Any arrangement of blocks of time could be indicated in such a format as shown in FIG. 2A or other example embodiments. [0066] FIG. 2B shows an example screenshot of the system running on a smartphone indicating an Overview of the availability that has been entered into the system. Thus, after the employee driver adds an availability block to a particular day, the user can preview that day's availability blocks by clicking on its respective date, 210. Additionally, the user can click a button, e.g. 212, to remove an availability block from the system. As discussed above, multiple availabilities can be chosen/selected for a particular day. In certain example embodiments, the availability may be sent to a recipient using an icon, e.g. 214.

[0067] The example embodiment GUI may be arranged in a way that the user can view and set a single working week's availabilities (Monday-Friday) at once, where movement between past and future weeks is facilitated by back 207 and forward 202 buttons from FIG. 2A.

[0068] Client Availability Examples

[0069] In FIG. 3, an example diagram is shown of a calendar GUI. In this illustration, a client who is to receive a delivery or needs a pickup, can enter his or her availabilities to a calendar system by a mobile device. A client can also submit its geolocation as well. Then the master system may be updated with this particular client's availability and location. In such a way, a user of the master system could view any and all of the clients' availabilities, see where holes in the calendar are for delivery units.

[0070] Alternatively or additionally, in the example of FIG. 3, the client is able to view and manipulate an interactive calendar in order to update the system with availability. Shown in the example, across the top of the page, the system may allow the client to submit future dates 30, select the current scheduled dates 302, and view past dates 303.

[0071] Alternatively or additionally, for simplicity, each week's display, 305, may only show working days of the week. Any combination of full weeks, weekends, and/or weekdays may be shown.

[0072] In certain examples, a client may click on any of the day buttons 306 to choose that entire day as his or her availability. When the day is selected, an icon may appear in the day, or the color of the day may change, for example. When the user has selected all of his or her available days 306, the client may submit a whole week at a time using the submit button 304 to the system database, e.g. cloud database.

[0073] FIG. 4 shows an example screenshot of another client calendar view. In this example, the client may enter extra delivery restrictions, such as the maximum number of deliveries per day 401 or per week 403 and then select submit 402 for upload of the information to the system. Information may be entered by the client clicking any of the boxes 401 or 403 and entering a number, for example.

[0074] Alternatively or additionally, the system could be configured to allow the client to enter any kind of data in such an example screen, i.e. the delivery restrictions example is merely exemplary. For example, the client could customize the kind of deliveries, specify the payload of the deliveries, indicate what time of day the deliveries can be made, indicate a maximum distance each delivery can be from a given point, etc.

[0075] Product Availability Examples

[0076] FIG. 5 shows an example screen shot of another interactive calendar display. In this example, all available dates for the product pickup are displayed. Because in certain example embodiments, the employee driver and client availabilities are set first (and have more restrictive parameters), there are only a finite number of product pickup dates 502 available. In this example embodiment, if there are more than nine dates available for product pickup, then the user may click on buttons 503 or 501 to move forward or ahead in time, respectively and view other dates. The example of viewing nine days is merely exemplary and not intended to be limiting. Any number of days could be displayed and viewed by a client.

[0077] In the example screen shot of FIG. 6, one day 601 has been selected and all available times on that selected day are displayed 602. The example shows a breakdown of every half hour starting at 9:30 AM but it should be understood that other time breakdowns are contemplated and displayed from any range of times during a day. Once again, because the employee driver and client availabilities are set first (and have more restrictive parameters), there is only a finite number of product pickup times 602 available.

[0078] The example shows a product (or product manager) selecting a day, e.g. 30 October 2014. The delivery address is shown in the screen next to the selected time. There is a text box 603 for the product (or product manager) to input any comments about the expected product delivery and a submit 604 button after the information has been input. Then the system sends the information to the master calendar to update.

[0079] System Flow Examples

[0080] FIG.s 7A, 7B, 7C and 7D schematically illustrate an exemplary system used for collecting employee driver, client, and product availability, analyzing route conditions to determine the best route for each employee driver, and disseminating information regarding those routes according to certain embodiments of the present invention. FIG.s 7A, 7B, 7C and 7D (collectively FIG.s 7) are continuations of one larger flow diagram, divided out for clarity purposes. The indications as to where and how the diagrams are interconnected are shows in the figures.

[0081] As the example flow diagram in FIG.s 7 take into account time, it will be described when the client and delivery fleet's availabilities have been entered first. Thus, the client and delivery fleet's availabilities will be used to determine the product's availabilities in this example embodiment. However, the product and client's availabilities could be entered first to determine what the employee driver's availability should be. Additionally, the employee driver and product availability could be entered first to determine what clients could be delivered to in a given amount of time.

[0082] As shown in FIG. 7D, after the appropriate delivery fleet employee drivers 712 have been determined in correlation with clients' available days 738 in FIG. 7 A, the process of determining future potential routes may be initiated. For each fleet entity, their previously scheduled appointments ("events") may be retrieved from a database 726 in FIG. 7A (which is the same as 726 in FIG. 7D). Each event ("E") may contain the destination of a fleet unit. The events may be arranged in chronological order (E₀, Ε^.ΕΝ). The route ("R") may be determined by public and commercial API's and data sources taking into account driving factors such as traffic and other events such as weather. For every event E, a route may be built using the previous route R as the starting location for the new event E. For every hour that exists within a given fleet employee driver's availability (e.g. 1106 in FIG. 11), a potential route (pRo) is constructed with the starting location being the previous R and the ending location being the new product's pickup location; and a potential route (pR is constructed with the ending location being the future E and the starting location being the prior product's pickup location.

[0083] In FIG. 7D, the client data entry segment 710 encapsulates various types of data entry available to one or more clients, e.g. External System 704; Client Availability GUI 706; and bulk data entry, e.g. Comma Separated Value ("CSV") Upload 702, through API 708 into a database 724.

[0084] In 706 the client may enter availability dates and other parameters into a database 724 using a graphical user interface (GUI) on any kind of networked device such as a desktop computer, tablet, phablet, wearable or smartphone. The client may not be limited to the availability input 706, however, and can also input availabilities and other parameters into the database by an external third-party system 704 that can communicate with the application programming interface (API) 708 and thereby the system, in a similar manner to the previously mentioned GUI 706, but specially tailored to the clients' needs, possibly lying on the client's own servers. Additionally, data can be input into the database by a CSV upload 702, which would allow older MS Excel-based clients to input their availabilities as well.

[0085] Alternatively or additionally, the purpose of the API 708 may be to normalize any data that is entered into it and turn it into data that is acceptable for entry and storage in the database

724.

[0086] In one or more embodiments, employee driver data entry system 712 in FIG. 7B encapsulates the various types of data entry available to an employee driver through API 720 into a database 740 in FIG. 7A. Those of skill in the art would appreciate that although database 740 is illustrated as a separate database from database 724 in FIG. 7D in this example, other configurations are contemplated, for instance, databases 740 and 724 could be implemented as single database or a distributed database. The employee driver can enter availabilities into the database by a GUI 716 on desktop, tablet, or mobile phone/computer, etc. in FIG. 7B. An external, customized system 718 that communicates with the system's API 720 may be used as well. Older systems can also be supported by data entry by a CSV upload 714. The API 720 may be used to normalize the data that is entered into an acceptable format for entry and storage into the database 740 in FIG. 7A.

[0087] Alternatively or additionally, the product (or product manager) data input 768 may be similar to clients input 710 in FIG. 7D and employee drivers input 712 in FIG. 7B. Product data input system 768 in FIG. 7C encapsulates the various types of data input/output available to the system. For instance, a product manager or the system may automatically select/enter product availabilities 766 using a GUI 762 on desktop, tablet, or mobile phone/computer, etc. in FIG. 7C. The product manager may also interact with the system by external, customized system 764 or by a CSV interface 760 to select/enter product availabilities 766. The selected product pickup data/time 766 may be transmitted through API 770 into a database 724 in FIG. 7C for storage and later retrieval. The API 758 may be used to normalize the data between the system and the product availability interface 768.

[0088] In operation, for each product pickup time selected through the product availability GUI 762 in FIG. 7C; product availability CSV 760; and external system 764, data flows from the system using API 758. For instance, data flows from the database 724 in FIG. 7D, to the database 740 in FIG. 7A or internally within the same database if the two are the same, depending on the embodiment. The process begins (see FIG. 7D) by first extracting data comprising all currently scheduled deliveries for a client (i.e. product to client nodes) 726; the client geolocation, availabilities, and other parameters, such as delivery restrictions 728; and the current timestamp 730 of when the generation of the data for 760, 762, and 764 using the API 758 in FIG. 7C begins. Using the current scheduled deliveries for the client 726 in FIG. 7D and the client geolocation and availabilities 728, the application may determine the client's true availability 732 in FIG. 7A by subtracting currently scheduled deliveries from the client availabilities originally set. If there are no dates available, as determined in step 734, no dates are generated by the API in 758 in FIG. 7C and the process exits at 736 and restarts when new client availability dates are entered or after a new product pick time is chosen in step 766. In one or more embodiments, the system may proceed to optimize currently scheduled deliveries based on updated information such as changes in fleet employee driver availabilities, client availabilities, etc. For instance, when an employee driver in a currently scheduled delivery suddenly changes availability, e.g. due to illness, the system may reprocess for that scheduled delivery as if it's a new client availability by removing the scheduled delivery from the currently scheduled delivery database.

[0089] However, if at step 734 a determination is made that dates are available, then the true filtered client availability dates 738 in FIG. 7A may be generated and sent to the database 740 that receives employee driver availabilities.

[0090] Alternatively or additionally, the database 740 may then send the fleet availability 742 originally set through 712 in FIG. 7B and the filtered client availability dates 738 in FIG. 7A that it received to the system. Additionally, the database 740 may also send the geolocation 744 of each of the employee drivers to the system. The database 724 in FIG. 7A - which is the same as database 724 of FIG. 7D - may also send the currently scheduled nodes (i.e. deliveries) 726 in FIG. 7A for each employee driver for each of the client availability dates 738 to the system. A computer application in the system then determines the true availabilities 750 of the employee driver by subtracting the currently scheduled deliveries (nodes) 726 from the fleet's originally set availabilities 742. For each of the hours that remains in the employee driver's availability, the computer application will determine the duration of the route 754 in FIG. 7C between the product and the employee driver's last scheduled delivery. In this example for the route 754, the application may take into account one or more parameters such as traffic, weather, time, employee driver geolocation, skill level of the employee driver, the resources available to the employee driver, and any other parameters 752 to determine how long the route will take or if the route is possible. For instance, the application may query a database of historical traffic record data, a weather database to determine the average temperature and road conditions, a public government database to find road speeds, and other third party providers that can provide any of the above or real-time data to supplement the data already generated and/or provided by the company's employee drivers.

[0091] Alternatively or additionally, the system may include the fleet employee driver's skills and/or resource in determining if the route is possible. This may be for systems where it is not necessary that all employee drivers of the fleet be trained to the same skill level and that all fleet employee drivers are capable of performing all the tasks required by each client. Thus, it may be desirable to determine that a fleet employee driver has the skill and the resource, e.g. automobile, to do the task. For instance, if a task calls for collection of biological products, then the employee driver should have the appropriate qualification for collection of biological products and it may also be desirable that the employee driver's delivery vehicle, e.g. 102, 102a, or 102b, is equipped to carry the biological product.

[0092] At block 756 a list of hours with a route that will successfully fit - using the hour as its pickup time - into the employee driver's schedule is then generated in FIG. 7C and passed to the API 758 for normalization. After normalization at API 758, the available pickup hours (i.e. date and time) for that particular product may be presented on a GUI 762, made available through CSV 760, or made accessible through an external system 764 for selection by a user or by an automated process. The selected date and time 766 is then sent to API 770 for normalization and ultimately stored in a database 724 for future retrieval. Thus, in one or more embodiments, database 724 comprises currently scheduled nodes.

[0093] The entire flowchart process in FIG.s 7 may be repeated each time a new product pickup time (node) 766 is chosen. Those of skill in the art would appreciate that the database 724 in FIG. 7C is the same as the database 724 in FIG. 7A and FIG. 7D.

[0094] Thus, the system disclosed here is able to accumulate various schedules from various fleet delivery employee drivers, aggregate and save the data and use it to coordinate proper and prompt delivery of any of various products or services over any geographical area. The system can be used to adjust delivery based on updates from the delivery fleet and/or customers as well as adjust based on outside influences such as traffic and weather. [0095] FIG. 8 is an example flow diagram of a use scenario for collecting employee driver, client, and product availability, analyzing route conditions - by servers and processors running a/many computer program(s) - to determine the best delivery route for each employee driver, and disseminating those routes according to certain embodiments herein. Although in this particular illustration shows the client 802 and fleet 804 availabilities as top processes, the computer application is not limited to the order in which the availabilities are entered into the system. Thus, for instance, the client and fleet availabilities may be synchronous or

asynchronous with the rest of the process steps without deviating with the spirit of the invention.

[0096] First, in the example, the delivery fleet availabilities 804 and client's availabilities 802 are entered into the system by an API 806. The entire fleet and client's availabilities do not need to be entered all at once. However, only the availabilities 804 and 802 entered thus far are taken into consideration when determining available product pickup times for presentation in block 832.

[0097] After the API 806 normalizes the data entered by the clients and fleet, in this example, it will report data 808 to the system for determination of dates in which an employee driver is available to drive the delivery fleet that corresponds to the client requested delivery dates. As illustrated, processing of each employee driver for correlation with client availability starts in step 810 using fleet and client availability information from block 808, where the next fleet employee driver is selected. A determination is made in block 812 if all the fleet employee drivers have been processed. If all the fleet employee drivers have not been processed, then the first client available date acceptable to the client for delivery is obtained in block 814. The system proceeds to step 816. In step 816, a check is made if all the client available dates have been processed. If not, the system proceeds to step 818 where a determination is made if the employee driver is available on the date acceptable to the client for delivery and, optionally, if the employee driver has adequate skill and resource to do the task. If employee driver is available (and skilled), then the system will add that date, and all hours still available on that date (subtract currently scheduled nodes), to an "Hour Queue" 820. The system subsequently proceeds to block 821 to obtain the next client available date and then returns to 816 to repeat the process until all client available dates are processed.

[0098] Alternatively or additionally, in one or more embodiments, by including the fleet employee driver's skills in the processing task in step 818, it is not necessary that all employee drivers of the fleet be trained to the same skill level and that all fleet employee drivers have resources capable of performing all the tasks required by each client.

[0099] However, if at block 818 a determination is made that the fleet employee driver is not available, the system proceeds to block 821 to get the next client available date and then returns to 816. Blocks 816 through 821 are repeated until all client available dates are processed for the current fleet employee driver selected in block 810.

[00100] However, if at step 816 a determination is made that all client available dates have been processed for the current fleet employee driver, alternatively or additionally, the system proceeds to block 822 for determination of employee driver availability for the route. Thus, at block 822, the next available hour is obtained from the Hour Queue (see block 820). A determination is made in step 824 if all available hours in the Hour Queue have been processed. If no, processing proceeds to step 826 where a determination is made if the fleet employee driver can perform the route for the selected hour. If so, the Hour is added to the Available Hour Array/Stack in step 828. Block 828 may include additional information such as the employee driver's biographic data and skills. Processing then returns to step 822 for the next available hour in the Hour Queue. If however, at step 826 a determination is made that the fleet employee driver cannot perform the route with the selected starting hour, processing returns to step 822 for the next available hour in the Hour Queue. Blocks 822 through 828 are repeated until all available hours in the Hour Queue are processed for the current fleet employee driver selected in block 810.

[00101] Alternatively or additionally, once all dates and their available hours have been added to the Hour Queue, each hour for each date is used as a pickup time for route determination by the system. For instance, at step 826, the system may take each hour as pickup time, and then use product geolocation, client geolocation, employee driver geolocation, weather and traffic information, as well as road information, from various public and private databases, to determine if the route will fit in the employee driver's schedule for that day, in the hours will saved 828 by the system. After all of the hours from all of the available days for an employee driver are ran through steps 822 through 828, a set of possible product pickup hours 828 are determined and stored for that employee driver.

[00102] However, if at step 824 a determination is made that all available hours in the Hour Queue have been processed, the system returns to block 810 for processing of the next fleet employee driver. If at step 812 a determination is made that all fleet employee drivers have been processed, the system proceeds to block 830. [00103] In this illustration, steps 810-828 are repeated for each delivery fleet employee driver, producing a final array of possible product pickup hours at block 828. Any duplicate hours in the array are removed in step 830 so that there are no duplicates displayed to the user or system to choose at block 832. The user, or an automated system, then selects a product pickup time 836. The selected product pickup time and its associated route are then sent to an API 836 for later use.

[00104] Master Scheduler Examples

[00105] Alternatively or additionally, in some embodiments, the master scheduler may be considered the backend servers and the running of a master schedule for all of the deliveries, request from customers, availability of delivery units, real-time geolocation updates of delivery units and alarms used to indicate potential problems in the master schedule. By centralizing the master schedule and all of the real time updates to the delivery units, the master scheduler may be able to coordinate many multiple deliveries to many multiple destinations, adjust to problems in real time and update and fix problems to the delivery schedule. In such a way, this centralized system is able to coordinate and comprehend many massive amounts of data, and in real time, quickly allow analysis of the situation and in some example embodiments, suggest possible solutions to problems and even potential problems.

[00106] FIG. 9 shows an example graphical user interface for the master scheduler backend, which shows all employee driver availabilities, client availabilities, and pickup routes currently scheduled. Additionally, it may be used as another way to schedule product pickup routes for products that are already located in the database. In this example embodiment, there is a calendar section 902 that displays how many employee drivers have open slots in their availability schedule. For example, for the particular date of October 6, 2014 903, there is only a single employee driver that has an open slot in their schedule, whereas on October 13, 2014 901, there are a total of 19 open availabilities.

[00107] In this example, a section of the GUI in FIG. 9 may allow the user to select a client 904 from a dropdown list, as well as a product 907 from a second dropdown list. In this particular embodiment, the product 907 happens to be a biological sample from a particular donor. When a client 904 and a donor 907 are chosen, the master scheduler pulls the client availabilities and restrictions, as well as the donor's geolocation, which the system then uses to determine which employee drivers have availabilities that match up with the client's availabilities and restrictions. Such a geolocation system may be constantly updated with information from the individual delivery units. The system may receive these updates and reflect them on the map. In such a way, the master scheduler may be able to view the real time or near real time location of the entire fleet, portions of the fleet, and/or individual units as selected.

[00108] Further alternatively or additionally, these employee drivers 909, along with their schedules 908 may be displayed under the map. Additionally, the users that match a client may also be shown visually as a marker 910 on a map 906 that can be zoomed in our out as the user needs. The schedules 908 can further be acted upon by the user, as shown in other figures.

[00109] FIG. 10 shows a detailed view of the calendar section 902 illustrated in FIG. 9, more specifically, the calendar graphical user interface that displays how many employee drivers have available schedules on a particular day. When the user first arrives at the master scheduler GUI FIG. 9, the first thing the user interacts with is the 'calendar section', detailed in FIG. 10. Upon arrival to the master scheduler, there may be no date selected and thus no date showing in the 'selected date' 1006 area, here "9/29/14" is shown in the example. Thus, the calendar shows the overall availabilities of each fleet employee driver and any scheduled product pickups on each day of the month. These availabilities are updated by the system when delivery employee drivers update their information using the mobile devices. Thus, the calendar may update periodically with new information regarding the availabilities. In this way, the entire delivery fleet may reflect their availabilities in one central display allowing for proper coordination of delivery resources by only one person or few people instead of trying to coordinate many multiple delivery units with many multiple middle managers and schedulers. This system makes delivery coordination more efficient.

[00110] For example, on October 17, 2014, i.e. block 1008, there were 10 employee drivers that had schedules with open blocks of time. The dates in the calendar are displayed one month at a time; however, the months can be cycled forward or backwards by clicking forward or backwards buttons 1004 at the top right of the screen. Any amount of time could be displayed on the system, weeks, weekends, blocks of any number of days. A month is shown as an example only.

[00111] Alternatively or additionally, the user can click the 'today' button 1002 to make sure the calendar shows the current month. If the user selects any of the dates, e.g. 1008, on the map, then a list and visual representation of available employee drivers will become available at the bottom of the screen, which is detailed in FIG. 11. [00112] FIG. 11 shows a detailed example of the map section 906 and schedules 908 illustrated in FIG. 9, more specifically, the map and availability graphical user interface that displays where on the globe each fleet employee driver is located, e.g. 1110, as well as each schedule, e.g. 1104. When a user selects a particular date, e.g. 1008, from the calendar in FIG. 10, then all of the delivery employee drivers' locations are displayed as markers 1112 on an interactive map 1110, where the user can zoom-in or zoom-out, as well as request a display of a list of delivery employee driver names 1102. Each of the employee driver's schedules, e.g. 1104, shows the company's hours of operation, e.g. from 7:00 A.M. on the left side ("7") to 5:00 P.M on the right side ("5") of the schedule. Note that in this illustrative example, the hours of operation are displayed in half hour increments but other time increments may be used without deviating from the spirit of the invention. In this example, the grayed time area with grey numbers, e.g. 1109 (i.e. 4:30 pm to 5 pm), of the employee driver's schedule 1104 represents a time span that the employee driver has chosen not to work (or rather the employee driver is not available). The grayed area with dark numbers, e.g. 1108 (i.e. 8:30 am to 11:30 am), represent currently scheduled product pickups and the time it will take for the employee driver to leave the prior appointment, travel to the new product, and pick up the product. The white areas with dark numbers, e.g. 1106 (i.e. 7 am to 8:30 am and 12 pm to 4:30 pm), represent an available time span in the employee driver's schedule.

[00113] The user may also want, instead of every employee driver's general availability, to display only the schedules of employee driver's 1104 that are in geographical proximity to a particular client, which can be chosen in a drop-down list 1116 that contains all of the company's clients. For example, alternatively or additionally, a company might have 100 overall employee drivers that have availabilities on a certain day, but only 10 employee drivers that are within a given geographical range of the client. Additionally, the number of available employee drivers on each day block, e.g. 1008, (FIG. 10) will also change to match the new filtered list of employee drivers available, e.g. 1102. Example embodiments may allow a master scheduler to tailor the geographical proximity to whichever range they desire. Such tailoring may be affected by the substance of the delivery itself, the mode of transportation of the delivery employee drivers, the traffic and weather conditions at a given time, etc. Thus, by allowing the master scheduler to tailor the visibility of delivery employee drivers, the system allows the master scheduler to best assign and adjust the deliveries in a live environment. [00114] The user may also want, instead of every employee driver's general availability and what employee drivers are within geographic range of the client, to know what employee drivers are in geographic range of both the product and client. By entering a product's name on the input field 1114, the master scheduler will determine what employee drivers are both in range of the client and the product by using their geolocation. Once again, the schedules, e.g. 1104, and numbers on each day, e.g. 1008 in FIG. 10, will update to reflect the new client and product parameters entered.

[00115] FIG. 12 shows an example modal graphical user interface that the system may display when certain elements are selected on the master scheduler. For example, when a currently scheduled route, e.g. 1108 from FIG. 11, is selected, a modal 1202 may appear that displays more detailed information 1210 about an employee driver's currently scheduled pickup. This example shows a time of appointment (e.g. "10:00 AM"), travel route (e.g. shown on map 1204), trip duration (e.g. "8:30 to 11 :30"), and any other details about the route including a master plan number, here "Plan 12" and donor name ("name"). The travel route may be visually displayed on a map 1204 that can be zoomed-in or zoomed-out, scrolled etc. In this illustrative example, the origin of the route 1206 is displayed by a marker with an 'A' and the destination 1208 is displayed by a marker with a 'Β'. In such a way, the master scheduler may see detailed information of this particular scheduled delivery and further customize it as necessary.

[00116] FIG. 13 shows a different example modal graphical user interface that may appear when certain elements are selected on the master scheduler. This example modal displays more detailed information about an employee driver's current availability 1310 and allows a user to select a product from the database and manually add it to that employee driver's availability for that day. For example, by clicking on the ' 12', e.g. box 1301, the user has told the system that a draw might want to be scheduled at noon on that day. The modal 1302 displays the time period selected, e.g. 1304, and prompts the user to select a product 1306 and a client 1308. The master scheduler, after clicking the 'submit' or 'schedule' button 1312 then determines if the product can be added to the employee driver's route, and if it can, the system adds it. The route (i.e. block 1310) will then appear as a gray block on the employee driver's schedule, e.g. similar to block 1314. If the product cannot be picked up, an alert may be given to the user that a different time period may be selected.

[00117] FIG. 14A shows an example graphical user interface that may be used by the system to communicate with employee drivers by the networked mobile devices, and disseminate an employee driver's schedule and product pickup route information, as well as other information about the route or pickup, which can be displayed on any kind of mobile device while in the field. The graphical user interface, in this embodiment, is shown as a mobile application.

[00118] The menu of the application 1424 can be found in the top left corner, which allows for the employee driver to find different sections of the application, such as the area where they can input their future availabilities, as illustrated in FIG. 2. In the top right corner is a message button 1422, that when clicked will allow the employee driver to contact the master scheduler and update it with new route information, by the network.

[00119] In this example, the time 1402 and date 1404 are displayed at the top of each "card" 1401 that represents a biological product pickup, or any other type of delivery pickup. Each pickup on the employee driver's route will have a card. Pertinent information to the route, such as the donor name and study information 1406, as well as pickup address 1408 of the donor. There is also a map 1411 in this example, of the route which displays information such as the origin "A" 1410, destination "B" 1412, and the distance 1420 between the two.

[00120] In certain examples, a more detailed map can be found by clicking on the 'marker' button 1414 in the bottom left corner of the example display, as well as the ability to call the donor or customer by clicking on the phone button 1416. Certain examples embodiments may also allow an update to be sent to the master scheduler that the draw has been completed using the 'shipped' button 1418 shown on the bottom right corner of the card 1401.

[00121] Alternatively or additionally, the top corner of the card 1401 may have a 'flip' button 1424, that when clicked gives the employee driver even more information about the draw or route.

[00122] When the card 1401 is flipped, as shown for example in FIG. 14B, more information about the route may be displayed, such as more details 1425 about the study or patient, such as diagnosis and Patient ID, in a bio pickup/delivery example. Even information that the customer input himself or herself when they chose the product pickup time in FIG. 6 is displayed, e.g. gate codes 1429 in the illustrative example, or other pertinent pickup information. Supplies 1432 needed to obtain the product from the donor are listed at the bottom of the card.

[00123] The employee drivers can also update the master scheduler alternatively or additionally, with the information about the draw by click on the 'ID/Diagnosis' button 1426 to update the donor's 'ID/Diagnosis,' as well as update the master scheduler what products have been drawn (picked up) from the donor by clicking on the 'Barcodes Scanned' button 1428. The 'Ship Now' button 1430 allows the employee driver to notify the master scheduler that the draw has been completed. There is also an area 1431 to show the employee driver how they will be delivering the product to the client. In this example, the employee driver will be delivering it by 'hand delivery' to the client's location.

[00124] FIG. 15 shows an example graphical user interface that may be used by the system to disseminate the delivery schedule to the client (or consumer of the product), as well as other information about the product or delivery schedule. In this example embodiment, the client's deliveries 1500 have been divided into two categories, upcoming 1502 and completed 1504. As this example shows delivery for biological products, the phrase 'draw' is used in place of 'product deliveries.' Similar to how the employee driver could see pertinent information about the patient and route, the client can as well. For example, the date the product was picked up 1506 or details about the product, in this case, the ethnicity of the source of the biological product 1508 can be found. Although FIG. 15 is illustrated by itself, it is usually found juxtaposed to the graphical user interface illustrated in FIG. 3.

[00125] FIG. 16 shows an example message that the system could generate and communicate in order to inform the pickup details. This may include information regarding the product pickup time such as the product, or donor (biological product) in this embodiment, as well as other information. This message could have any of various forms including but not limited to an email, SMS text message, social media message, or any of other various communications. In this example, the donor name 1602 and the employee driver's name 1604 are shown at the top of the email, which helps the donor confirm the accuracy of the biological pickup. The appointment details 1606 follows, which has time and date 1608 of the pickup, the address 1610 of the pickup, and other information like the phone number 1612 and email 1614 address that belong to the donor. The donor may have the ability to reply to the message and cancel or confirm the appointment as well, notifying the master schedule so that the appropriate actions may be taken. Additionally, although the display of the product information is disseminated by email in this particular example embodiment, the dissemination is not limited to email. A graphical user interface may also be utilized, such as on a website or application on a phone, laptop, tablet, or desktop.

[00126] Conclusion

[00127] The foregoing description, for purpose of explanation, has been described with reference to specific embodiments. However, the illustrative discussions above are not intended to be exhaustive or to limit the invention to the precise forms disclosed. Many modifications and variations are possible in view of the above teachings. The embodiments were chosen and described in order to best explain the principles of the invention and its practical applications, to thereby enable others skilled in the art to best utilize the invention and various embodiments with various modifications as are suited to the particular use contemplated.

[00128] The term "first", "second" and the like, herein do not denote any order, quantity or importance, but rather are used to distinguish one element from another, and the terms "a" and "an" herein do not denote a limitation of quantity, but rather denote the presence of at least one of the referenced item.

[00129] The innovations herein may be implemented using one or more components, systems, servers, appliances, other subcomponents, or distributed between such elements. When implemented as a system, such systems may include and/or involve, inter alia, components such as software modules, general-purpose CPU, RAM, etc. found in general-purpose computers. In implementations where the innovations reside on a server, such a server may include or involve components such as CPU, RAM, etc., such as those found in general-purpose computers.

[00130] Additionally, the innovations herein may be achieved using implementations with disparate or entirely different software, hardware and/or firmware components, beyond that set forth above. With regard to such other components (e.g., software, processing components, etc.) and/or computer-readable media associated with or embodying the present inventions, for example, aspects of the innovations herein may be implemented consistent with numerous general purpose or special purpose computing systems or configurations. Various exemplary computing systems, environments, and/or configurations that may be suitable for use with the innovations herein may include, but are not limited to: software or other components within or embodied on personal computers, servers or server computing devices such as

routing/connectivity components, hand-held or laptop devices, multiprocessor systems, microprocessor-based systems, set top boxes, consumer electronic devices, network PCs, other existing computer platforms, distributed computing environments that include one or more of the above systems or devices, etc.

[00131] In some instances, aspects of the innovations herein may be achieved by or performed by logic and/or logic instructions including program modules, executed in association with such components or circuitry, for example. In general, program modules may include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular instructions herein. The inventions may also be practiced in the context of distributed software, computer, or circuit settings where circuitry is connected by communication buses, circuitry or links. In distributed settings, control/instructions may occur from both local and remote computer storage media including memory storage devices.

[00132] Innovative software, circuitry and components herein may also include and/or utilize one or more type of computer readable media. Computer readable media can be any available media that is resident on, associable with, or can be accessed by such circuits and/or computing components. By way of example, and not limitation, computer readable media may comprise computer storage media and communication media. Computer storage media includes volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and can accessed by computing component. Communication media may comprise computer readable instructions, data structures, program modules and/or other components. Further, communication media may include wired media such as a wired network or direct-wired connection, however no media of any such type herein includes transitory media. Combinations of the any of the above are also included within the scope of computer readable media.

[00133] In the present description, the terms component, module, device, etc. may refer to any type of logical or functional software elements, circuits, blocks and/or processes that may be implemented in a variety of ways. For example, the functions of various circuits and/or blocks can be combined with one another into any other number of modules. Each module may even be implemented as a software program stored on a tangible memory (e.g., random access memory, read only memory, CD-ROM memory, hard disk drive, etc.) to be read by a central processing unit to implement the functions of the innovations herein. Or, the modules can comprise programming instructions transmitted to a general purpose computer or to processing/graphics hardware by a transmission carrier wave. Also, the modules can be implemented as hardware logic circuitry implementing the functions encompassed by the innovations herein. Finally, the modules can be implemented using special purpose instructions (SIMD instructions), field programmable logic arrays or any mix thereof which provides the desired level performance and cost.

[00134] As disclosed herein, features consistent with the present inventions may be

implemented by computer-hardware, software and/or firmware. For example, the systems and methods disclosed herein may be embodied in various forms including, for example, a data processor, such as a computer that also includes a database, digital electronic circuitry, firmware, software, or in combinations of them. Further, while some of the disclosed implementations describe specific hardware components, systems and methods consistent with the innovations herein may be implemented with any combination of hardware, software and/or firmware.

Moreover, the above-noted features and other aspects and principles of the innovations herein may be implemented in various environments. Such environments and related applications may be specially constructed for performing the various routines, processes and/or operations according to the invention or they may include a general-purpose computer or computing platform selectively activated or reconfigured by code to provide the necessary functionality. The processes disclosed herein are not inherently related to any particular computer, network, architecture, environment, or other apparatus, and may be implemented by a suitable

combination of hardware, software, and/or firmware. For example, various general -purpose machines may be used with programs written in accordance with teachings of the invention, or it may be more convenient to construct a specialized apparatus or system to perform the required methods and techniques.

[00135] Aspects of the method and system described herein, such as the logic, may also be implemented as functionality programmed into any of a variety of circuitry, including programmable logic devices ("PLDs"), such as field programmable gate arrays ("FPGAs"), programmable array logic ("PAL") devices, electrically programmable logic and memory devices and standard cell-based devices, as well as application specific integrated circuits. Some other possibilities for implementing aspects include: memory devices, microcontrollers with memory (such as EEPROM), embedded microprocessors, firmware, software, etc. Furthermore, aspects may be embodied in microprocessors having software-based circuit emulation, discrete logic (sequential and combinatorial), custom devices, fuzzy (neural) logic, quantum devices, and hybrids of any of the above device types. The underlying device technologies may be provided in a variety of component types, e.g., metal-oxide semiconductor field-effect transistor

("MOSFET") technologies like complementary metal-oxide semiconductor ("CMOS"), bipolar technologies like emitter-coupled logic ("ECL"), polymer technologies (e.g., silicon-conjugated polymer and metal-conjugated polymer-metal structures), mixed analog and digital, and so on.

[00136] It should also be noted that the various logic and/or functions disclosed herein may be enabled using any number of combinations of hardware, firmware, and/or as data and/or instructions embodied in various machine-readable or computer-readable media, in terms of their behavioral, register transfer, logic component, and/or other characteristics. Computer-readable media in which such formatted data and/or instructions may be embodied include, but are not limited to, non-volatile storage media in various forms (e.g., optical, magnetic or semiconductor storage media) though again does not include transitory media. Unless the context clearly requires otherwise, throughout the description, the words "comprise," "comprising," and the like are to be construed in an inclusive sense as opposed to an exclusive or exhaustive sense; that is to say, in a sense of "including, but not limited to." Words using the singular or plural number also include the plural or singular number respectively. Additionally, the words "herein,"

"hereunder," "above," "below," and words of similar import refer to this application as a whole and not to any particular portions of this application. When the word "or" is used in reference to a list of two or more items, that word covers all of the following interpretations of the word: any of the items in the list, all of the items in the list and any combination of the items in the list.

[00137] Although certain presently preferred implementations of the invention have been specifically described herein, it will be apparent to those skilled in the art to which the invention pertains that variations and modifications of the various implementations shown and described herein may be made without departing from the spirit and scope of the invention. Accordingly, it is intended that the invention be limited only to the extent required by the applicable rules of law.

Claims

CLAIMS What is claimed is:

1. A method for scheduling, comprising:

receiving, by a computer server in communication with a data storage and a network, information regarding driver availability times and scheduled geolocations during the driver availability times, over the network;

receiving, by the computer server, information regarding a client needing service including the client geolocation and client availability times to be serviced, over the network; determining, by the computer server, a route and a corresponding route distance for a plurality of possible routes from the driver scheduled geolocations and the client needing service geolocation, during the driver availability times;

determining, by the computer server, a duration to travel each route distance, including driving factors received over the network;

identifying, by the computer server, a list of possible delivery times when the driver can travel from one of the scheduled geolocations to the client geolocation using the determined routes and determined duration to travel each route; and

compiling, by the computer server, the possible delivery times that match the client availability times.

2. The method of claim 1 wherein driving factors include at least one of time of day, traffic, construction, and weather.

3. The method of claim 1 further comprising,

sending to a wireless user device of the driver over the network, the client geolocation,

the compiled list of possible delivery times that match the client availability times, and

the determined route to the client geolocation; and receiving an image from the wireless user device over the network, of a bar code obtained at the client.

4. The method of claim 1 wherein the driving factors includes consideration of at least one of, biographic information of the driver, skill level of the driver, and resources available to the driver.

5. The method of claim 1 further comprising, by the computer server,

receiving information regarding a product availability and geolocation of the product.

6. The method of claim 5, wherein the delivery restrictions includes one or more of the maximum number of deliveries per day or per week, time of day deliveries can be made, and maximum distance each delivery can be from a given point.

7. The method of claim 1 wherein driver availabilities include hours each driver is available for driving.

8. The method of claim 1 further comprising, by the computer server,

receiving updated geolocation of the driver;

adjusting the plurality of routes and duration to travel each route distance according to the updated driver geolocation.

9. The method of claim 1 further comprising, by the computer server,

receiving updated availability times of the driver;

adjusting the list of possible delivery times, based on the updated availability times of the driver.

10. A non-transitory computer-readable medium having computer-executable instructions thereon for a method of scheduling, the method comprising:

receiving, by a computer server in communication with a data storage and a network, information regarding an driver availability times and scheduled geolocations during the availability times, over the network;

receiving, by the computer server, information regarding a client needing service including the client geolocation and client availability times to be serviced, over the network; determining, by the computer server, a route and a corresponding route distance for a plurality of possible routes from, the driver scheduled geolocations and the client needing service geolocation during the driver availability times;

determining, by the computer server, a duration to travel each route distance, including driving factors received over the network;

identifying, by the computer server, a list of possible delivery times when the driver can travel from one of the scheduled geolocations to the client geolocation using the determined routes and determined duration to travel each route;

compiling, by the computer server, possible delivery times that match the client availability times.

11. The instructions of claim 10 wherein driving factors include at least one of time of day, traffic, construction, and weather.

12. The instructions of claim 10 further comprising,

sending , by the computer server, to a wireless user device of the driver over the network, the client geolocation,

the compiled list of possible delivery times that match the client availability times, and

the determined route to the client geolocation.

13. The instructions of claim 10 wherein the driving factors includes consideration of at least one of, biographic information of the driver, skill level of the driver, and resources available to the driver.

14. The instructions of claim 10 receiving an image from the wireless user device over the network, of a bar code obtained at the client.

15. The instructions of claim 10, wherein client availability times includes consideration of delivery restrictions including one or more of the maximum number of deliveries per day or per week, time of day deliveries can be made, and maximum distance each delivery can be from a given point.

16. The instructions of claim 10 further comprising, by the computer server, receiving information regarding a product availability and geolocation of the product.

17. The instructions of claim 10 further comprising, by the computer server,

receiving updated geolocation of the driver;

adjusting the plurality of routes and duration to travel each route distance according to the updated driver geolocation; and

receiving updated availability times of the driver;

adjusting the list of possible delivery times, based on the updated availability times of the driver.

18. A system for scheduling, comprising:

by an application running on a wireless device in communication with a network, the application configured to,

cause display of a graphical user interface (GUI) on the wireless device which allows a user to input available driver times over a given period of time;

send the available driver times to a master scheduler over the network;

send geolocation information to the master scheduler over the network;

receive client information from the master scheduler over the network,

wherein the client information includes geolocation of the client; receive driving directions for display on the GUI to the client geolocation from the master scheduler over the network;

send updated geolocations to the master scheduler over the network; and send updated available driver times to the master scheduler over the network.

19. The system of claim 18 wherein the wireless device is at least one of, a tablet, phablet, wearable, smartphone, and computer system in a vehicle.

20. The system of claim 18 wherein the application is further configured to,

create an image of a barcode at the client; and

send the image to the master scheduler over the network.