CROSS-REFERENCE TO RELATED APPLICATIONThis application claims the benefit of U.S. Provisional Patent Application No. 62/934,336, filed on Nov. 12, 2019, which is herein incorporated by reference in its entirety.
BACKGROUNDCurrent logistical companies manually insert orders for transportations of goods into their system. In doing so, current logistic companies have to manually determine an appropriate route for the goods to get from its current location to a destination location, which sometimes includes stops until arriving at the destination location. As such, current logistical companies must manually determine an appropriate transporter (e.g., a driver, a train, and a flight) for each leg of the transport. Accordingly, current logistic companies are unable to automatically determine an appropriate route and transporters for goods upon receipt of the order. Along these lines, current logistical companies are unable to systematically take into account the user's preferences. As such, current logistical companies are unable to automatically determine that a preferred route for one user may not be a preferred route for another user.
BRIEF DESCRIPTION OF THE DRAWINGSThe accompanying drawings are incorporated herein and form a part of the specification.
FIG. 1 is a block diagram of an example logistical management system, according to some embodiments.
FIGS. 2-4 are example user interfaces of a user request application, according to some embodiments.
FIG. 5 is an example transportation graph generated by a route generator module, according to some embodiments.
FIG. 6 is a block diagram of an example transport module, according to some embodiments.
FIG. 7 is an example drive-only route constructed by a route generator module in communication with a transport module, according to some embodiments.
FIG. 8 is an example route having a connection as constructed by a route generator module in communication with a transport module, according to some embodiments.
FIG. 9 is example transporters identified by a transporter application, according to some embodiments.
FIG. 10 is an example user interface of a transporter application when waiting for an assignment of an order, according to some embodiments.
FIGS. 11 and 12 are example user interfaces of a transporter application upon receipt of an assignment of an order, according to some embodiments.
FIG. 13 is an example user interface of a transporter application for a transporter traveling to a pickup or intermediate location, according to some embodiments.
FIGS. 14-17 are example user interfaces of a transporter application for a transporter at a pickup or intermediate location, according to some embodiments.
FIG. 18 is an example user interface of a transporter application for a transporter traveling to a destination location, according to some embodiments.
FIGS. 19 and 20 are example user interfaces of a transporter application for a transporter at a destination location, according to some embodiments.
FIG. 21 is an example user interface of a transporter application for a transporter upon completion of transportation of goods of an order, according to some embodiments.
FIG. 22 is an example user interface of a transport manager application, illustrating a plurality of orders from different users, according to some embodiments.
FIG. 23 is an example user interface of a transport manager application, illustrating a particular order, according to some embodiments.
FIG. 24 is an example user interface of a transport manager application, illustrating dispatching a transporter for the transport of a particular order, according to some embodiments.
FIG. 25 is an example user interface of a transport manager application, illustrating a digest of a particular order, according to some embodiments.
FIG. 26 is a flowchart illustrating an example process for managing the transport of goods, according to some embodiments.
FIG. 27 is a flowchart illustrating an example process for transporting a good from one location to another location, according to some embodiments.
FIG. 28 is a flowchart illustrating an example process for identifying an appropriate transporter of a good, according to some embodiments.
FIG. 29 is a flowchart illustrating an example process for minimizing the risk of a good delivered past a requested time, according to some embodiments.
FIG. 30 is an example computer system useful for implementing various embodiments.
In the drawings, like reference numbers generally indicate identical or similar elements. Additionally, generally, the left-most digit(s) of a reference number identifies the drawing in which the reference number first appears.
DETAILED DESCRIPTIONProvided herein are system, apparatus, device, method and/or computer program product embodiments, and/or combinations and sub-combinations thereof, for providing an end-to-end suite for managing the transport of goods from receipt of an order to transport of the good to a destination location.
Current logistical systems have many shortcomings in automatically determining an appropriate route from a pickup location to a destination location, upon receipt of a request for transport of goods, and without assistance from a user. First, current logistical systems typically require user intervention for determining the appropriate route and coordinating the transportation of the goods among stops (e.g., pickup location, intermediate locations, and destination location) of the appropriate route. Specifically, upon receipt of the request, authorized users typically manually determine the appropriate route from the pickup location to the destination location. In doing so, authorized users will communicate with transporters and/or methods of transportation to arrange for transport of the goods. As such, for example, authorized users will communicate with a transporter (e.g., a driver) to pick up goods from a pickup location and deliver the goods to a first intermediate location (e.g., an airport). Authorized users will then communicate with a transportation company for transportation of the goods from the first intermediate location to a second intermediate location (e.g., an airport). Authorized users will then communicate with a transporter (e.g., a driver) to pick up the goods from the second intermediate location and deliver the goods to a destination location.
Second, current logistical systems do not consider the preferences of users requesting the transport of goods. For example, current logistical systems do not consider that some users do not like particular methods of transportation (e.g., airplane or train) or particular carriers (e.g., United Airlines or BNSF Railway), to provide a few examples. Accordingly, when determining the appropriate route, current logistical systems do not accurately determine modified costs for different possible routes (and segments) based on user preferences.
Third, current logistical systems do not consider many variables inherent to various possible routes from the pickup location to the destination location. For example, current logistical systems do not consider a transport time for particular transporters (e.g., drivers) to arrive at pickup locations and deliver goods to intermediate and destination locations. Further, current logistical systems do not consider a tender time for particular transporters to receive goods at a pickup location and deliver goods to intermediate and destination locations. Accordingly, when determining the appropriate route, current logistical systems do not consider that different pickup, intermediate, and destination locations have different transport and tender times. In addition, current logistical systems do not consider that transport and tender times may depend on the transporter. For example, some transporters are slower or faster than other transporters.
Fourth, when determining transporters to pick up goods from the pickup or intermediate locations and deliver the goods to the intermediate or destination locations, current logistical systems do not consider all possible transporters capable of transporting the goods. For example, some logistical systems solely determine transporters based on an actual cost. Other logistical systems do not properly compare transporters—such as a transporter previously assigned to transport goods and an unassigned transporter—as possible transporters for transporting goods.
In overcoming the aforementioned shortcomings, the present disclosure provides a central server including a user request application, a route generator module, a transporter application, and/or a transport manager application. The user request application receives a request for transport of a good from a recipient of the good (e.g., a consumer or a hospital) or a transportation company (e.g., United Parcel Service or FedEx Corporation). The request includes a pickup location, a destination location, a service type (e.g., recommended, fastest routing, economy routing, and drive only) and a commodity type (e.g., aircraft parts, computer equipment, documents, electronic equipment, medical device/part, other, etc.).
In some embodiments, upon submission of the order, for determining a preferred route from the pickup location to the destination location, the route generator module receives a pre-generated graph from geographical data module. The pre-generated graph has geographical data, including all possible pickup locations, possible intermediate locations, and/or possible delivery locations. Route generator module may then translate the graph and identify the pickup and delivery locations specified in the request and all possible intermediate locations. Route generator module may then identify all possible routes from the pickup location to the delivery location, which may include one or more intermediate routes.
As such, the transportation graph may include many possible transportation segments making up the possible routes from the pickup location to the destination location and possibly including possible intermediate locations. For example, the possible transportation segments may be from the pickup location, various possible intermediate locations, from the numerous possible intermediate locations to other possible intermediate locations, and from these possible intermediate locations to the destination location. The possible transportation segments may relate to the same or different transportation types (e.g., cars, trains, flight). For example, one possible route may be a drive from a pickup location (e.g., a manufacturing center) to an intermediate location (e.g., a trucking stop) and then from the intermediate location to a destination location (e.g., a store). Another possible route may include a drive from a pickup location (e.g., a hospital) to a first intermediate location (e.g., airport), a flight front the first intermediate location to a second intermediate location (e.g., airport), and a drive from the second intermediate location to a destination location (e.g., hospital).
Route generator module may then identify one more transportation edges for each of the pickup location, the intermediate transportation location, and the delivery location. The transportation edges may relate to a time or a cost relating to the pick up location, the intermediate transportation location, the delivery location, and/or the segments between the locations. The transportation edges may relate to a travel time between locations, a cargo time at specific locations, and a tender time at specific locations, as will be described in more detail below.
Subsequently, the route generator module determines a preferred route based on the possible transportation segments having the lowest actual cost (provided by transporters), for example, using a search algorithm such as A-star (A*). As such, the preferred route may be determined irrespective of an actual cost or a modified cost, as discussed below (e.g., fastest route possible). Conversely, the preferred route may depend on the transportation cost, a user preference, and a likelihood of route approval. In some embodiments, the user preference may be an airline, a flight, and a time of day. In some embodiments, the user preferences include a user's value of time, which may be based on a likelihood of route approval. As such, the preferred route may depend on the likelihood of route approval independent of the user preference.
Further, in some embodiments, upon submission of the order, a transporter application then determines a preferred transporter to transport a good from a pickup location to an intermediate location, from the intermediate location to another intermediate location, and/or from the intermediate location to the destination location. In determining the preferred transporter, the transporter application identifies transporters within a predetermined distance from the pickup location. In some embodiments, the transporters may be scheduled to transport goods for another embodiment. The transporter application then determines if the identified transporters are eligible based on the goods commodity type. For example, some goods may require transporters to have certified licenses or appropriate transportation carriers (e.g., refrigeration, weight). The transporter application also determines if the identified transporters are solicitable. For example, the transporter application confirms that the transporter is able to transport goods to an intermediate or delivery destination prior to the specified times of the route generator module or user.
The transporter application thereafter determines an estimated completion time for transporters to transport the goods to the destination location. In doing so, the transporter application may utilize a transporter model for determining an estimated completion time (ECT) for completing all jobs for each eligible transporter. Based on the estimated completion time, the transporter application selects a preferred transporter. In some embodiments, the preferred transporter is scheduled to pick up and deliver goods for another order before delivering the solicited order.
The transporter application then sends a request to transport the good to the preferred transporter and waits an allotted time for acceptance. If the transporter application does not receive an acceptance within the allotted time, the transporter application restarts the process of identifying a preferred transporter. In some embodiments, the transporter application may consider transporters that did not accept the same job within the allotted time, for example, by denying or not responding to the request.
In addition, in some embodiments, upon the submission of the request, the transport manager application may create a record of the order and place the order in a queue of orders. In doing so, the transport manager application may identify the type of goods and designate them to a special operations team trained to handle their transport. The transport manager application may permit members of the special operations teams to designate scheduled actions, create or edit preferred routes (discussed below), select transporters for different segments, designate tasks to transporters, and specify rewards for completing tasks.
The transport manager application may also be in communication with the route generator module to receive the preferred route and the required pickup times associated with the pickup location, intermediate locations (if applicable), and destination location. Accordingly, the transport manager application may sort the orders based on the scheduled times for various actions and/or preferred departure times for routes. As such, the orders having upcoming scheduled action times or upcoming preferred route times may be provided first, whereas orders having later scheduled action times or later scheduled preferred route times may be provided last. In doing so, the transport manager application may present the order a specified color (e.g., red, yellow, and green) based on the schedule action and/or preferred route time.
Accordingly, to overcome the shortcoming of current logistical systems, the present disclosure's logistical system improves the processing of computing devices for at least the following reasons. First, after receiving an order, computing devices store a location of a pickup and destination node (e.g., a pickup and destination location) in memory. Computing devices then attempt to identify additional routes for the goods. To do so, computing devices may be in communication with external providers (e.g., transportation providers) to identify intermediate nodes (e.g., intermediate locations) for changing transportation carries during the transport to the destination location, and, then, to store these intermediate nodes in memory. Computing devices are further able to identify the different transportation methods between the same nodes (e.g., pickup to intermediate, intermediate to intermediate, and intermediate to destination). As such, computing devices are able to store each possible manner to travel from one particular node to another particular node is stored. These may be considered segments and are stored in memory.
After storing the different segments in memory, computing devices determine an actual cost for each segment, transit time for each segment, and/or a likelihood of route approval for each possible combination of segments. To do so, computing devices may pull data (e.g., travel time, travel cost) from external transportation sources. Computing devices may then determine a user value for each segment based on the transit time and actual cost for the associated segment, as well as the user's value of cost or time. For example, the user may value 1 minute as $3. Alternatively, the user may value 10 minutes as $1. Computing devices may then store the user value associated with that segment in memory.
Thereafter, computing devices utilize a pathfinding algorithm (e.g., A*) to traverse through each possible combination of segments stored in memory. In doing so, computing devices are able to identify the best path for a user based on the segments associated costs. This can be performed automatically without user input and be based on the user's past orders.
FIG. 1 is a block diagram of an example logistical management system (LMS)100, according to some embodiments.LMS100 may includecentral server102,transporter provider104,geographical provider106, and/oruser devices108A-C. As will be discussed in more detail below,central server102 may receive and process requests for transporting goods from users ofuser devices108A-C. As such, in some embodiments, users sending the requests may be from those in possession of the goods (e.g., owners of the goods). In some embodiments, users may be a carrier delivery service company (e.g., United Parcel Service or FedEx Corporation).User devices108A-C may be a personal digital assistant (PDA), a desktop workstation, a laptop or notebook computer, a netbook, tablet, a smartphone, or any other type of electronic device, to name a few non-limiting examples.
Central server102 may be incommunication transport provider104 and/orgeographical provider106.Transport provider104 may provide transport data of various transportation modes (e.g., airlines, trains, freight trucks). In some embodiments,central server102 is in communication withmultiple transportation providers104 providing transportation information for specific types of transportation and/or companies. For example, transportation providers may be American Airlines, Amtrak, and J.B. Hunt Transport Services. As such,central server102 may be in communication with multipledifferent transportation providers104 of the same or different types (e.g., train carriers, airline carriers, and vehicle carriers).
Further,geographical provider106 may provide geographical data required to process the request. As will be discussed in more detail below, the request includes a pickup and destination location, and, in processing the request,central server102 may identify intermediate locations, which relate to stops between the pickup location and the destination location. Accordingly,geographical provider106 may provide geographical data relating to the pickup, intermediate, and destination locations. As such, where the transporter is a vehicle, geographical data may include traffic and navigational data to pick up, intermediate, and destination locations at different times and days. Along these lines, geographical data may also be information on the pickup, intermediate, and destination location (e.g., parking, precise pickup locations (e.g., department), walking directions, and a map).Geographical provider106 may continually provide geographical data in real-time.
In receiving and processing requests,central server102 includesuser profile module110,geographical data module112,user request application114,route generator module116,transporter module118,transporter application120, and/ortransport manager application122.
User profile module110 stores user profiles. As discussed above, users may be a transportation company requesting transport of goods for their users (e.g., clients) or those requesting transport of their goods. As such, user profiles may be for the transportation companies requesting transport for their users or those wishing to transport their own goods. User profiles may include personal information (e.g., a name, a home address, a phone number, and email address), previous shipping information (e.g., types of previously transported goods, sizes of previously transported goods, previous departing locations, and previous destination locations), user preferences (e.g., a particular transportation type or carrier). Further, in some embodiments, as will be discussed in more detail below, user profiles may include a user value of time (which is used to derive a recommended route for the user).
Geographical data module112 may store geographical data received fromgeographical provider106 and/or from an authorized user. The geographical data may relate to the transport of goods. As discussed above, transporters may pick up goods from a pickup location or an intermediate location, and drop off the goods at the intermediate location, another intermediate location, or the destination location. In some embodiments, the geographical data may relate to possible pickup locations, possible intermediate locations, and possible destination locations. The possible pickup and destination locations may be any physical location relating to the user seeking transport of the good, such as a personal residence (e.g., a house) or a place of business (e.g., a package delivery company, a hospital, a car manufacturer). The possible intermediate locations may be related to one or more modes of transportation. In some embodiments, the modes of transportation may be rail (e.g., trains), air (e.g., airlines), road (e.g., cars, trucks). In some embodiments, the possible intermediate locations may be physical locations related to the modes of transportation. For example, where the mode of transportation is air, the possible intermediate locations may private or public airports. Likewise, where the mode of transportation is road, the possible intermediate locations are truck stops.
Further, in some embodiments, geographical data module may also include transit information relating to the possible pickup locations, the possible intermediate locations, and the possible destination locations. In some embodiments, the transit information may also include prescheduled departure dates and times, prescheduled arrival dates and times, and/or prescheduled transport time, for example, for an airline and/or a freight. In some embodiments, geographical data may also include cutoff times before departure for receipt of goods, for example, for an airport or a train station.
Along these lines, the transport data may also relate to each possible route from the possible pickup locations to the possible intermediate locations or the possible destination locations and from the possible intermediate locations to other possible intermediate locations and the possible destination locations. In some embodiments, the transit information may include driving data (e.g., navigational data, traffic data, road closure data, etc.) from. Along these lines,geographical data module112 may receive updates formgeographical provider106 relating to the transit information (e.g., new departure dates and updates, new arrival dates and times, new transport times, new routes, etc.).
Geographical data module112 may also generate a graph forroute generating module116 to utilize for generating a preferred route from a pickup location to a destination location.Geographical data module112 may generate a graph (pre-generated graph) based on geographical data received fromgeographical provider106 and/or provided by an authorized user. In some embodiments, the pre-generated graph includes nodes all possible pickup locations, possible intermediate locations, and/or possible destination locations. In some embodiments, the graph further includes all possible routes for traveling from the possible pickup locations to the possible intermediate locations, from the possible pickup locations to the possible destination locations, from the possible intermediate locations to other possible intermediate locations, and/or from the possible intermediate locations or to possible destination locations.
User request application114 receives requests for transporting goods fromuser devices108A-C.User request application114 may then process a request for transporting goods from starting a pickup location to a destination location. As discussed above, intermediate companies may utilizeuser request application114 on behalf of their consumers. Additionally, consumers may directly utilizeuser request application114 to transport goods.
FIGS. 2-4 illustrate example interfaces200,300, and400 of user request application114 (ofFIG. 1). Referring now toFIG. 2,user interface200 includes pick uptime202, pick upaddress204, pick-up point of contact (POC)206, pick-upspecial instructions208,destination address210,destination POC212, destinationspecial instructions214,good information216,service type218,commodity type220, and/or submitorder button222.
In some embodiments, as illustrated, pick uptime202 may include a plurality of options, such as “Send a driver immediately,” “Future Pickup,” and “Will Call.” The “Send a driver immediately” option may send a transporter (e.g., driver) immediately upon submission of a request. The “Future Pickup” option may allow a user to provide a designated time and/or date. The “Will Call” option may allow a user to provide a request that the goods be picked up by the user at the destination location.
Pick-up and destination addresses204 and210 provide a location for picking up and delivering the goods, respectively. Pick-up anddestination POCs206 and212 provide an individual for contact before, during, or after transit to and/or from the pickup location and destination location, respectively. Pick-up and destinationspecial instructions208 and214 provide instructions for transporting particular goods with respect to their state (e.g., fragile or perishable), unique circumstances (e.g., deadline, importance), or a special case (e.g., handing of the good (e.g., upright)).Good information216 relates to any information required for the transport of the goods. For example, as illustrated,good information216 may relate to a number of pieces of a particular good having certain dimensions, weight, and/or user reference numbers.Service type218 provides predetermined options for the transporting of the goods. For example, as shown, the options may be a fastest route, a drive-only route, an economy route, and a recommended route, as will be described in more detail below.
Referring now toFIG. 3, upon submission of a request for transport of goods viauser interface200's submit button222 (ofFIG. 2),user interface300 may be presented.User interface300 includesmap302,user request summary304,change service type306,route summary308, and/orconfirmation button310.Map302 presents the route.User request summary304 includes some or all of the user information provided onuser interface200.Change service type306 permits changes to service type218 (ofFIG. 2).Route summary308 includes a pickup date/time and/or a delivery date/time. The pickup and/or delivery dates and/or times may be a range of dates and/or times.Route summary308 also includes a change delivery date ortime option312.
Referring now toFIG. 4, after confirmation of user request viauser interface300's confirmation button310 (ofFIG. 3),user interface400 may be presented.User interface400 includeslive map402, pickup anddestination window404,status updater406, trackingidentification number408,sharable link410, and/ordetail summary412.Live map402 provides a current (live) transport location of goods with respect to a geographical map. Pickup anddestination window404 provides a pertinent date, time, and address for pickup and delivery of goods.Status updater406 provides an update on a status of the transport of goods. As such,status updater406 may provide a list of current and/or past events, which may be a result of reaching a designated geographical location, a specified time, a predefined event (e.g., scanning a package at intermediate location).Tracking identification number408 is a random combination of numbers and letters automatically generated upon submission of an order.Tracking identification number408 may be unique to a user request.Sharable link410 allows users to copy or share access touser interface400. For example, where users are transportation companies,sharable link410 may be provided to their users whose goods are transported.Detail summary412 includes some or all of the information provided via user interface300 (ofFIG. 3).
Referring toFIG. 1,central server102 further includesroute generator module116 to generate a preferred route from a pickup location to a destination location. In some embodiments, uponuser request application114 receiving a user request,user request application114 sends the request to theroute generator module116, which requests the pre-generated graph, as discussed above, fromgeographical data module112.Route generator module116 then translates the pre-generated graph to identify the user request's pickup and destination locations. In some embodiments,route generator module116 also identifies possible intermediate locations corresponding to the pickup and destination locations based on the geographical data.
As discussed above, the possible intermediate relate to locations for products to change carriers and/or modes of transportation to arrive at the destination location. In some embodiments, the possible intermediate locations corresponding to the pickup and destination locations provided in the request are less than all possible intermediate locations provided in the pre-generated graph. In some embodiments,route generator module116 can also identify transit information for the pickup location, each possible intermediate location, and the destination location, as described above.
Further,route generator module116 also identify possible routes from the pickup location to each possible intermediate location, from the pickup location to the destination location, from each possible intermediate location to another possible intermediate location, and/or from each possible intermediate location to the destination location. In some embodiments,route generator module116 may identify multiple possible routes from one location to another location. For example,route generator module116 may identify multiple routes from the pickup location to a possible intermediate location.
Route generator module116 may generate a subgraph from the pre-generated graph based on the pickup location, the destination location, the possible intermediate locations, and/or the possible routes. In some embodiments,route generator module116 may generate the possible routes after generating the subgraph. In some embodiments,route generator module116 may generate the subgraph with the possible routes.
FIG. 5 is anexample transportation graph500 for the transport of goods frompickup location502 todestination location504. In some embodiments,transportation graph500 is the pre-generated graph received from geographical data module112 (ofFIG. 1). In some embodiments,transportation graph500 is a subgraph of the pre-generated graph
Further, as discussed above, in some embodiments,transportation graph500 may include any combination of possibleintermediate locations506A-C. For example, in some embodiments,transportation graph500 may include a single possibleintermediate location506A. Further, in some embodiments,transportation graph500 may include multiple possibleintermediate locations506B and506C.
Accordingly, in some embodiments,transportation graph500 may includepossible transportation segments508A-G relating to the possible routes from startinglocation502 todestination location504, from starting location to each possibleintermediate location506A-C, from eachintermediate location506A-C to another possibleintermediate location506A-C, and from eachintermediate location506A-C todestination location504. In some embodiments,transportation graph500 may include a singlepossible transportation segment508A and508B frompickup location502 to possibleintermediate location506B ordestination location504. Further, in some embodiments,transportation graph500 may also include a singlepossible transportation segment508C from one possibleintermediate location506B to another possible intermediate location506D. Along these lines, in some embodiments,transportation graph500 may also include multiple possible transportation segments508D and508E frompickup location502 to possibleintermediate location506A. Further, although not illustrated, in some embodiments,transportation graph500 may also include multiple possible transportation segments frompickup location502 todestination location504, from one possibleintermediate location506B to another possibleintermediate location506C, and from possibleintermediate location506C todestination location504.
As described above,pickup location502, possibleintermediate locations506A-C, anddestination location504 may relate to the same or different modes of transportation locations (e.g., airports, train stations, trucking stations, etc.). Accordingly,possible transportation segments508A-G may relate to the same or different modes of transportation (e.g., vehicle, airplane, train, waterway, etc.). For example, possible transportation segments508D and508E—frompickup location502 to possibleintermediate location506A—may relate to the same mode of transportation (e.g., airplane). Alternatively, a particular possible transportation segment508D—frompickup location502 to possibleintermediate location506A—may relate to one mode of transportation (e.g., vehicle), and another possible transportation segment508E frompickup location502 to possibleintermediate location506B may relate to another mode of transportation (e.g., airplane). The same may apply frompickup location502 todestination location504 and from one possibleintermediate location506B to another possibleintermediate location506C. As such, a complete route frompickup location502 todestination location504, with or withoutintermediate locations506A-C, may utilize the same or different modes of transportation.
As described above, after generating the subgraph from the pre-generated graph, route generator module116 (ofFIG. 1) also receives transport data relating to thepickup location502,destination location504, each possibleintermediate locations506A-C, andpossible transportation segments508A-G from transporter module118 (ofFIG. 1). In some embodiments,route generator module116 may be in communication withtransporter module118 to determine one or more transformation edges for each ofpickup location502,destination location504, and each possibleintermediate location506A-C. Route generatemodule116 may associate the transformation edges to thepickup location502,destination location504, and/or each possibleintermediate location506A-C.
FIG. 6 illustrates anexample transporter module600 includinglocation submodule602,transportation submodule604, andcargo submodule606. As will be described in more detail below,location submodule602 can provide a tendering edge corresponding to an actual tendering time at each ofpickup location502,destination location504, and each possibleintermediate location506A-C (ofFIG. 5).Transportation submodule604 can provide a transportation edge corresponding to an actual transport time or actual transport cost for each possible route from each ofpickup location502,destination location504, and each possibleintermediate location506A-C. Cargo submodule can provide a cargo edge providing a load or unload time of the good at each ofpickup location502,destination location504, and each possibleintermediate location506A-C. Location submodule602 determines an amount of time for a particular or average transporter to perform tendering good actions at the pickup location, each possible intermediate location, and the destination location (“actual tender time”). Tendering good actions at pickup locations relate to transporters arriving at the pickup location, receiving the goods, and returning to their mode of transportation. Likewise, tendering good actions at the intermediate and destination locations relate to arriving at the intermediate or destination locations and tendering the goods.
For example, in some embodiments, for determining the actual tender time at the pickup location,location submodule602 may determine an aggregate amount of time for a particular transporter to park their vehicle at the pickup location (e.g., hospital), walk a particular place of the pickup location (e.g., a lab), receive the goods (e.g., scanning and signing for the packages of goods), and return to their vehicle. Likewise, for determining the actual tender time at an intermediate location,location submodule602 may determine an aggregate amount of time for a particular transporter to park their vehicle at the intermediate location (e.g., airport), walk to a tender location of the intermediate location (e.g., cargo window), and tender the goods (e.g., wait in line and fill out the appropriate paperwork). Similarly, for determining the actual tender time at the destination location,location submodule602 may determine an aggregate amount of time for a particular transporter to park their vehicle at the intermediate location (e.g., airport), walk to the tender location (e.g., a different hospital), walk a particular place of the pickup location (e.g., a surgery center), and provide the goods (e.g., receiving a signature).
Along these lines, in some embodiments,location submodule602 includeslocation time model608 to predict the actual tender time at the pickup location, each possible intermediate location, and the destination location. In some embodiments,location time model608 may be a machine-learning model trained on historical tender times for known pickup, intermediate, and destination locations and known transporters. In some embodiments,location time model608 may consider that different pickup, intermediate, and destination locations have different processing times based on, for example, size, wait time, and processing requirements. Along these lines,location time model608 may consider that different transporters take different tender times to at the pickup, intermediate, and destination locations. For example, some transporters may walk to and from a location quickly, whereas other transporters may do so slowly.
Further, in some embodiments, for determining the actual tendering time,location time model608 considers the current waiting times of the pickup, intermediate, and/or destination locations for receiving, tendering, and/or delivering the goods, respectively. Accordingly,location time model608 may increase any previously determined transport time by a waiting time for tendering the goods. Also, in some embodiments,location time model608 may predict the amount of time for new pickup/intermediate/destination locations (e.g., where transporters have not previously picked up or delivered goods). In doing so,location time model608 may consider publically known data of the new pickup/intermediate/destination location and transporters' historical times for known pickup/destination locations. Publically known data on the new pickup/destination location may include an average number of individuals (e.g., at various times throughout the day) and a size of the location.
Transportation submodule604 determines an actual transport time or an actual cost for a particular or average transporter to transport the goods from one location to another location (“actual transport time” or “actual transport cost”). The actual transport time and/or actual transport cost may depend on a mode of transportation (e.g., train, car, and airplane), current transport data (e.g., available routes and current traffic), and transporter's historical transport data (e.g., average miles per hour and an average amount of travel time). In some embodiments, the actual transport time and/or the actual transport cost may be received from transport provider104 (ofFIG. 1). In some embodiments,transportation submodule604 may include a transportation time orcost model608 to predict the actual transport time or the actual transport cost. Transport time orcost model608 may be a machine-learning model trained on previously utilized transport data (e.g., used routes, traffic for particular routes, an average speed, and an average amount of travel time) for a particular or average transporter utilizing a particular mode of transportation.
Cargo submodule606 determines an amount of time for loading or unloading goods at the pickup location, each possible intermediate location, and the destination location (“actual cargo time”). In some embodiments,cargo submodule606 includescargo load submodule612 and cargo unloadsubmodule614.Cargo load submodule612 determines an amount of time for placing and loading goods on a method of transportation upon receipt from an intermediate location (“actual cargo load time”). For example, upon tendering a particular package to an airport,cargo load submodule612 determines the amount of time for the airport to place the package on the flight. In some embodiments, the cargo load time may be the method of transportation's cutoff time for receiving packages (e.g., 1 hour before takeoff). In some embodiments, the cargo load time may be based on the cutoff time, the departure time, and the cargo load time. Also, the cargo load time may be further based a cargo open and closed time provided by the method of transportation (e.g., 6:00 AM-12:00 AM).
To determine the actual cargo load time,cargo load submodule612 receives the cutoff time, departure time, and/or cargo open and closed time from transporter provider104 (e.g., American Airlines, United Airlines, etc.) or a transportation agency (e.g., airport, train station, etc.). Accordingly,cargo load submodule612 may update the cargo load time based on feedback by thetransporter provider104 and the transportation agency. For example, if a flight is delayed an hour,cargo load submodule612 will move the cutoff time and departure time back an hour.
Cargo unloadsubmodule614 determines an amount of time for unloading the goods from a method of transportation (“actual cargo unload time”). Likecargo load submodule612, cargo unloadsubmodule614 receives the cargo arrival time, the cargo unload open time, the cargo unload close time, and/or a transportation agency (e.g., airport, train station, etc.) from transporter provider104 (e.g., American Airlines, United Airlines, etc.). Accordingly, cargo unloadsubmodule614 may update the actual cargo unload time based on feedback by thetransporter provider104 and the transportation agency.
Referring toFIG. 1, in some embodiments, after associatingtransporter module118's transport data with one or more edges oftransportation graph500'spickup location502,destination location504, possibleintermediate locations506A-C, andpossible transportation segments508A-G (ofFIG. 5) (e.g., a tendering edge, a transportation edge, and/or a cargo edge),route generator module118 may request user preferences and/or a user value of time from user profile module, which may be unique to a user seeking transport of the good.Route generator module118 may then determine an optimal route based on user-selected service type218 (ofFIG. 2). As discussed above, user-selectedservice type218 may be one of a fastest route, a drive only route, an economy route, and/or a recommended route.
In some embodiments, where user-selectedservice type218 is the fastest route,route generator module116 may generate a preferred route frompickup location502 to destination location504 (ofFIG. 5) based on the least amount of time and/or on the user preference.Route generator module116 may select the preferred route irrespective of the actual cost for transporting the good. For instance,route generator module116 can selectsegment508A to route a good frompickup location502 todestination location504 although other segments may have a lower cost. Along these lines, if the user prefers a certain mode of transportation or carrier,route generator module116 can select segments corresponding to the preferred mode of transportation or carrier, although other segments permit the good to arrive atdestination location504 sooner.
In some embodiments, where user-selectedservice type218 is drive-only and economy route, the preferred route frompickup location502 todestination location504 based on the actual cost and the user preference. In some embodiments, for the recommended route,route generator module118 generates a preferred route frompickup location502 to destination location504 (ofFIG. 5) based on actual cost, user preference, and a likelihood of route approval. Along these lines, as illustrated above with respect toFIG. 6, the transport and location data may be in the form of time (e.g., minutes) and actual cost (e.g., dollars). Accordingly, as stated above, in some embodiments, for the drive-only, economy, and recommended routes,route generator module116 may determine a true user cost relating to the pickup location, possible intermediate location, destination location, and/or possible transportation segments. In some embodiments, for the drive-only and economy routes,route generator module116 may determine a cost per interval of time (e.g., 2 dollars per minute) or a time per monetary unit (e.g., 2 minutes per dollar). In some embodiments,route generator module116 determine a cost per interval of time or a time per monetary unit based on previous user orders In some embodiments, the cost per interval of time may be (Avg$PerMin(OnOperationsOrCustomerApprovedOrders)*Approval Weight)+(Avg$PerMin(OnOperationsOrCustomerDisapprovedOrders)*DisapprovalWeight). In some embodiments, when the user is new,route generator module116 may assign a predetermined cost per interval of time (e.g., 2 dollars per minute) or a predetermined time per monetary unit (e.g., 2 minutes per dollar) for the user.
As such, for the economy and drive-only routes, where there is an actual cost (e.g., dollars) associated with possibleintermediate locations506A-C andpossible transportation segments508A-G (ofFIG. 5), theclient cost=actual cost x (‘cost per interval of time’ or ‘time per monetary unit’). For example,route generator module116 may consider a first and second possible route. The first possible route comprises a flight frompickup location502 to destination location504 (“possible transportation segment508A”). The second possible route comprises a drive frompickup location502 tointermediate location506B (“possible transportation segment508B”), a flight fromintermediate location506B tointermediate location506C (“possible transportation segment508C”), and a drive fromintermediate location506C to destination location504 (“possible transportation destination508G”).Possible segments508A-C and G may have an actual cost of $150, $10, $100, and $100, respectively. Further, the waiting times at theintermediate locations506B and506C may each be 40 minutes. Accordingly, assuming that minute per dollar is 2,route generator module116 may determine that the total client cost for the first possible route is 300 minutes ($150×2 ‘minutes per dollar’) and that the total client cost for the second possible route is 320 minutes (($10×2 ‘minutes per dollar’)+(40 minutes)+($100×2 ‘minutes per dollar’)+(40 minutes)+10×2 ‘minutes per dollar’)). Accordingly, although the first possible route has a user cost more than the second possible route (i.e., $150 vs. $140),route generator module116 will select the first possible route. or example, in some embodiments, for possibleintermediate locations506A-C andpossible transportation segments508A-G (ofFIG. 5) having an associated time but not the actual cost, the user cost may be equal to weight time x (1/‘handler approval’%). For possibleintermediate locations506A-C andpossible transportation segments508A-G (ofFIG. 5) having an associated time and actual cost, the user cost may be equal to ((weight time+(user cost x (‘cost per interval of time’ or ‘time per monetary unit’)))+x (1/‘handler approval’%)).
Further, for the recommended route,route generator module116 may also consider a likelihood of approval ofpossible transportation segments508A-D (ofFIG. 5) by a handler (“handler approval”). As will be described in more detail, handler approval is required for each route. Accordingly, upon determination of a route, the handler may then review the route and either approve or deny all of it or segments of it. Thus, if the route is approved or denied, all segments in the route are marked “good” or “bad” However, if changed, the unchanged segments are marked “good” and the changed segments are marked “bad.” For example, if a user has previously submitted user requests and a particular segment has historically been approved for the user, the path search algorithm (e.g., A*) will likely prefer the particular segment. However, if a particular user has not previously submitted user requests, the likelihood of approval for a particular segment for the particular user may be based on other users. For example, if the particular user is requesting transport of a good similar to other transporters where the particular segment was approved, the likelihood of approval for the particular segment may be high. However, if the particular user is requesting transport of a good different from other transporters where the particular segment was not approved, the likelihood approval for the particular segment may be low. By operating in such a fashion,route generator module116 may accurately consider different possible legs and routes that have different times and costs as preferred by the user.
After deriving the transit cost for each segment of the path, irrespective of user-selected service type218 (ofFIG. 2),route generator module116 may utilize a path-finding algorithm to find a preferred route—having one or more segments—among the plurality of possible routes having a lowest cost (e.g., transit cost). In some embodiments, the path-finding algorithm may be A*, although other path-finding algorithms may be utilized.
Additionally,route generator module116 may receive updates fromtransport provider104 on the delay of scheduled transports (e.g., flights, trains, buses). Likewise,route generator module116 may receive updates fromgeographical provider106 relating to drive-only transportation (e.g., traffic, road closure, accidents). In some embodiments,route generator module116 may receive the updates in real-time. Accordingly,route generator module116 may update the preferred route based on the service type218 (ofFIG. 2) (e.g., fastest route) and/or the user-selected delivery date and time (e.g., Mar. 16, 2020, at 2:00 PM EST).Route generator module116 may then utilize the path-finding algorithm to see if a new preferred path exists.
FIGS. 7 and 8 areexample routes700 and800 frompickup location702 and802 todestination location704 and804 generated fromgeographical data module112 and transporter module118 (ofFIG. 1). As described above, in some embodiments, as illustrated inFIG. 6,transporter module600 includestransportation submodule604,location submodule602, andcargo submodule606. Likewise, as also described above, in some embodiments,transportation submodule604 andlocation submodule602 includestransportation time model610 andlocation time model608, respectively. Accordingly, referring now toFIGS. 7 and 8,routes700 and800 are based on location time models706A-B and808A-G andtransportation time models708 and810A-D.
FIG. 7 is an example drive-only route700 frompickup location702 todestination location704. Location time model706A and706B determines a tendering time at pick uplocation702 anddestination location704.Transportation time model708 determines a travel time frompickup location702 todestination location704. As such, a transporter arrives atpickup location702 and, after receiving goods, departs at first point intime710. Thereafter, the transporter arrives atdestination location704, and, after second amount oftime712, tenders goods.
FIG. 8 is an example ofroute700 frompickup location802 todestination location802 including intermediate, airport locations806A-C. Location time model808A-G determines a tendering time at pick uplocation802, intermediate, airport locations806A-C, anddestination location804. Specifically, location time model808A-G determines a time to do a pickup atpickup location802, a time to tender the goods to the first intermediate location806A, a time to transfer the goods to cargo, a time idle at the second, intermediate location806B, a time for unloading at the third, intermediate location806C, a time to remove the goods from cargo and provide them ready for pickup from the third, intermediate location806C, and a time to do the drop at thedestination location804. Transport time model810A-D determines a travel time frompickup location802 to first intermediate location806A, from first intermediate location806A to second intermediate location806B, from second intermediate location806B to third intermediate location806C, and from third intermediate location806C todestination location804.
Accordingly, a transporter arrives atpickup location802, receives goods, and departs at first point intime812. The transporter then arrives at first intermediate location806A (e.g., first airport). The goods are tendered until second point intime814. The goods are then transferred via cargo until third point intime816 so that they are ready for transport to second intermediate location806B (e.g., second airport). Thereafter, the goods depart from first intermediate location806A (e.g., second airport) to second intermediate location806B (e.g., third airport).
After arriving at second intermediate location806B (e.g., second airport),route800 has a layover. As such, the goods depart from second intermediate location806B (e.g., second airport) at fourth point intime818 to third intermediate location806C (e.g., third airport). Upon arriving at third intermediate location806C (e.g., third airport), goods are transferred via cargo until fifth point intime820 so that they are ready for pickup by a transporter for delivery todestination location804. The transporter thus arrives at the third intermediate location806C, receives the goods, and departs to thedestination location804 at sixth point oftime822. After arrival atdestination location804, transporter drops off the goods to an authorized individual at seventh point oftime828.
Referring back toFIG. 1, during and/or after the appropriate route from a pickup location to a destination location,transporter application120 receives requests from transporters—viauser devices108A-C—for transporting goods from a pickup location to an intermediate location (e.g., an airport) or a destination location. As such,transporter application120 may provide instructions to transporters viauser devices108A-C during their route, as will be discussed in more detail below. Accordingly, after the submission of an order of goods as described above with respect toFIGS. 1-4,transporter application120 communicates withtransporter module118 to identify an appropriate transporter for transporting goods from the pickup location to the intermediate or destination locations.
Referring now toFIG. 6, to identify the appropriate transporter,transporter module600 further includestransporter submodule616. After users submit orders,transporter submodule616 identifies available transporters within a predetermined distance from the pickup or intermediate, for example, by tracking their location through user devices106A-C (ofFIG. 1). The available transporters may be assigned to another job. In other words, the available transporters may have picked up or be scheduled to pick up goods for another job from a different or same pickup location. Likewise, the available transporters may be scheduled to transport goods for another to a different or same intermediate or destination location.FIG. 9 illustrates exampleavailable transporters906A-C withinpredetermined distance902 from pickup orintermediate location904.
Referring toFIG. 6,transporter submodule616 may then determine if the number of identified available transporter meets or exceeds a predetermined number of available transporters. Transporters may relate to an individual or a carrier. In some embodiments, if the number of identified available transporters does not meet or exceed a predetermined number of drivers,transporter submodule616 may expand the searchable range by a predetermined distance. Alternatively, if the number of identified available transporters does not meet or exceed a predetermined number of available transporters,transporter submodule616 may expand the searchable range until the predetermined number of available transporters is met. The predetermined distance may 5 miles, 10 miles, 19 miles, or 50 miles, to provide a few examples. The predetermined number of available transporters may be 5, 10, 15, or 20, to provide a few examples.
Transporter submodule616 may then identify eligible transporters for transporting the goods from the available transporters. As discussed above, the goods may require special handling by the transporters. For example, the goods may be fragile (e.g., glass) or an organ (e.g., a heart). Further, the goods may be heavy (e.g., furniture) or need refrigeration (e.g., produce and human tissue) and thus require special transportation. Likewise, the goods may be of a certain size (e.g., a car) and thus need a suitable size carrier. As such,transporter submodule616 may ensure that the available transporters have the appropriate certifications and/or are of the appropriate kind of carriers (e.g., a vehicle or a truck). Thus,transporter submodule616 may filter through the available transporters for eligible transporters, for example, those that have the proper certification and/or are of the appropriate type of carriers.Transporter submodule616 may then determine if the number of eligible transporters meets or exceed a predetermined number of eligible transporters. If not, as discussed above, the searchable range is expanded by a predetermined distance or until the predetermined number of eligible transporters is met.
Transporter submodule616 may then determine if the eligible transporters are solicitable. Eligible transporters are solicitable if they are able to transport the good to the pickup location, intermediate location, or destination location by a time specified by model generation module116 (ofFIG. 1) or a user in the request. Further, as mentioned above, eligible transporters may include those transporting or scheduled to transport other orders. Accordingly, these eligible transporters are solicitable if they are, or will be, going to the same pickup location, intermediate location, or destination location. Further, eligible transporters assigned other jobs are solicitable if they can complete transport all jobs by their specified times.
Accordingly, to identify solicitable transporters,transporter submodule616 determines an estimate completion time (ECT) for completing transport of all jobs for each eligible transporter. As such, for an eligible transporter not transporting any other orders,transporter submodule616 determines an ECT for a transporter to pick up and deliver the solicited order. For an eligible transporter transporting other orders,transporter submodule616 determines an ECT for a transporter to pick up the orders from the pickup location and deliver the orders to the intermediate and destination locations in any sequence. To determine the ECT,transporter module610 can utilize a trained transporter model.
To determine the ECT,transporter submodule616 can utilize a trained transporter model. In some embodiments, the trained transporter model can includetransportation submodule604'stransportation time model610 and/or location submodule602'slocation time model608. As discussed above,transportation time model610 determines an estimated amount of time for transporters to transport the goods to the pickup and/or intermediate locations (“an estimated transport time”). Accordingly, as illustrated inFIG. 9, transportation time model610 (ofFIG. 6) may determineparticular routes908A-C for transporters902A-C to travel to pickup location or intermediate location906.Location time model608 determines an estimated amount of time for transporters to tender the goods at pickup and/or intermediate locations (“an estimated tender time”).
In some embodiments,transporter submodule616's trained transporter model can also include transporteracceptance time model618 and transporteracceptance chance model620. Transporteracceptance time model618 predicts an estimated amount of time that it will take a transporter to accept a solicitation for a job (“an estimated transporter acceptance time”). In some embodiments, transporteracceptance time model618 may be based on a predetermined time provided to solicited transporters (e.g., 90 seconds). In some embodiments,transporter acceptance time618 is based on an output provided by transporteracceptance chance model620, which may represent a likelihood of a particular solicitable transporter accepting the job. In some embodiments, solicitationacceptance time model620 may be equal to a predetermined solicit time x (1/a likelihood of solicitable transporter acceptance). In some embodiments, transporteracceptance chance model620 may be trained on historical data of the particular solicitable transporter accepting previous jobs, for example, at certain hours of the day.
Therefore, the ECT may be a total of an estimated tender time, an estimated transport time, and/or an estimated solicitation acceptance time. Along these lines, where the solicitable transporter is scheduled to transport multiple jobs,transporter submodule616 may derive the ECT for completing transport for picking up and delivering orders to the destination or intermediate locations in every possible sequence. After doing so,transporter application120 selects the sequence of events having the least amount of time to represent the time the solicitable transporter may perform the jobs.
For example, if the solicitable transporter was previously assigned “jobA” and is currently being solicited for “jobB,”transporter submodule616 may determine an ECT for each of the following sequences—(i) picking up “jobA,” picking up “jobB,” delivering “jobA,” and delivering “jobB,” (ii) picking up “jobA,” picking up “jobB,” delivering “jobB,” and delivering “jobA,” (iii) picking up “jobA,” delivering “jobA,” picking up “jobB,” and delivering “jobB,” (iv) picking up “jobB,” picking up “jobA,” delivering “jobA,” and delivering “jobB,” (v) picking up “jobB,” picking up “jobA,” delivering “jobB,” and delivering “jobA,” and (vi) picking up “jobB,” delivering “jobB,” picking up “jobA,” and delivering “jobA.” Accordingly, if the ECT for sequences (i), (ii), (iii), (iv), (v), and (vi) is 120 minutes, 170 minutes, 130 minutes, 90 minutes, and 160 minutes, respectively,transporter application120 may select sequence (iii) as representing the transporter for the amount of time it can complete “jobA” and “jobB.”
Along these lines, to compare multiple solicitable transporters previously assigned other jobs,transporter submodule616 may select the solicitable having the shortest ECT for completing the solicited offer. For example, solicitable transporters “X” and “Y” may have been previously assigned “jobA” and “jobB,” respectively, and are currently being solicited “jobC.” As such,transporter submodule616 may determine that transporter “X”'s ECT for completing “jobA” and “jobC” is 120 minutes, and that transporter “Y”'s ECT for completing “jobB” and “jobC” is 180 minutes. In some embodiments,transporter submodule616 may determine that transporter “X”'s and “Y”'s ECT for completing “jobC” is 70 minutes and 90 minutes, respectively. Accordingly, although transporter “X”'s ECT for completing both jobs is shorter than transporter “Y”'s ECT,transporter submodule616 may select transporter “Y” since transporter “Y” ECT for completing the transport of the solicited job—i.e., “jobC”—is shorter. In some embodiments,transporter submodule616 may determine that transporter “X”'s and “Y”'s ECT for completing “jobA” is 120 minutes and 90 minutes, respectively.Transporter submodule616 may also determine that the transporter “X” is to complete “jobA” then “jobB” and that transporter “Y” is to complete “jobB” then “jobA.” Accordingly, although transporter “Y” is to complete “jobB” after a previously assigned order, transporter “Y” may still be selected over transporter “X.”
Along these,transporter submodule616 may consider solicitable transporters previously assigned other orders and solicitable transporters not previously assigned other orders.Transporter submodule616 may then select the solicitable transporter having the least ECT for completing transport of the solicited job as a preferred pickup transporter. For example,transporter submodule616 may consider transporters “A” and “B.” Transporter “A” may have been previously assigned “jobA” and is being solicited for “jobB.” Transporter B is only being solicited for “jobB.” Accordingly,transporter submodule616 may determine that the ECT for transporters “A” and “B” for completing solicited offer “job” is 80 minutes and 100 minutes, respectively. As such,transporter submodule616 may select transporter “A,” although it has been assigned another job (i.e., “jobA”) and may deliver the other before the solicited job (i.e., “jobB”).
Transporter submodule616 may then send a request to the preferred transporter to transport the order. In some embodiments,transporter submodule616 may wait a predetermined amount of time (e.g., 90 seconds) for acceptance. If the solicited transporter does not accept the offer,transporter submodule616 may then restart the process to determine an appropriate transporter (i.e., identify available transporters, identify eligible transporters from the available transporters, etc.). In doing so, the transporter may be considered again for solicitation, albeit the acceptance chance model may derive a lower likelihood of accepting the job based on their lack of acceptance previously, thus being less likely to be solicited again.
FIGS. 10-21 illustrateexample user interfaces1000,1100,1200,1300,1400,1500,1600,1700,1800,1900,2000, and2100 of a transporter application120 (ofFIG. 1), according to some embodiments. Referring now toFIG. 10,user interface1000 may includestatus indicator1002 and/orvehicle type1004.Status indicator1002 may permit a transporter to indicate availability for the transporting of goods. In some embodiments,status indicator1002 may permit date and/or time for which the transporter will be available.Vehicle type1004 may permit a transporter to provide vehicle information for which the transporter will deliver goods. The vehicle information may include a year, a make, a model, and any other type of special handling (e.g., refrigeration).
Referring now toFIG. 11, upon assignment of a particular job to transport goods,user interface1100 may be provided.User interface1100 may receivenotification1102 of solicitation of a job.Notification1102 includes a pickup time and/or date and an option to “view” or “dismiss” the job. If the “view” option is selected, the user approves the job. However, if the “dismiss” option is selected, the user rejects the job.
Referring now toFIGS. 12 and 13, upon viewing (or approving) a particular job,user interfaces1200 and/or1300 may be presented.FIG. 12 illustratesuser interface1200 includingspecial instructions notification1202 of the job. As illustrated,special instructions notification1202 may be provided before viewing of the details of the job, as shown in detail inFIG. 13. As noted above, the special instructions may be provided by a user when submitting a request, or, as will be discussed in more detail below, by an authorized user in processing the request. This confirms that the transporter views the special instructions.
FIG. 13 illustrates user interface1300 providing details of the job for the transporter. User interface1300 includes pick uplocation1302, pick uptime1304,arrival button1306,order number1308,reference number1310,goods information1312,special instructions1314, takephoto option1316, and/ortender information1318. Pick uplocation1302 may be a current location of goods.Pickup time1304 may be a required amount of time for the transporter to arrive atarrival location1302. In some embodiments,pickup time1304 may be based on traffic and available routes received from geographical provider106 (ofFIG. 1). Further,pickup time1304 may be no greater than a predetermined amount of time (e.g., one hour). This may be important for time-critical shipment of goods (e.g., a heart).Arrival button1306 permits transporters to indicate arrival at the pickup location.Order number1608 may an internal number for reference by authorized users and/or for processing by central server102 (ofFIG. 1).Reference number1310 may be an external number for client use.Goods information1312 permits transporters to view data relating to the goods. Good information may include a number of packages, a size of the packages, a weight of the packages, a tracking number, and identification information, to provide a few examples. Takephoto option1316 permits transporters to take photos of goods. Upon receipt of photos,central server102 may determine if the goods are the appropriate goods for transport.Tender information1318 permits transporters to view any information relating to a location for tendering the goods. As illustrated, in some embodiments,tender information1318 may include a tender time and/or location. As noted above, transporters may not be aware of particulars of a job, such as a tender location, until acceptance of the job.
Referring now toFIG. 14, upon arrival to a designated location (e.g., pick up location or intermediate location), prompt1402 may be provided. As such, prompt1402 may be automatically provided uponuser device108A (ofFIG. 1) (e.g., a mobile device) detecting the presence of transporter at the designated location via location tracking oftransporter device108A through transporter application120 (ofFIG. 1). Prompt1402 may confirm that the transporter is at the designated location.
Referring now toFIG. 15, upon selection of arrival button1310 (ofFIG. 13) or confirming arrival via prompt1402 (ofFIG. 14),user interface1500 may be provided. Like user interface1300,user interface1500 providesarrival location1502, pickup time1504,order number1506,reference number1508,goods information1510,special instructions1512, takephoto1514, and/ortender information1516.User interface1500 may also presentnext step option1518 and/or waitingoption1520.Next step option1518 may be selected when the goods are ready for transport and/or received by the transporter. In some embodiments,next step option1518 may not be selected until the transporter application120 (ofFIG. 1) confirms the transporter is at the pickup location. The confirmation may be accomplished by tracking a location of transporter's user device106A (ofFIG. 1) and/or receiving an indication from the designated location.Waiting option1520 may be selected when the goods are not ready for transport.
Referring nowFIG. 16, upon selection of waiting option1520 (ofFIG. 15),user interface1600 is provided.User interface1600 tracks a waiting time1602 at the designated location for the transporter to receive the goods. In some embodiments, when the transporter waits predetermined amounts of time (e.g., fifteen minutes), the transporter is to receive a predetermined additional amount of monies. Likeuser interface1500,user interface1600 may also includearrival location1604,order number1606,reference number1608,goods information1610,special instructions1612, takephoto1614,tender information1616, and/ornext step option1618.
After selectinguser interface1500'snext step option1518 oruser interface1600'swaiting option1618, transporter may be prompted to enter a unique package number (e.g., an order number), take a picture of a code, and/or scanning a code via user device106A (ofFIG. 1). Thereafter, as illustrated inFIG. 17,user interface1700 may provide good information. Upon doing so, central server102 (ofFIG. 1) may verify that the transporter is picking up the correct package. Subsequently, transporter application120 (ofFIG. 1) may require receiving a name and/or signature of an authorized receiver at the pickup location via user device106A.
Referring now toFIG. 18, after the goods are verified,user interface1800 may be provided.User interface1800 may provide information for transporting the picked up goods to the tender location (e.g., an intermediate location or a destination location).User interface1800 may also include tender location1802, transport information1804, cutoff time1806, and/orarrival button1808. Tender location1802 is an intermediate or destination location. When the tender location1802 is an intermediate location, transport information1804 may provide transport information for the transport of the goods from the intermediate location to the next intermediate location or the destination location. For example, as illustrated, transport information1804 may include a flight transporting the goods. Along these lines, cutoff time1806 may be the latest time at tender location1802 for receipt goods. As such, cutoff time1806 may be based on transport information. For example, if a flight is delayed, cutoff time1806 may be adjusted accordingly.Arrival button1808 may provide an indication that the transporter has arrived at the tender location.
Likeuser interface1600,user interface1800 may also includeorder number1810,reference number1812,good information1814, and/or takephoto1816.User interface1800 may further include transport bill example1818. As indicated above, transporters may tender goods to an intermediate location for further transport by a transportation company utilizing a mode of transportation. The intermediate location, the transportation company, or the mode of transportation may require a unique transport bill. For example, Delta Airlines, United Parcel Service, Delta Airlines, and United Airlines may all have different transport bills. As such, transport bill example1818 may assist the transporter in accurately completing unique transport bills at the tender location so that there are no issues in tendering the goods.
Referring now toFIG. 19, upon selection of user arrival button1808 (FIG. 18),user interface1900 may be provided. Likeuser interface1800,user interface1900 may provide information for transporting the picked up goods to the tender location (e.g., an intermediate location or a destination location). As such,user interface1900 may includetender location1902,transport information1904,cutoff time1906,order number1908,reference number1910,good information1912, transport bill example1914, and/or takephoto1916. Further, likeuser interface1800,user interface1900 may providenext step option1918 and/or waitingoption1920.Next step option1918 is to be selected when the goods are received by the tender location. In some embodiments,next step option1918 may not be selected until the transporter application120 (ofFIG. 1) confirms the tender location received the goods.Waiting option1920 is to be selected when the transporter is waiting to tender the goods at the tender location.
Referring againFIG. 16, upon selection of waiting option1918 (ofFIG. 19),user interface1600 is provided.User interface1600 provides a waiting time1602 at the tender location for the transporter to tender the goods. In some embodiments, when the transporter waits predetermined amounts of time (e.g., fifteen minutes), the transporter is to receive a predetermined additional amount of money.
After selectinguser interface1900'snext step option1918 oruser interface1600'snext step option1618, the transporter may be prompted to enter a unique package number (e.g., an order number), take a picture of a code, and/or scanning a code via user device106A (ofFIG. 1). Thereafter, as illustrated inFIG. 17,user interface1700 may provide good information. Upon doing so, central server102 (ofFIG. 1) may verify that the transporter is picking up the correct package. Subsequently, transporter application120 (ofFIG. 1) may require receiving a name and/or signature of an authorized receiver at the pickup location via user device106A.
Referring now toFIG. 20, after verification by the central server102 (ofFIG. 1),user interface2000 may be provided.User interface2000 may include package acceptedbutton2002, unable todelivery button2004, and/or airwaybill example button2006. Upon indicating the package is accepted via package acceptedbutton2002, the transporter may be required to enter an airway bill number and/or provide a picture of the airway bill.
Referring now toFIG. 21, after tendering the package at the tender location,user interface2100 may be provided. User interface may2100 provide a transporter with the reward. As illustrated, the reward may be an amount of money. However, the reward may also be a number of points or any other type of token for service. As such, transporters may not be aware of their reward until after tendering the goods at the tender location or attempting to do so. Further, as explained above, the reward may be based on their weighting times at the pickup location and/or tender location. Further, the reward may be based on a length of the trip, a time duration of the trip, a length of the trip, and/or the importance of the goods. Along these lines, the reward may be reduced if the transporter does not arrive at the pickup and/or dispatch location by the specified time.
Referring back toFIG. 1,transport manager application122 permits authorized users—viauser devices108A-C—to track and/or manage orders for the transport of goods. Accordingly, upon submission of an order as described with respect toFIGS. 2-4,transport manager application122 may receive an order for the transport of goods.Transport manager application122 may assign the order to a predetermined order type based on the type of goods and/or the mode of transportation. For example, some goods require special handling (e.g., refrigeration, chemicals, body parts), whereas other orders may be of a special type (e.g., healthcare orders or medical orders). Accordingly, by assigning the order to an appropriate order type,transport manager application122 may ensure that an appropriate operational team member (e.g., handler)—having the requisite skill and knowledge—to monitor the transport of the order.
In some embodiments,transport manager application122 may assign the appropriate operational team members to the orders. Alternatively,transport manager application122 may allow the appropriate operational team member to select an order to monitor. Along these lines, multiple operational team members may work on orders during transport of the goods from the pickup location to the destination location.
Further, in some embodiments,transport manager application122 may receive preferred routes fromroute generator module116.Transport manager application122 may also permit appropriate operational team members to approve, create, and/or modify determined preferred routes. Further,transport manager application122 may permit appropriate operational team members to assign transporters for the transport of the order. Similarly,transporter manager application122 may permit authorized users to assign tasks to transporters. In doing so,transporter manager application122 may provide transporters an amount of money for completing or attempting to complete the assigned tasks.
Further, to monitor the transport of orders,transport manager application122 may receive updates from the transporters on the status of the transport. In some embodiments,transport manager application122 may receive updates fromtransport provider104 on the delay of scheduled transports (e.g., flights, trains, buses). Likewise, in some embodiments,transport manager application122 may receive updates fromgeographical provider106 relating to drive-only transportation (e.g., traffic, road closure, accidents). Further, in some embodiments,transport manager application122 may receive updates from the transporters—viauser devices108A-C—scheduled to pick up goods from the pickup and/or intermediate locations. For example, the transporters may not have been departed to and/or from the pickup and/or intermediate locations by the designated time. Accordingly, in some embodiments,transport manager application122 may receive updates fromtransport provider104,geographical provider106, and/oruser devices108A-C in real-time.
By operating in such a fashion,transport manager application122 may permit appropriate operational team members to monitor orders during their transport. In doing so, in some embodiments,transport manager application122 may assign scheduled actions to the orders.Transport manager application122 may also receive scheduled actions for the orders from the appropriate operational team members. Scheduled actions may relate to a required operation from a transporter departing to, arriving at, and/or departing from a pickup location, an intermediate location, and/or destination location. As such, in some embodiments, the scheduled actions may relate to a specific time. Accordingly,transport manager application122 may sort the orders based on their upcoming time and assign them a color based thereon (e.g., green, yellow, and red).
FIGS. 22-25 illustrateuser interfaces2200,2300,2400, and2500 provided by transport manager application122 (ofFIG. 1).FIG. 22 illustrates user interface2200 for trackingorders2202 in real-time. User interface2260 providesorder types2204A-J and allows handlers to select and view orders of thedifferent order types2204A-J. Eachorder type2204A-J may require different handling and/or skill. As such, operational teams may be trained to manage and/or handle different groups oforder types2204A-J. As such, operational team members (e.g., handlers) may select or be assigned orders.
As illustrated, order types2204A-J may includeactive orders2204A,ground orders2204B, next flight out (NFO)orders2204C,fright orders2204D,healthcare orders2204E, immediate (STAT)orders2204F, medical collection (MCP) orders2204G, routedorders2204H, escalated orders2204I, and/or will call orders2204J. Allorders2204A may relate all orders currently being processed. As such, allorders2204A includesground orders2204B, NFO orders2204C,fright orders2204D,healthcare orders2204E, STAT orders2204F,MCP orders2204G, routedorders2204H, and/or escalated orders2204I.Ground orders2204B relates to orders of goods being transported by ground. As such,ground order2204B relates to orders of goods whose routes do not have a segment and have a mode of transportation other than ground (e.g., a flight segment).NFO orders2204C relates to orders of goods to be transported by flight and not requiring special handling.Freight orders2204D relate to orders of goods needing special handling. For example,freight orders2204D may be above a predetermined weight (e.g., 100 lbs.), greater than a predetermined dimension (e.g., 5 FT×5 FT×FT), call for a controlled temperature (e.g., less 29° F.), and require secure shipment, to provide a few examples.
Healthcare orders2204E may relate to orders of healthcare goods, which may or may not require special handling.STAT orders2204F may relate to goods to be transported at predefined times (e.g., 8:00 AM and 4:00 PM) and/or places (e.g., hospitals, doctor offices, and pharmacies). MCP orders2202G relate to orders of goods that require skill by transporters. In some embodiments, for example, the packages may contain blood or a bodily tissue. Routedorders2204H relates to orders having predetermined routes required to be followed by transporters. For example, where the transporter has multiple orders and must pickup one order up or drop one order off in a particular sequence, the orders may be considered routedorders2204H. Escalatedorder22041 relates to any order manually escalated by an authorized user. As such, escalatedorder22041 may includeground orders2204B, NFO orders2204C,fright orders2204D,healthcare orders2204E, STAT orders2204F,MCP orders2204G, and/or routedorders2204H. Will call orders2204J may be orders of goods submitted via will call by users, as described above with respect toFIG. 2. Will call orders2204J are notactive orders2204A.
User interface2200 presents allorders2202 categorized under allorders group2204A. For eachorder2202, user interface2200 provideshandler2206,order number2208,status indicator2210,current transporter2212, target location2514, and/or scheduledaction2216.Handler2206 may an individual or member of the appropriate operational team in charge of the order of goods.Order number2208 may be a unique alphanumeric number generated by central server102 (ofFIG. 1) for the order.Status indicator2210 may provide an indication of where the goods are in the route generated bycentral server102. For example, the goods may be at a pickup location, in transport to an intermediate location, at an intermediate location, in transport to a destination location, and/or at a destination location.Current transporter2212 may refer to a specific transporter transporting the good at a particular time. Target location2516 may refer to a current pickup location, intermediate location, or delivery location being traveled to by the transporter currently transporting the good. Scheduledaction2216 may be a follow-up action provided byhandler2206. The follow-up action may specify a desired time to perform the action.
In some embodiments, although not illustrated,orders2202 may be designated a predetermined color based on a transportation status and/or status action. The transportation status may relate to a departure time, pick up time, and/or a tender time. As discussed above, the transporter may be required to depart from their current location or an intermediate location at a specific departure time. Likewise, the transporter may be required to pick up goods at a pickup location at a specific pick up time. Further, the transporter may be required to tender the package at an intermediate location (e.g., an airport) at a specific tender time. As such, theorders2202 may change colors based on the transportation status. In some embodiments, the predetermined colors may be red, yellow, or green. The designated color may be selected based on predetermined rules. For example, an order of goods may be green until reaching a predefined threshold and thereafter change to yellow. Thereafter, after reaching another predefined threshold, the order of goods may change to red. This may allow assigned handlers or other authorized users to track the orders of goods.
Referring now toFIG. 23, after the selection of a particular order2202 (ofFIG. 22) by a handler,user interface2300 may be presented.User interface2300 may include assignedhandler2302,order number2304,order status2306,user information2308, actions required2310,commodity type2312,reference number2314, attacheddocuments2316, and/orgoods information2318.Order status2306 may be updated in real-time and be one of a predetermined number of events, such as those illustrated status indicator2210 (ofFIG. 22).User information2308 may include contact information of a user requesting the transport of goods. Actions required2310 may include actions required by a handler.Commodity type2312 may relate to a good type.Reference number2314 may be a tracking number for a particular package of goods of the order being transported. In some embodiments, an order may include multiple packages having different tracking numbers. Attacheddocuments2316 may be documents relating to the transport of the goods and may be uploaded by the transporter (e.g., airway bill) and/or handler (e.g., airway bill example). As such,user information2308,commodity type2312, and/orgoods information2318 may be provided via a user request at user interface200 (ofFIG. 2).
User interface2300 may also includesegment information2316A-C for segments of a route from a pickup location to a destination location. In some embodiments, as illustrated,segment information2316A relates to picking up the goods,segment information2316B relates to tendering the goods at an intermediate location (e.g., an airport), and/orsegment information2316C relates to delivering the goods to a drop off location. As such,segment information2316A includes transporter information (e.g., a name, a license plate, and/or a type of vehicle), a pickup address, a pickup contact, pickup instructions, a pickup window, and/or assessorials.Segment information2316B includes information of the intermediate location. For example, when the intermediate location is an airport,segment information2316 may include flight information (e.g., departure time, arrival time, departure location, arrival location, and flight number), and airway bills.Segment information2316C includes a transporter delivery address, a delivery contract, delivery instructions, an original quoted delivery time, an updated delivery time, a proof of delivery, and assessorials.
As stated above,segment information2316A and2316C may include transporter information. In some embodiments, as described above, upon submission of orders by users, the central server102 (ofFIG. 1) may automatically select the appropriate transporter.Segment information2316A and2316C may also permit members to manually dispatch transporters2320. As such, referring now toFIG. 24, eligible andineligible transporters2402 may be provided. For eachtransporter2402,user interface2400 may provide a rating, an availability, and/or an estimated time of arrival.
Referring back toFIG. 23, via assessorials,segment information2316A and2316C permits assigned handlers to provide or select tasks (e.g., picking up dry ice for medication and/or printing documents) for transporters of goods. The handlers may reward the transporters for performing the tasking or attempting to do so, for example, by providing them a selected or predetermined amount of money. As explained above, the reward amount may be unknown to the transporter until completion of the transport.
User interface2300 may permit handlers to provides notes2320, digest2322, and/or special operational instructions (SOP)2324. Notes2320 may be provided by handlers for themselves or future handles.Digest2322 may be automatically generated by transport manager application122 (ofFIG. 1) in real-time and may include a particular action and associated time and/or date for the performance of the action. As illustrated inFIG. 25,user interface2500'sdigest2502 may include events performed by transporters (e.g., leaving starting locating, arriving at pick up location, departing pick up location, arriving at tender location, and completing tender) and/or handlers (e.g., uploading tender documents, changing follow-up time, and changing delivery address).SOP2324 may be provided handlers and/or users. As such, notes2320 and/orSOP2324 may be provided and performed by different handlers
FIG. 26 is a flowchart formethod2600 for managing the transport of goods, according to some embodiments.FIG. 27 is a flowchart formethod2700 for transporting a good from a pickup location to a destination location, according to some embodiments.FIG. 28 is a flowchart formethod2800 for identifying an appropriate transporter of a good, according to some embodiments.FIG. 29 is a flowchart formethod2900 for minimizing a risk of a good being delivered past a requested time, according to someembodiments Method2700,2800, and2900, can be performed by processing logic that can comprise hardware (e.g., circuitry, dedicated logic, programmable logic, microcode, etc.), software (e.g., instructions executing on a processing device), or a combination thereof. It is to be appreciated that not all steps may be needed to perform the disclosure provided herein. Further, some of the steps may be performed simultaneously or in a different order than shown inFIGS. 26-29, as will be understood by a person of ordinary skill in the art.
Referring now atFIG. 26,method2600 shall be described with reference toFIGS. 1, 2, 5, 12, and 25. However,method2600 is not limited to that example embodiment.
At2602,central server102 receives a request for transporting a good from a user. The request includes a pickup location (e.g., pickup address206), a destination location (e.g., destination address210), a user preference, and an arrival time preference.
At2604,central server102 determines a preferred route for transport of the good from thepickup location502 to thedestination location504 based on the user preference such that the good arrives at thedestination location504 by arrival time preference. In some embodiments, the preferred route may include one or moreintermediate locations506A-C.
At2606,central server102 dispatchestransporter906A to the pickup the good from a location (e.g., pickup location904).Transporter906A may be selected frommany transporters906A-C based on a quickest arrival time to the good's location. In some embodiments,transporter906A may be further from pickup location1204. In some embodiments,transporter906A may have been previously assigned goods for another order to pick up and/or delivery. As such, in some embodiments,transporter906A may be considered amongother transporters906B and906C not previously assigned goods for other orders to pick up and/or delivery.
At2608,central server102 creates a record of theorder2502 so thatpreselected handlers2206 may track the transport of the good and confirm that the good arrives at the destination location by the arrival time preference. The assigned handler may be selected based on the type of product.
Referring now atFIG. 27,method2700 shall be described with reference toFIGS. 1, 2, and 5. However,method2700 is not limited to that example embodiment.
At2702,user request application114 receives a request for transport of a good from a user. The request includes pickup location (e.g., pickup address204) and destination location (e.g., destination address210). In some embodiments, the request may include a user preference (e.g., a particular airline or mode of transportation) and/or an arrival time preference. Alternatively,central server102 may determine user preference and/or arrival time.
At2704,route generator module116 identifies a first pickup node, a first intermediate node, a second intermediate node, and a delivery node on a pre-generated graph corresponding to thepickup location502, a firstintermediate location506A, a secondintermediate location506B, and thedelivery location504.
At2706,route generator module116 identifies one or more transportation edges relating to a transit cost associated with a corresponding one the pickup location, the first intermediate location, the second intermediate location, and the destination location. As such, each of the plurality of transportation edges corresponds to one of the pickup node, the first intermediate node, the second intermediate node, and the destination node such that each of the pickup node, the first intermediate node, the second intermediate node, and the destination node corresponds to the transit cost.
At2708,route generator module116 calculates a first actual cost for transporting the good frompickup location502 tointermediate location506A based on the user preference and/or the transport data. In some embodiments,route generator module116 calculates a first actual cost for transporting the good from the pickup location to each possibleintermediate location506A-C.
At2710,route generator module116 generates a subgraph of the pre-generated graph including the pickup node, the first intermediate node, the second intermediate node, the destination node, and/or the plurality of transportation edges.
At2712,route generator module116 generates a preferred route from the pickup location to the destination location having a lowest transit cost of transporting the good from the pickup location to the destination location based on the subgraph.
Referring now atFIG. 28,method2800 shall be described with reference toFIGS. 1, 2, and 12. However,method2800 is not limited to that example embodiment.
At2802,transporter module118 receives a request to initiate an auto dispatch process for picking up a good of a order. The request includes the first good, a pickup location (e.g., pickup address204), and a delivery destination (e.g., an intermediate location or destination address210). In some embodiments, the request may include a user preference (e.g., a particular airline or mode of transportation) and/or an arrival time preference. Alternatively,central server102 may determine user preference and/or arrival time.
At2804,transporter module118 identifies first andsecond transporter906A and906B within a predetermined distance frompickup location904 of the good or intermediate locations606A-C during route of the order's good. In some embodiments, second transporter1202A can be transporting a good of another order. Second transporter902A can be in the process of performing another job. For example,second transporter902 can be picking up another order's good the same ordifferent pickup location904/intermediate location606A-C. Second transporter can be transporting the other order's good to the same or different delivery destination (e.g., an intermediate location or destination address210).
At2806,transporter module118 determines that first andsecond transporters906A and906B are eligible for transport based on the good. As discussed above, the goods may require special handling by the transporters. For example, the goods may be fragile (e.g., glass) or an organ (e.g., a heart). Further, the goods may be heavy (e.g., furniture) or need refrigeration (e.g., produce) and thus require special transportation. Likewise, the goods may be of a certain size (e.g., a car) and thus need a suitable size carrier.
At2808,transporter module118 derives an estimated completion time (ECT) for first andsecond transporters906A and906B to transport the first good from the pickup location to the delivery destination. In some embodiments,first transporters906B may have been previously assigned another job (i.e., to pick up deliver goods to the same and/or different locations).
At2810,transporter module118 determines that the first andsecond transporters906A and906B are solicitable based on the ECT for the first andsecond transporters906A and906B.
At2812,transport module118 selects the second transporter1202B based on the ECT of the first andsecond transporters906A and906B. Accordingly, in some embodiments,second transporter1202—previously assigned another job—may be selected overfirst transporter906A—not previously assigned any jobs.
Referring now atFIG. 29,method2900 shall be described with reference toFIGS. 1, 2, and25. However,method2900 is not limited to that example embodiment.
At2902,transport manager application122 receives a request for transport of a good from a user. The request includes pickup location (e.g., pickup address204) and destination location (e.g., destination address210). In some embodiments, the request may include a user preference (e.g., a particular airline or mode of transportation) and/or an arrival time preference. Alternatively,central server102 may determine user preference and/or arrival time.
At2904,transport manager application122 places arecord2502 of the request for transport in a queue. Before doing so,central server102 may derive a preferred route from thepickup address204 todestination address210. In some embodiments, the route
At2906,transport manager application122 assigns the order to handler2506. In some embodiments,transport manager application122 may automatically assign the order to appropriate handler2506 (e.g., an available handler). In some embodiments,transport manager application122 may accept a request from handler2506 and assign it to handler2506.
At2908,transport manager application122 tracks the progress of the transport of the good based on an event time generated from the request or assigned byhandler2206. For example, in some embodiments,transport manager application122 will track transporter progress in departing from their current or pickup location and arriving at an intermediate location or destination location. In some embodiments,transporter manager application122 may provide the progress viauser interface2300's scheduledaction2316.
Various embodiments may be implemented, for example, using one or more well-known computer systems, such ascomputer system3000 shown inFIG. 30. One ormore computer systems3000 may be used, for example, to implement any of the embodiments discussed herein, as well as combinations and sub-combinations thereof.
Computer system3000 may include one or more processors (also called central processing units, or CPUs), such as aprocessor3004.Processor3004 may be connected to a communication infrastructure orbus3006.
Computer system3000 may also include user input/output device(s)3003, such as monitors, keyboards, pointing devices, etc., which may communicate withcommunication infrastructure3006 through user input/output interface(s)3002.
One ormore processors3004 may be a graphics processing unit (GPU). In an embodiment, a GPU may be a processor that is a specialized electronic circuit designed to process mathematically intensive applications. The GPU may have a parallel structure that is efficient for parallel processing of large blocks of data, such as mathematically intensive data common to computer graphics applications, images, videos, etc.
Computer system3000 may also include a main orprimary memory3008, such as random access memory (RAM).Main memory3008 may include one or more levels of cache.Main memory3008 may have stored therein control logic (i.e., computer software) and/or data.
Computer system3000 may also include one or more secondary storage devices ormemory3010.Secondary memory3010 may include, for example, ahard disk drive3012 and/or a removable storage device or drive3014.Removable storage drive3014 may be a floppy disk drive, a magnetic tape drive, a compact disk drive, an optical storage device, tape backup device, and/or any other storage device/drive.
Removable storage drive3014 may interact with aremovable storage unit3018.Removable storage unit3018 may include a computer-usable or readable storage device having stored thereon computer software (control logic) and/or data.Removable storage unit3018 may be a floppy disk, magnetic tape, compact disk, DVD, optical storage disk, and/any other computer data storage device.Removable storage drive3014 may read from and/or write toremovable storage unit3018.
Secondary memory3010 may include other means, devices, components, instrumentalities or other approaches for allowing computer programs and/or other instructions and/or data to be accessed bycomputer system3000. Such means, devices, components, instrumentalities, or other approaches may include, for example, aremovable storage unit3022 and aninterface3020. Examples of theremovable storage unit3022 and theinterface3020 may include a program cartridge and cartridge interface (such as that found in video game devices), a removable memory chip (such as an EPROM or PROM) and associated socket, a memory stick and USB port, a memory card and associated memory card slot, and/or any other removable storage unit and associated interface.
Computer system3000 may further include a communication ornetwork interface3024.Communication interface3024 may enablecomputer system3000 to communicate and interact with any combination of external devices, external networks, external entities, etc. (individually and collectively referenced by reference number3028). For example,communication interface3024 may allowcomputer system3000 to communicate with external orremote devices3028 overcommunications path3026, which may be wired and/or wireless (or a combination thereof), and which may include any combination of LANs, WANs, the Internet, etc. Control logic and/or data may be transmitted to and fromcomputer system3000 viacommunication path3026.
Computer system3000 may also be any of a personal digital assistant (PDA), desktop workstation, laptop or notebook computer, netbook, tablet, smartphone, smartwatch or other wearable, appliance, part of the Internet-of-Things, and/or embedded system, to name a few non-limiting examples, or any combination thereof.
Computer system3000 may be a client or server, accessing or hosting any applications and/or data through any delivery paradigm, including but not limited to remote or distributed cloud computing solutions; local or on-premises software (“on-premise” cloud-based solutions); “as a service” models (e.g., content as a service (CaaS), digital content as a service (DCaaS), software as a service (SaaS), managed software as a service (MSaaS), platform as a service (PaaS), desktop as a service (DaaS), framework as a service (FaaS), backend as a service (BaaS), mobile backend as a service (MBaaS), infrastructure as a service (IaaS), etc.); and/or a hybrid model including any combination of the foregoing examples or other services or delivery paradigms.
Any applicable data structures, file formats, and schemas incomputer system3000 may be derived from standards including but not limited to JavaScript Object Notation (JSON), Extensible Markup Language (XML), Yet Another Markup Language (YAML), Extensible Hypertext Markup Language (XHTML), Wireless Markup Language (WML), MessagePack, XML User Interface Language (XUL), or any other functionally similar representations alone or in combination. Alternatively, proprietary data structures, formats or schemas may be used, either exclusively or in combination with known or open standards.
In some embodiments, a tangible, non-transitory apparatus or article of manufacture comprising a tangible, non-transitory computer useable or readable medium having control logic (software) stored thereon may also be referred to herein as a computer program product or program storage device. This includes, but is not limited to,computer system3000,main memory3008,secondary memory3010, andremovable storage units3018 and3022, as well as tangible articles of manufacture embodying any combination of the foregoing. Such control logic, when executed by one or more data processing devices (such as computer system3000), may cause such data processing devices to operate as described herein.
Based on the teachings contained in this disclosure, it will be apparent to persons skilled in the relevant art(s) how to make and use embodiments of this disclosure using data processing devices, computer systems and/or computer architectures other than that shown inFIG. 30. In particular, embodiments can operate with software, hardware, and/or operating system implementations other than those described herein.
It is to be appreciated that the Detailed Description section, and not any other section, is intended to be used to interpret the claims. Other sections can set forth one or more but not all exemplary embodiments as contemplated by the inventor(s), and thus, are not intended to limit this disclosure or the appended claims in any way.
While this disclosure describes exemplary embodiments for exemplary fields and applications, it should be understood that the disclosure is not limited thereto. Other embodiments and modifications thereto are possible, and are within the scope and spirit of this disclosure. For example, and without limiting the generality of this paragraph, embodiments are not limited to the software, hardware, firmware, and/or entities illustrated in the figures and/or described herein. Further, embodiments (whether or not explicitly described herein) have significant utility to fields and applications beyond the examples described herein.
Embodiments have been described herein with the aid of functional building blocks illustrating the implementation of specified functions and relationships thereof. The boundaries of these functional building blocks have been arbitrarily defined herein for the convenience of the description. Alternate boundaries can be defined as long as the specified functions and relationships (or equivalents thereof) are appropriately performed. Also, alternative embodiments can perform functional blocks, steps, operations, methods, etc. using orderings different than those described herein.
References herein to “one embodiment,” “an embodiment,” “an example embodiment,” or similar phrases, indicate that the embodiment described can include a particular feature, structure, or characteristic, but every embodiment can not necessarily include the particular feature, structure, or characteristic. Moreover, such phrases are not necessarily referring to the same embodiment. Further, when a particular feature, structure, or characteristic is described in connection with an embodiment, it would be within the knowledge of persons skilled in the relevant art(s) to incorporate such feature, structure, or characteristic into other embodiments whether or not explicitly mentioned or described herein. Additionally, some embodiments can be described using the expression “coupled” and “connected” along with their derivatives. These terms are not necessarily intended as synonyms for each other. For example, some embodiments can be described using the terms “connected” and/or “coupled” to indicate that two or more elements are in direct physical or electrical contact with each other. The term “coupled,” however, can also mean that two or more elements are not in direct contact with each other, but yet still co-operate or interact with each other.
The breadth and scope of this disclosure should not be limited by any of the above-described exemplary embodiments but should be defined only in accordance with the following claims and their equivalents.