Systems, devices, and computer-implemented methods for monitoring packages in transit through a logistics network

Abstract

Methods, apparatus, and systems are described for monitoring in-transit parcels in a network to determine which parcels are at risk of being delivered after a specified committed time. In general, parcel fingerprints that define events expected to occur for in-transit parcels and define thresholds for those events are generated from historical data of events occurring in a logistics network for in-transit parcels. These thresholds may be applied in real-time to parcels as events occur for the parcel in transit to determine a risk level for any parcel having an event that occurs after the event thresholds. Attention can be given to parcels that are at a sufficient risk level.

Description

[Technical Field]

[0001] The present disclosure relates generally to systems, devices, computer-readable media, and methods in the field of shipment management and logistics, and more particularly to various aspects relating to systems, devices, computer-readable media, and methods for various enhanced and improved logistics monitoring capabilities to determine packages at risk of being delivered later than a specified committed time.

[0002] (Related Applications) This application claims priority to U.S. Provisional Application No. 63 / 284,615, filed November 30, 2021, entitled "SYSTEMS, APPARATUS, AND COMPUTER-IMPLEMENTED METHODS FOR MONITORING PACKAGES IN TRANSIT THROUGH A LOGISTICS NETWORK," the entire contents of which are incorporated herein by reference. [Background technology]

[0003] Logistics networks transport packages from origin to destination. Large logistics networks can operate on a massive scale, transporting millions of packages from country to country around the world every day. Such large logistics networks can include hundreds of planes, tens of thousands of trucks / vans, and hundreds of thousands of team members. Furthermore, these logistics networks can be highly complex, with day-specific and time-specific packages, different transit days, hundreds of service types, and packages moving via various modes of transportation, such as road, air, and rail. Network operations can vary over time and by day of the week. Additionally, networks can be affected by seasonality, with peak volumes being approximately 1.5 to 2 times higher than non-peak volumes. Furthermore, because new facilities and new transportation legs and modes may be continually added, network plans must continually evolve to adapt to changing volumes and network configurations.

[0004] For a given shipment transported through a logistics network, the purchased service type may specify a committed time for delivery of the shipment from its origin to its destination. Accordingly, a customer may purchase the level of service required for a particular shipment. However, shipments transported through the logistics network may experience delays or other exceptions to the normal transport schedule for various reasons. Weather, traffic, equipment failures, internal network operational errors, etc., may affect the shipment's transport. Therefore, some shipments may be delivered later than the stated committed time.

[0005] While a later-than-expected delivery may be harmless in some circumstances, in other circumstances a later-than-expected delivery may have more serious consequences. Therefore, it is particularly important that awareness of late-delivered packages be available. However, conventional computer systems in logistics networks lack the ability to provide such package-level insight to logistics network operator personnel or customers. Therefore, such determinations may require manual review of potentially hundreds or thousands of in-transit packages at any given time for any large customer. Monitoring in-transit packages to determine which packages may be late to their destination is an enormous and burdensome task requiring significant and expensive personnel and time efforts, which may not result in identifying all packages of interest.

[0006] To address one or more of these issues, more capable and intelligent facility configurations are needed to learn from the network's historical behavior and apply those learnings when monitoring the transportation of packages within logistics networks to identify those packages that are at risk of being delivered later than expected. Summary of the Invention

[0007] In the following description, it will become apparent that certain aspects and embodiments are generally directed to technical solutions for logistics operations, including providing a processing system with the ability to train a model of network operations that specifies thresholds for events that packages are expected to encounter while in transit between an origin and a destination based on an analysis of historical logistics network data. It will also become apparent that certain aspects and embodiments are generally directed to monitoring events for packages related to the specified thresholds to determine which packages are at risk of being delivered later than a specified committed time, thereby enabling at-risk packages to be identified to personnel and / or customers. It should be understood that aspects and embodiments, in their broadest sense, can be practiced without one or more features of these aspects and embodiments. It should be understood that these aspects and embodiments are merely exemplary.

[0008] In one aspect of the present disclosure, a computer system for monitoring the transportation of packages within a logistics network is described. The computer system includes an interface to at least one logistics network data source. The computer system includes a first data storage module including historical network data coupled to the interface, the first data storage module configuring the historical network data from data feeds from the logistics network data source. The computer system includes a second data storage module including package transport model data. The computer system includes a first processing system accessing the data storage module and applying machine learning to the historical network data to train the package transport model data. The first processing system captures data-driven patterns including likely locations of historical events, likely types of historical events, and likely times of historical events. From the data-driven patterns, the first processing system creates a series of predicted events for a virtual package being transported from a first location to a final location through the logistics network, and determines thresholds for each of the predicted events to ensure the virtual package arrives at the final location by a specified time, each threshold associated with the likely time of a predicted event occurring for the virtual package, the predicted events associated with likely locations and likely types. The computer system includes a second processing system coupled to the interface for receiving live data including data regarding actual shipments in transit from the logistics network, the second processing system accessing the transportation model data from the second data storage device, applying the thresholds to the predicted events regarding the actual shipments in transit, and evaluating whether the actual shipments in transit will be delivered to the final location as scheduled for each predicted event based on the application of the thresholds.

[0009] In another aspect of the present disclosure, a computer system for determining a level of risk that a package will be delivered to a final location after a specified time is described. The computer system includes a first processing system that determines a threshold value for each predicted event for the package between a first location and a final location. The computer system includes a second processing system that determines, for each predicted event, whether the event will occur according to the threshold value corresponding to each predicted event during the package's transit. At a point during the package's transit, the second processing system determines a level of risk that the package will be delivered after a specified time based on an amount of delay exceeding the threshold value for a most recent predicted event.

[0010] Another aspect of the present disclosure focuses on a computer-implemented method for determining a level of risk of a package being delivered to a final location after a specified time. The method includes determining a threshold value for each predicted event for the package between a first location and a final location. The method includes determining, for each predicted event, whether the event will occur during the package's transit according to the threshold value corresponding to the predicted event. Additionally, the method includes determining, at a point during the package's transit, a level of risk of the package being delivered after a specified time based on an amount of delay exceeding the threshold value for a most recent predicted event.

[0011] Another aspect of the present disclosure focuses on a computer-implemented method for monitoring the transportation of packages within a logistics network. The method includes applying machine learning to historical network data for the logistics network to train package transportation model data. The machine learning trains the package transportation model data by capturing data-driven patterns including likely locations of historical events, likely types of historical events, and likely times of historical events. From the data-driven patterns, the machine learning trains the package transportation model data by creating a series of predicted events for a virtual package being transported through the logistics network from a first location to a final location and determining thresholds for each of the predicted events for the virtual package to arrive at the final location by a specified time, where each threshold is associated with the likely time of a predicted event occurring for the virtual package and the predicted events are associated with a likely location and a likely type.

[0012] Each of these aspects provides improvements to the art of logistics operations, including monitoring package events as they transit a logistics network to identify packages at risk of being delivered after a specified committed time. Additional advantages of this and other aspects of the disclosed embodiments and examples will be set forth in part in the description that follows, and in part will be obvious from the description, or may be learned by practice of the invention. It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the invention. [Brief explanation of the drawings]

[0013] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate several embodiments in accordance with one or more principles of the invention and, together with the description, serve to explain one or more principles of the invention.

[0014] [Figure 1]FIG. 1 is a diagram of an exemplary logistics network including parcel data collection that may be used for purposes of training a model of logistics network operations and monitoring parcels in real time by applying the model to live parcel data to determine the risk of a parcel in the logistics network being delivered after a specified time, in accordance with an embodiment of the present invention.

[0015] [Figure 2] FIG. 1 is a diagram of an example computer system that may include one or more processing systems that implement one or more modules for training a model of network operations and one or more modules for monitoring packages in real time by applying the model to determine risk.

[0016] [Figure 3] FIG. 1 illustrates three example aspects of package monitoring to detect packages at risk of being delivered after a specified time, including model training, model scoring, and configurable output.

[0017] [Figure 4] FIG. 1 is a flow diagram illustrating an example method for training a model of logistics network operations, including predicted events, thresholds associated with the predicted events, and risks associated with real-time delayed occurrence of the events.

[0018] [Figure 5] FIG. 3 is a diagram of example modules that may be executed by a processing system such as that shown in FIG. 2 to train a model of logistics network operations.

[0019] [Figure 6] 6 is an exemplary histogram illustrating the distribution of lag times for events such as those shown in FIGS. 4 and 5 and illustrating the determination of a threshold for events to be included in a model from the distribution of lag times for events.

[0020] [Figure 7]FIG. 1 is a flow diagram illustrating an example method for determining event thresholds for current predicted events expected to occur for packages being transported within a logistics network.

[0021] [Figure 8A] FIG. 1 is a flow diagram illustrating an example method for determining the location and type of next predicted event that is expected to occur for a package being transported within a logistics network after the occurrence of a corresponding current event. [Figure 8B] FIG. 1 is a flow diagram illustrating an example method for determining the location and type of next predicted event that is expected to occur for a package being transported within a logistics network after the occurrence of a corresponding current event.

[0022] [Figure 9A] FIG. 10 is a flow diagram illustrating an example method for determining values ​​in a risk table that provides the risk associated with the amount of delay for each predicted event. [Figure 9B] FIG. 10 is a flow diagram illustrating an example method for determining values ​​in a risk table that provides the risk associated with the amount of delay for each predicted event.

[0023] [Figure 10] 1 is a flow diagram illustrating an exemplary method for using a model to score risk of a package in relation to a predicted event, including both ex post and ex pre-scoring of risk for the predicted event.

[0024] [Figure 11] FIG. 1 is a flow diagram illustrating an example method for using a model to provide a posteriori scoring of a package's risk relative to the occurrence of a current predicted event.

[0025] [Figure 12] FIG. 10 is a flow diagram illustrating an example method for using a model to provide a proactive scoring of a package's risk relative to the non-occurrence of a next predicted event following the occurrence of a current event.

[0026] [Figure 13] FIG. 10 is a flow diagram illustrating an example method of a risk aggregator aspect of a model for establishing a level of risk for a predictive event in terms of it being the next predictive event that, upon occurrence, becomes the current event.

[0027] [Figure 14] FIG. 1 is a flow diagram illustrating an exemplary method for rerouting shipments according to a level of risk determined by a model.

[0028] [Figure 15] FIG. 1 illustrates an exemplary timeline of events for a package rerouted by level of risk.

[0029] [Figure 16] FIG. 1 is a flow diagram illustrating an example method for determining risk to a package from pre-shipment severity advisories in relation to a predicted transportation route provided by a model.

[0030] [Figure 17] 1 is a screen capture illustrating an exemplary user interface for presenting information about packages in transit within a logistics network, including those at risk of being delivered later than scheduled.

[0031] [Figure 18] 1 is a screen capture illustrating an exemplary user interface for presenting information about a package in transit within a logistics network, including different levels of risk of being delivered later than specified.

[0032] [Figure 19]1 is a screen capture showing an exemplary user interface for presenting information about packages in transit within a logistics network, including where events are occurring that indicate the package is at risk of being delivered later than specified, including filters to control the nature of the information displayed. DETAILED DESCRIPTION OF THE INVENTION

[0033] Reference will now be made in detail to various illustrative embodiments. Wherever possible, the same reference numbers are used in the drawings and the description to refer to the same or like parts. However, those skilled in the art will understand that different embodiments may implement particular parts differently, depending on the needs of the intended deployment and operating environment of each embodiment.

[0034] Generally, various embodiments of systems, devices, computer-readable media, and methods are described below that model logistics network operations in terms of the timing and location of events that packages encounter while in transit within the logistics network. Thresholds are determined for events that a package is likely to experience, and these thresholds provide a way to determine, for each event that a package is likely to encounter while in transit, whether the package is at risk of being delivered after a specified time, such as a commitment time that the recipient expects to meet.

[0035] Those skilled in the art will also appreciate that the embodiments described herein provide improvements to particular technologies, such as systems for monitoring package shipments, logistics operations, and related infrastructure. The embodiments describe specific technical applications that utilize and apply particular embodiments to create a model of logistics network events and use the model to monitor packages in transit through a logistics network to identify packages that are at risk of being delivered after a specified committed time. Monitoring to identify at-risk packages enables relevant actions to be taken not only within the logistics network, but also at the customer level, and the specific technical applications improve or otherwise enhance such technology fields, as described and supported in the disclosure that follows.

[0036] FIG. 1 illustrates a portion of an example logistics network 100 used to transport packages between an origin and a final location, also referred to as a destination. The example logistics network 100 may include any number of facilities. Hubs 102 and 104 are examples of facilities where packages arrive and are sorted for transport to another hub or to a station 106, 108, 110, 112, 114, or 116 associated with the hub. Packages are transported from hubs 102 and 104 to an associated station, where they may be routed to their destination.

[0037] As packages are transported through logistics network 100, they encounter various events from which information about the package is collected by logistics network 100. This data is then collected at a computer system 118, such as one or more server computers that maintain one or more databases of package and event information. These events may be scan events, such as when a barcode, QR code, or similar readable code from a label or from an electronic circuit, such as a radio frequency identification (RFID) tag, located on the package is scanned. These events may also include communications initiated by a transmitter on the package, such as an active RFID tag, a short-range transmitter, or a Bluetooth device, that transmits package information to a receiving device.

[0038] These events may occur at each milestone of the package during its journey. For example, an event may occur when the package is picked up at a remote location; another event may occur when the package arrives at a station; another event may occur when the package passes through a sorting or loading stage within a station; another event may occur when the package departs from a station for a hub; another event may occur when the package arrives at a hub; another event may occur when the package is sorted at the hub, etc. Because each event identifies the package along with the time and location of the event, the location of the package at any time within logistics network 100 is known.

[0039] The specific routes and timings that packages follow during transportation through the logistics network are defined by a plan. A package transportation planning system 120, such as one or more server computers, may determine an appropriate transportation plan for each package, and that data is provided to various facilities, including hubs and stations, so that packages identified at each event can be sorted and loaded to follow the routes described in the plan. The plan may also specify a specific time by which packages should be delivered to their final destinations, along which routes may be selected. However, packages may experience delays and other deviations from the initial plan due to various factors.

[0040] 2 illustrates an example computer system 200 that may be used to model a logistics network based on historical data collected by package data collection system 118. The example computer system 200 may then apply the model to real-time data streaming from logistics network 100 to determine the level of risk of a package being delivered later than a specified time. Computer system 200 may include an interface 202 to data sources in logistics network 100, including data collection 118. Data streaming from logistics network 100 to computer system 200 via package data interface 202 may be prepared and cleansed using typical data cleansing techniques. For example, the data interface may filter out events that may not be relevant to model training or scoring activities.

[0041] The parcel data storage module 204 collects prepared historical network event data for use in subsequent processes for both model training and scoring activities. For model training, the parcel data storage module 204 may provide historical event data of the logistics network 100 to the first processing system 210. For model scoring, the parcel data storage module 204 may provide live data being streamed from the logistics network 100 to the second processing system 218. While the first processing system 210 and the second processing system 218 are shown as separate items in FIG. 2 , it will be understood that these processing systems may be provided by a single computer or a single collection of computers implementing separate functional modules for model training and scoring. Furthermore, when references are made herein to computers, server computers, computer systems, and processing systems, these may include one or more general-purpose programmable processors, one or more application-specific processors, hardwired digital logic, and / or various combinations of such devices.

[0042] The first processing system 210 may perform operations to train a model representing events occurring within the logistics network 100 from historical event data captured from the logistics network 100 over a predetermined period of time. Additionally, the first processing system 210 may repeatedly perform model training to account for new aspects of the logistics network 100 that may arise over time. For example, new events may be introduced into a set of existing facilities, and these new events are captured in the historical data maintained in the package data storage device 204 so that the first processing system 210 may continue to train the model to incorporate the new events. Additionally, the addition of a new facility may introduce new events into the historical data maintained in the package data storage device 204 so that the first processing system 210 may continue to train the model to incorporate new events corresponding to the new facility. In this manner, the computer system 200 maintains a model of the network 100 that is up-to-date, allowing the model to adapt to the logistics network 100 and thereby allowing real-time application of the model for scoring to account for the evolving network 100.

[0043] Furthermore, computer system 200 is not limited to a single logistics network 100 or operator of logistics network 100. Computer system 200, particularly first processing system 210, may incorporate different networks when training the model, regardless of operator, as long as historical event data from these additional networks is available. Additionally, computer system 200, particularly second processing system 218, may score the model against shipments in different networks as long as streaming live event data from the different networks is available.

[0044] Focusing on the first processing system 210, the exemplary computer system 200 includes two subsystems that provide machine learning for training the model. The first subsystem 212 implements machine learning from captured historical event data to perform baggage fingerprint calculations to create baggage fingerprints that define the model. A baggage fingerprint describes events that a baggage is expected to encounter during its transit from a specific first location, such as the baggage's origin location, to a specific final location, such as the baggage's destination location. The events captured from the network that make up the historical data and the events inherent in the baggage fingerprint are identified as having several characteristics. For example, an event may be identified as having three characteristics: the location where the event occurs, the type of event that occurs, and the time at which the event occurs.

[0045] The time included in the package fingerprint of the model specified for an event is the latest time the event should occur for a virtual package to be delivered on time to its final location by a specified time. This time of the event in the model is therefore referred to as the package threshold. This package threshold is determined by machine learning from historical data, where events of a given location and a given type represented in the historical data typically occur over a specified range of times. Examples of the machine learning operations of the first subsystem 212 that generate thresholds are described in more detail below with reference to Figures 4 through 8B.

[0046] The first processing system 210 stores the luggage fingerprints for all known luggage events determined by machine learning from historical data and modeling as luggage transportation model data in a luggage fingerprint storage module 216, which may be a database. The luggage fingerprint data can then be made available from the luggage fingerprint storage module 216 to other subsystems of the first processing system 210, including a second subsystem 214 for luggage risk table calculation. The luggage fingerprint data is used by the second subsystem 214 to determine, for each predicted event in the luggage fingerprint for a virtual luggage, the level of risk of the virtual luggage being delivered to a particular final location for different amounts of delay beyond a luggage threshold. The determination of the risk table entries in the second subsystem 214 is described in more detail below in conjunction with Figures 9A and 9B.

[0047] The risk table of second subsystem 214 and the package fingerprints from first subsystem 212 and storage device 216 are made available to second processing system 218 for model scoring on real-time package data. Second processing system 218 also receives live data streaming from logistics network 100 to apply package thresholds when using model scoring to determine, in real time, the amount of delay of a predicted event that exceeds the package threshold for a physical package. Upon determining the amount of delay, if any, that a physical package experienced for a particular predicted event, second processing system 218 can determine a corresponding risk level for the package to be delivered to its final location after a specified time. Determining risk levels for physical packages in transit is described in more detail below in connection with Figures 10 through 13.

[0048] In addition to determining risk based on the risk table from second subsystem 214, second processing system 218 may also receive risk information regarding external factors that result in adverse conditions for transporting a package. External sources 206 of data related to such external factors may stream data to computer system 200, and more specifically, to external factors / risk storage device 208 and second processing system 218. For example, external factors may include weather, traffic, power outages, etc., which may result in predictable delays before a package is transported from one location to another, rather than being determined solely in relation to package thresholds for the event. Second processing system 218 performs such advance prediction of delay risk by having a predicted path from the package's fingerprint and then assessing the predicted delay risk for each leg of the package's expected journey. Determining risk from external sources is described in more detail below in connection with FIG. 16.

[0049] Once a risk level is assessed for a physical package in transit within logistics network 100, information regarding the package and the risk level is made available to downstream consumers. Alerts may be generated immediately from second processing system 218 to draw attention to specific situations regarding missed packages or packages with significant risk levels. Furthermore, information regarding the package and risk level may be provided to another storage device 220, which maintains an up-to-date risk assessment for each physical package currently in transit within logistics network 100. Additionally, one or more third processing systems 222, 224 may access the information and provide it to one or more entities via user applications. For example, one system 222 may function as a web server and provide information to customers expecting to receive their packages via a data feed to a dedicated application or a website accessed by the customer over the Internet. Another system 224 may provide information to personnel at shipping entities operating logistics network 100.

[0050] A person viewing information provided by system 222 or 224 as a display on a device may be able to quickly see which packages are at risk of being delivered after a specified time. Thus, the person does not need to sift through information about every package they want to monitor for on-time delivery, since only packages at risk of being delivered after a specified time require attention. Additionally, the person may be provided with additional options, including the ability to view package-specific information about packages at risk of being delivered after a specified time. Personnel at the shipping entity may be provided with additional features, including the ability to filter information about any package in logistics network 100, such as by customer, and identify specific facilities, days of the week, etc., within logistics network 100 where a package is at risk, in order to further identify potential points of failure within the network. Screen captures of examples of such user interfaces are described in more detail below with reference to Figures 17-19.

[0051] In addition to displaying information about packages at risk of being delivered after a predetermined time for delivery, information about the packages at risk may be shared with a fourth processing system 226 that executes package transportation planning for the logistics network. The fourth processing system 226 may be a subsystem of the package transportation planning system 120, which determines the actual route through the logistics network 100 that a package will take to be delivered to its final location. Thus, at any given facility along the package's intended route, the fourth processing system 226 may determine that a better route is available to increase the likelihood that the package will be delivered by the specified time. Once the package takes a new route, the second processing system 218 may use events occurring along the new route to determine the level of risk, thereby providing a closed-loop system between the fourth processing system 226 for package transportation planning and the second processing system 218 for risk determination via model scoring.

[0052] For example, during a package's pre-shipment phase, an external factor, such as a forecast of severe weather at a facility at the time the package is expected to arrive at or depart from the facility, may indicate a risk to the package that triggers fourth processing system 226 to create a new plan to route the package through a different facility. Similarly, a level of risk determined as a result of a package threshold being violated during transportation may trigger fourth processing system 226 to create a new plan to route the package through a different facility to reduce the amount of delay associated with a subsequent event the package encounters. In either case, second processing system 218 assesses the risk of the package being delivered to its final location, and that risk information is provided as feedback to fourth processing system 226.

[0053] FIG. 3 illustrates a functional overview 300 of computer system 200. Here, it can be seen that model training from historical event data captured from logistics network 100 occurs in overview step 302. This relates to the operation of first processing system 210, where package fingerprints containing predicted events and corresponding package thresholds for each event are determined, along with associated risk levels for different amounts of delay relative to the package thresholds. Model scoring then occurs in overview step 304, where it relates to the operation of second processing system 218, where it compares package fingerprint package thresholds to current events after they occur, and to compare package thresholds to upcoming predicted events while waiting for them to occur. The determined risk levels, and missed event exceptions, as a whole, can then be provided to downstream consumers via configurable outputs on a displayed user interface in overview step 306.

[0054] FIG. 4 is a flow diagram of machine learning steps 400 that may be performed by the first processing system 210 for model training. First, in step 402, the first processing system 210 extracts historical data including the event type, event time, and event location of packages delivered over a specific time frame. The event type may identify whether the event is a pickup, arrival, departure, delivery, etc. The event time may identify the time and day of the week. The event location may identify the location where the event occurs, including any facility in the logistics network 100 or any other location where the event occurs. Next, in step 404, a first module (Module 1) implemented by the first processing system 210 calculates the slack time for all events and categorizes the slack time into slack time bins. The slack time is the amount of time between the time of the event and a specified time, which is the latest time a delivery should occur for it to be considered on time. Categorizing the slack time of events into slack time bins effectively constructs a histogram, an example of which is described in more detail below with reference to FIGS. 5 and 6.

[0055] Once all event slack times from the historical data have been classified, the first portion of the second module (Module 2.1) determines a threshold value for each current predicted event of the virtual package in step 406. The threshold value for each current predicted event is determined by calculating a desired percentile of all slack times specific to on-time packages relative to the location of the current predicted event. For this current predicted event of the virtual package, the virtual package has a final destination, is shipped with a specific product type, and has a specified committed time for delivery on a specific day of the week. The product type is related to the level of service offered for transporting the virtual package, such as ground service, next-day service, or international service. Thus, each threshold value determined in step 406 is associated with a current predicted event of a virtual package having these characteristics, thereby enabling appropriate selection of the current predicted event for inclusion in the package fingerprint of a real package having the same characteristics as the virtual package. An example of the sequence of substeps taken to determine the threshold value as in step 406 is described in more detail below with reference to FIG. 7.

[0056] Once the baggage thresholds have been determined for all possible current predicted events in the network, the second portion of the second module (Module 2.2) determines the location and type of the next predicted event following the particular current event in step 408. To determine the location and type of the next predicted event following the particular current event, the thresholds of all possible next predicted events following the particular current event are determined using a histogram of the leading times of the possible next predicted events following the particular current event, again using a desired percentile to determine the threshold of the potential next event. The potential next event with the slowest threshold is selected as the location and type of the next predicted event for the baggage fingerprint. An example sequence of substeps performed to determine the location and type of the next predicted event in step 408 is described in more detail below with reference to Figures 8A and 8B.

[0057] Once all next predicted events have been determined, the third portion of the second module (Module 2.3) combines the outputs of Modules 2.1 and 2.2 in step 410. Thus, for a given current predicted event for a given virtual load with a determined threshold, Module 2.3 combines the appropriate next predicted event location and type and the next predicted event threshold determined in Module 2.1. The threshold used with the next predicted event selected by Module 2.2 is not the threshold determined by Module 2.2, but rather the threshold calculated for the location and type of that next predicted event if that location and type were considered the current predicted event in Module 2.1. This removes the dependency on the current predicted event preceding the next predicted event when determining the threshold for that next predicted event by using the output of Module 2.1 as the threshold for each next predicted event. This is related to the post-event scoring of the current event and the pre-event scoring of the next event, and is discussed below in connection with Figures 10-13. An example output of Module 2.3, which combines the current predicted event from Module 2.1 with the next predicted event from Module 2.2, is shown in Table 1 immediately below. Table 1: [Table 1]

[0058] This luggage fingerprint of the virtual luggage shows that each predicted current event has a threshold T_1 (specified in minutes until the commit time) determined in step 406 of module 2.1. Each next predicted event following the current predicted event has a threshold T_2 (specified in minutes until the commit time). However, each next predicted event is further seen to be followed by the same event, but this time as the current predicted event. In other words, when the next predicted event actually occurs, it becomes the current predicted event. Thus, T_2 of the next predicted event following one current predicted event is equal to T_1 of the next current predicted event.

[0059] As a specific example of the package fingerprint shown in Table 1 above, for carrier entity FX, the first current predicted event occurs at facility ABEA of type PU (i.e., a pickup event), where the package is destined for a delivery address associated with facility CHIA. Service description code D indicates a domestic delivery service, service code 3 indicates a two-day delivery, and the day of the week (dow) indicates a Wednesday delivery date. The threshold T_1 for the first current predicted event is 2835, meaning that the pickup is expected to occur 2835 minutes before the specified delivery time for the purchased service type. The next event expected to follow the current predicted event occurs at facility EWRHB as an arrival (AR), as determined by module 2.2, which searches for all possible next events following the current event for the predicted ABEA PU. The threshold T_2 for this next predicted event is 1890 minutes before the specified delivery time, and it was not found by module 2.2 due to this T_2 value. The current predicted event following the next predicted event is EWRHB arrival, and its threshold T_1 is 1890, which is exactly the same as the T_2 value of the preceding next predicted event. Module 2.1 required the threshold T_1 to be 1890 when evaluating the EWRHB arrival event as the current event. Module 2.3 used the T_1 value of the threshold of the current predicted event for EWRHB, 1890, as the T_2 value of the threshold of the next predicted event for EWRHB, eliminating the dependency of the T_2 EWRHB threshold on the previous ABEA PU event.

[0060] An additional module, part 2.4, may be used in combination with the output of module 2.3 to append the destination time zone name, as shown in Table 1. This allows for subsequent adjustment of the time to a common frame of reference, such as Coordinated Universal Time (UTC), based on the time zone that applies to the location of each predicted event. This simplifies the application of thresholds as events may span from one time zone to the next.

[0061] Once package fingerprint information is complete for all predicted events that may occur within logistics network 100, a risk dimension table is created for all predicted events in step 412. This is done by calculating the risk of delivery delay for each time range in which the event may occur beyond the event threshold. For example, the range may be one hour, so that a risk level is calculated for each time the event occurs after the threshold from the package fingerprint. Risk is specific to the predicted event and virtual package characteristics, including event location, event type, product or service type, number of days until commitment time, day of the week for the commitment time, etc.

[0062] FIG. 5 illustrates a set of components used in the flow of FIG. 4 to determine the current predicted event, the next predicted event, and respective thresholds for the event location, event type, product or service type, days until commit time, and day of the week for the commit time. Module 1, described above with respect to step 404 of FIG. 4, utilizes inputs 502 including the event type, domestic versus international service type, the country code of the country the package is being transported to, the carrier code identifying the carrier of any particular package, and the delivery date range for determining the slack time such that the slack time binned is the correct slack time for a particular virtual package with predetermined characteristics. Module 1 operation 504 accesses historical package event data 506 to calculate the slack time distribution for each possible event within logistics network 100. Module 1 output 508 includes the slack times in bins to establish a slack time distribution that can be represented in histogram form 600, as shown in FIG. 6. In the example of FIG. 6, it can be seen that histogram 600 includes slack times binned into 15-minute intervals. While other intervals may be selected, it has been found that 15-minute intervals provide sufficient resolution for determining effective thresholds.

[0063] This output of Module 1 is then provided to Module 2 along with Module 2 input 512, which includes percentile numbers, minimum flow volume percent, and a predefined time commitment date range for delivery. Module 2 operation determines package fingerprint events, including the current predicted event and the next predicted event, and thresholds for each event, as described in steps 406, 408, and 410 of Figure 4. The output of Module 2 is placed in storage 510 and includes a package fingerprint component that includes all predicted events and corresponding thresholds, similar to those shown in Table 1 for a given virtual package.

[0064] Returning to FIG. 6, histogram 600 further illustrates how module 2.1 determines a threshold for a given current event. In this example, the event is an outbound scan from a hub of a package destined for a particular final location. A threshold is then determined using a desired percentile of slack time. In this example, the desired percentile, designated 606, is the 99th percentile, which has been shown to provide an effective threshold for determining the risk of package delay. In this example, the 99th percentile of observed on-time scans is 12:15 AM on the commit date for delivery. Therefore, packages leaving this particular hub after 12:15 AM on the commit date and destined for this particular final location are estimated to be at a level of risk of being delivered after the commit date. In this manner, packages with slack time in bins in region 602 are estimated to be on time with no level of risk, while packages with slack time in bins in region 604 are estimated to be at risk of delivery delay.

[0065] FIG. 7 is a flow diagram illustrating example steps 700 that may be followed when performing the functionality of Module 2.1 to determine a current predictive event threshold for a package fingerprint. Module 2.1 begins at step 702, where Module 2.1 reads an input parameter as the percentile number at which the event fingerprint threshold is selected. As described above for the example shown in FIG. 6, the percentile was 99. The current predictive event slack distribution provided for the histogram is read as input at step 704 from the database storing the histogram, e.g., a Hive table if Apache Hive is being used. At step 706, the bin code columns are extracted for event location, ship-to location, event type, shipping service type, shipment commit day of the week, and event slack bin number. At step 708, if the bin time code is negative, a flag is generated. Next, at step 710, the total frequency of each of the event location, ship-to location, event type, shipping service type, shipment commit day of the week, and event slack bin number for non-negative bin time codes is calculated.

[0066] At this point, a set of steps 712 is performed for each unique combination of event location, ship-to location, event type, shipping service type, and shipping day of the week. In a first step 714 of the set of steps 712, the events are sorted in ascending order by bin time end. In step 716 of the set of steps 712, a cumulative frequency (CF) is calculated, and in step 718 of the set 712, a total frequency (TF) is calculated. Next, in step 720 of the set of steps 712, a cumulative percentage (CP) is calculated as CP = CF / TF. In step 722 of the set of steps 712, rows with an associated CP of at least 1-percentile number (e.g., 99) / 100 are selected. Next, in step 724, row numbers are assigned in ascending order of bin time end, and a row with a row number equal to 1 is selected as the fingerprint threshold for the current predicted event. Here, the current predicted event is defined as a unique combination of event location, ship-to location, event type, shipping service type, and shipping commit day of the week. Next, in step 726, the current predicted events associated with each selected fingerprint threshold are written to a threshold data frame, completing module 2.1.

[0067] 8A-8B are flow diagrams illustrating example steps 800 that may be followed when performing the functionality of module 2.2 to determine the next predicted event location and type for a baggage fingerprint for a given current predicted event determined in module 2.1. First, in step 802, an input parameter is read as the desired percentile number of observed on-time scans. This may be the same percentile (e.g., 99) used in module 2.1, or it may be different because this threshold is used as a test for determining the next event in the most recent next predicted event after the given current event, but is not used as a threshold for the next predicted event in the baggage fingerprint. Next, in step 804, another input parameter is read as the desired minimum percentage of all historical next events required for the next predicted event to be a valid next predicted event. This minimum percentage represents a minimum flow volume for a potential predicted event, allowing next predicted events with very low occurrence volume to be filtered from the pool of potential next events for the given current event. A useful minimum percentage for such filtering has been found to be 10%, although other minimum percentages are also applicable.

[0068] Once the input parameters are read, in step 806, margin histogram data for each potential next event for a given current forecast event is read as input from a database that stores histograms, e.g., a Hive table if Apache Hive is used. This allows the bin code columns to be extracted into event location, ship-to location, event type, ship service type, ship commit day of week, next event location, next event type, and next bin time code in step 808. In step 810, a flag is created if the bin time code is negative; otherwise, a bin time end is created from the number in the next bin time code. Next, in step 812, the total frequency of each of the event location, ship-to location, event type, ship service type, ship commit day of week, next event location, next event type, and next bin time code if the bin time code is non-negative is calculated.

[0069] At this point, a series of steps 814 is performed for each unique combination of event location, ship-to location, event type, shipping service type, shipment commit day, next event location, and next event type. In the first step 816 of the series of steps 814, the events are sorted in ascending order by bin time end. In step 818 of the series of steps 814, a cumulative frequency (CF) is calculated, and in step 820 of the set 814, a first total frequency (TF1) is calculated. Next, in step 822 of the series of steps 814, a cumulative percentage (CP) is calculated as CP = CF / TF1. In step 824 of the series of steps 814, rows with an associated CP of at least 1-percentile (e.g., 99) / 100 are selected. Next, in step 826, row numbers are assigned in ascending order of bin time end, and rows with row numbers equal to 1 are selected.

[0070] Once a row equal to 1 is selected for each unique combination, a series of steps 828 is performed for each unique combination of event location, ship-to location, event type, shipping service type, and ship-commit day of the week. In step 830, the first of the series of steps 828, a second total frequency (TF2) is calculated. Next, a series of steps 832 nested within the series of steps 828 is performed for each unique combination of event location, ship-to location, event type, shipping service type, ship-commit day of the week, next event location, and next event type. In step 834, a distribution percentage (DP) is calculated as DP = TF1 / TF2. In step 836 of set 832, rows with an associated DP of at least a minimum percentage (e.g., 10) / 100 are selected, thereby retaining only potential next events that meet this minimum flow volume. Next, in step 838, row numbers are assigned in ascending order of bin time end, and the row with a row number equal to 1 is selected as the next predicted event type and location. Here, the next predicted event for each current predicted event is defined as the unique combination of the event location, destination location, event type, shipping service type, and shipment commit day of the week corresponding to the associated previous current predicted event. In step 840, this next predicted event type and location are written as output to the next event data frame. As previously mentioned, the parcel threshold used in the parcel fingerprint of the next predicted event is determined separately by module 2.1, where the next predicted event is considered the current predicted event. Module 2.3 combines the outputs of modules 2.1 and 2.2 to generate a parcel fingerprint such as that shown in Table 1. Here, the threshold T_2 of the next predicted event is the same as T_1 for the current predicted event following the predicted event, because the next predicted event (T_2) is the same predicted event monitored during pre-event scoring and the next current event (T_1) is the same predicted event monitored during post-event scoring.

[0071] A specific example of how Module 2.2 determines the next predicted event location and type is as follows: A historical current event that occurred at a DENR event location of type Departure has three potential next locations and event types in the historical data. For each of the three potential next locations and event types, a 99th percentile threshold time and sample size are determined. For example, an Arrival event type at an ORDR event location occurs 5% of the time, with a 99th percentile threshold for this pair of events of 10 / 1 / 19 5:30. An Arrival event type at an INDH event location and an Arrival event type at a MEMH event location occur 45% and 50% of the time, respectively, with a 99th percentile threshold of 10 / 1 / 19 1:45 and 10 / 1 / 19 00:00, respectively. Given this information, the Arrival event type at the INDH event location is selected as the next predicted event type and location for the current event of Departure from DENR. This is because the next predicted event location and type has a sample size greater than 10%, and its 99th percentile threshold is the most recent among those with a sample size greater than 10%.

[0072] 9A and 9B are a flow diagram illustrating example steps 900 that may be followed when performing the functions of the package risk table calculation subsystem 214 of the first processing system 210. In a first step 902, input parameters are read as the start and end shipping dates of packages from historical data. Next, in step 904, historical event data for packages with shipping dates within the start and end shipping dates is read as further input. In step 906, the service type, commit day, and service result (delivered on time or delayed by a specified amount of time) are extracted from each package's historical data. In step 908, an event array is expanded for the extracted information. Next, in step 910, the data is filtered to retain only fingerprint-eligible events. For example, any events unrelated to the predicted events for the logistics network 100 used in the package fingerprint are removed.

[0073] Once the historical event data has been filtered, it is ready to be applied to determine the risk level of a package being delivered after a specified time based on the length of delay exceeding the package fingerprint threshold for each predicted event. In step 912, for each event for each package from the historical data, the event type, event location, and number of days from the event time to the commit date are determined, with the maximum value being specific to each service type. For example, an express service type has a maximum of three days, and a ground service type has a maximum of seven days. In step 914, for each event for each historical package, the corresponding package fingerprint threshold is obtained. Next, in step 916, it is determined whether any of the package's historical events violate the package fingerprint threshold.

[0074] At this point, the amount of delay for each historical event for each package determined in step 916 can be calculated in step 918 by determining the difference between the actual event time and the fingerprint threshold, up to a desired maximum value. For example, the maximum delay may be limited to a level such as 10 hours, where the risk level of a package being delayed is already considered very high. In this example, the amount of delay is calculated in hours, but it will be understood that other time units can also be used as the basis for the determination, depending on the desired level of granularity. In step 920, for each historical event that has a fingerprint threshold violation, the fingerprint violation counter assigned to the set of matching events to which the event with the threshold violation belongs is incremented by one. Thus, the result of step 920 is an aggregation of threshold violations for each particular set of matching events.

[0075] In step 922, for each historical event that has a fingerprint threshold violation and has a delivery that was delayed because it occurred after a specified time, such as the commit time, a late delivery counter assigned to the set of matching events to which the event with the threshold violation and late delivery belongs is incremented by one. The result of step 922 is therefore a count of late deliveries for each particular set of matching events. For each of these sets of matching events, a level of risk may be calculated by dividing the value of the late counter by the value of the violation counter. Thus, the output of step 924 is a value between 0 and 1 to set the level of risk. If the output is desired to be expressed as a percentage, this value may be multiplied by 100. The output is then written to a risk table in step 926.

[0076] An example risk table is shown below in Table 2 for an arrival (AR) event type at event location MEMH. This illustrates that there may be delay amounts not shown in the historical event data. For example, delays of 1, 2, 3, and 6 hours are not represented in the historical data. However, these delay amounts may occur in the future. Therefore, it may be appropriate to interpolate to determine the risk amount for such missed delay amounts. A risk table including such interpolation is shown below in Table 3. As historical data continues to be captured, the process of creating the risk table may be continually performed by the first processing system 210, so that the interpolated delay amounts may eventually be replaced with the delay amounts occurring in the historical data. Table 2 (without interpolation): [Table 2] Table 3 (after interpolation): [Table 3]

[0077] The operation of the first processing system 210 to create a model defined by the package fingerprint and associated risk table is described above, and the second processing system 218 may score the model against real-time data of a physical package in transit within the logistics network 100 to determine a level of risk for each predicted event, both reactively and proactively. FIG. 10 is a flow diagram of an example method 1000 for scoring a model against real-time event data of a physical package in transit. In step 1002, real-time live event data streaming for a physical package in transit is received by the second processing system 218. At this point, proactive scoring for the next predicted event from the package fingerprint is canceled by the occurrence of the current predicted event corresponding to the event data just received in step 1002. In step 1006, the new current event is scored against the model by comparing the current predicted event that just occurred for the physical package with a threshold value for the current predicted event that matches the current event that actually occurred for the physical package, and determining the amount of delay (if any) for the occurrence of the event that exceeds the threshold. This delay amount may then be determined for the predicted event in the risk table that matches the current event to reveal the corresponding level of risk specified in the risk table, which may then be made available to downstream processes.

[0078] Once the level of risk of the current event to the actual package has been determined, proactive scoring may be scheduled for the next predictive event defined for the current event in the package fingerprint in step 1008. However, if the current event is of a delivery type, delivery has occurred and the process may end. If the current event is not of a delivery type, i.e., the package is still in transit, proactive scoring is scheduled and begins occurring at the time period specified by the schedule in step 1008. For example, proactive scoring may be scheduled to run every 15 minutes. It will be appreciated that the schedule need not be every 15 minutes, in which case the amount of time may be selected as a balance between the resolution of the proactive score and the amount of processing required by the second processing system 218, given the potentially large scale of the logistics network 100 and the sheer number of actual packages in transit at any given time that are scored against the model. Once a threshold for the next predicted event to be scored has been reached, a level of risk is assigned. The scheduled proactive scoring may then continue to periodically update the risk level based on increasing delays beyond the threshold. If a new occurrence of an event occurs for the package, the flow of the example method 1000 returns to step 1002 .

[0079] Because proactive scoring is looking for a package for which the next predicted event has not yet occurred, it is not yet possible to score that event as a current event. This allows proactive scoring in step 1008 to determine the risk for the next predicted event before it actually occurs in network 100, rather than determining the risk only after the event has occurred via reactive scoring in step 1006. When proactive risk assessment is performed at a scheduled time, risk aggregation may be used in conjunction with the most recent proactive score and the current proactive score to determine whether the risk from the most recent proactive score or the risk from the existing proactive score is used as the package's risk level at that time. However, once the next predicted event actually occurs and becomes a current event that is proactively scored, the risk from that proactive score becomes the package's risk level. An example of the reactive scoring step is described below in conjunction with FIG. 11, and an example of the proactive scoring step is described below in conjunction with FIG. 12.

[0080] FIG. 11 is a flow diagram illustrating example steps 1100 that may be followed when executing the reactive scoring function of the second processing system 218. In step 1102, the flow begins by reading streamed events from event locations in the logistics network 100 directed to the second processing system 218. The streamed events may identify the package, origin, final location, a predetermined time for delivery known as the service commit, product / service type, and delivery day. In step 1104, the events are organized into the specific data processing format required and cleansed to filter out events that are not relevant for scoring or are otherwise out of scope. In step 1106, any scheduled proactive scoring activity for this package is deactivated because a reactive scorable event has occurred.

[0081] In step 1108, a determination is made as to whether the time of the event has already passed the service commit. If yes, the package is already late, and therefore the risk of the package being late is 1 or 100%, and post-hoc scoring ends. If the time of the current event has not yet passed the service commit, in step 1112, a current predicted event fingerprint threshold corresponding to the actual current event streaming from logistics network 100 is obtained and applied to the time of the event. The amount of delay of the actual event relative to the current predicted event cutoff time indicated by the threshold is determined, and in step 1114, a determination is made as to whether there is a delay relative to the threshold cutoff time.

[0082] If there are no delays exceeding the threshold, the package is on track for delivery by service commitment. Therefore, a risk score of 0 is assigned in step 116. If there is a delay amount between the occurrence of the actual current event versus the threshold for the matching current predicted event from the package fingerprint, then in step 1118, the level of risk is retrieved from the risk table and this level of risk is assigned as the package's risk score. After risk scoring is completed in either step 1116 or 1118, proactive scoring is scheduled to activate for the next predicted event for the package fingerprint in step 1120. The reactive scoring process for this current event is then completed, and reactive scoring becomes idle until the next event is streamed from a location in logistics network 100.

[0083] One scenario that may occur during reactive scoring is that an actual current event occurring in logistics network 100 may not match the current predicted event from the package fingerprint. In other words, transportation planning may have sent the package to a different facility than predicted by the package fingerprint. This may be the result of normal business operations, such as load balancing along the logistics network's route, and / or the application of pre-shipment risk analysis that caused an unexpected route through the logistics network to be selected. However, when a current event occurs within the network, reactive scoring obtains a threshold value associated with the actual current event from the package fingerprint information available for logistics network 100 and then proceeds from that current event so that reactive and proactive scoring can continue based on the next predicted event and the current predicted event from the actual current event until the final destination is reached. Because the next predicted event may later differ based on the actual current location from the next predicted event that was based on the location of the current predicted event, the fingerprint may differ from what was initially predicted by the package fingerprint, but the process continues reactive and proactive scoring based on the predicted event and threshold value of the new package fingerprint.

[0084] FIG. 12 is a flow diagram illustrating example steps 1200 that may be followed when executing the proactive scoring function of the second processing system 218 scheduled during the reactive scoring method of FIG. 11. The method begins periodically according to a schedule, beginning at step 1202, where the next predicted event of a package fingerprint is evaluated. This evaluation compares the current time with the service commit time and a threshold value specified by the package fingerprint for this next predicted event to determine the amount of delay, if any, that exceeds the threshold. Decision step 1204 determines whether the current time is past the service commit time. If yes, the package is already late, so the risk of the package being late is assigned as 1 or 100%, and this instance of proactive scoring for the next predicted event ends. If the time of the current event has not yet passed the service commit time, the amount of delay of the actual event relative to the cutoff time for the next predicted event, as indicated by the previously determined threshold, is considered, and it is determined in step 1208 whether there is a delay relative to the threshold cutoff time.

[0085] If there is no delay, the package is currently no higher risk than when the most recent reactive scoring was performed. Therefore, the risk score is unchanged, and this instance of proactive scoring for the next predictive event ends. If there is indeed a delay relative to the threshold, in this example, in step 1210, the scheduled proactive event is cleared for this package, as a new proactive schedule is created instead. Next, in step 1212, the risk level of this next predictive event at this amount of delay exceeding the threshold is found in the risk table and assigned to the package. A new proactive scoring action for the next predictive event may then be scheduled to start at a new time in the future. For example, a new schedule for proactive scoring for the package may be scheduled to start one hour later, which corresponds to an increment in the amount of delay in the risk table, e.g., a one-hour increment. The amount of time before the next proactive scoring begins is a balance of the amount of processing power required for proactive scheduling versus the particular level of granularity value for proactive scoring updates. This instance of proactive scoring then ends.

[0086] 13 is a flow diagram illustrating example steps 1300 that may be followed when performing the risk aggregation function of the second processing system 218. In some embodiments, it may be desirable to use proactive scoring only for the purpose of determining whether the risk of a package being delivered after a specified time is worse than the risk from the most recent reactive scoring, and to record that worse risk for the package. Thus, if proactive scoring of the next predicted event results in a lower risk score than assigned by the most reactive scoring, the higher risk in the most reactive scoring is maintained as the package's risk level. Thus, in such embodiments, only the actual occurrence of an event within the reactive scored network can reduce the package's assigned risk level. Example 1300 illustrates this implementation.

[0087] Example 1300 begins at step 1302, where proactive scoring of the next predicted event of the package fingerprint is performed to determine a proactive scored risk level. This proactive scored risk level, i.e., new risk, is compared to the most recent reactive scored risk level for the package, i.e., old risk, and a determination is made as to whether the new risk is greater than the old risk. If the new risk is not greater than the old risk, the old risk found from the most recent reactive scoring is maintained as the level of risk for the package in step 1308. If the new risk is greater than the old risk, the new risk found from the most recent reactive scoring is maintained as the level of risk for the package in step 1306. Example risk aggregator 1300 then ends until the next proactive scoring for the package occurs.

[0088] 14 is a flow diagram illustrating example steps 1400 that the fourth processing system 226 may follow to reroute a package via changes to the transportation plan implemented by the logistics network 100 in response to the level of risk determined by the second processing system 218. The second processing system 218 may output live in-transit package risk data as a stream directed to and received by the fourth processing system 226 in step 1402. The fourth processing system 226 may then determine an alternative transportation plan from the package's current location to its final destination at an estimated risk lower than the current risk level in step 1404. For example, this step may include implementing an alternative transportation plan in step 1406 in which the package is directed to an atypical next-event location that differs from the fingerprint threshold's next predicted event location, thereby triggering a new assessment of the package's risk that is likely different from the previous one. This can be even more effective when used in combination with pre-shipment risk determinations from external risk analysis, such as whether weather or traffic to a selected atypical next location is predicted to be a lower risk than the risk posed by weather or traffic to a more typical next location. Transportation planning and external risk analysis are described below in connection with Figures 15 and 16.

[0089] FIG. 15 illustrates an example 1500 of an actual package event 1502 and the associated risk level 1504 of the package being delivered after the specified time that occurs during the package's transit. The package arrives at location INDH, generating a risk score of 0. However, within the station at the INDH location, an exception occurs due to weather risk, resulting in a 73% chance that the package will be delivered after the specified committed time. However, due to the high level of risk, the package's transportation plan is changed and the package is rerouted, resulting in an updated risk prediction of 0 because the new route does not encounter weather risk. Furthermore, the package fingerprint threshold that applies to packages departing from the INDH location and bound for a MICA final destination at a given committed time and service level is not violated at the time of the departure event from INDH.

[0090] Along the route, the departure event from location MEMH is 9 minutes later than the event's fingerprint threshold (5:09 AM vs. 5:00 AM), resulting in a 34% ex post risk score based on the risk table. However, the risk score of 34% is considered low risk because the package is more likely than not to reach its final location by the 10:30 AM commitment time. The package then arrives at the next event location, MSPA, 56 minutes later than the event's fingerprint threshold (7:41 AM vs. 6:45 AM). However, the risk table indicates a risk score of only 7%, placing the package in the no risk category because it is highly likely to reach its final destination by the 10:30 AM commitment time. This keeps the risk fluctuating, but it does not exceed the low risk category, and the package is delivered by the 10:30 AM commitment time.

[0091] 16 is a flow diagram illustrating example steps 1600 that the fourth processing system 226 may follow to consider pre-shipment analysis using external factors and associated risks. In step 1602, the package's starting location or origin, start time, final destination, and product / service type are obtained. Next, in step 1604, the expected path and timing of the product traveling through the network 100 along the expected path is calculated using the predicted events in the package fingerprint for moving such package to its final location. In step 1606, based on the predicted location and time calculated from the package fingerprint, external factors and associated risk information 1608 is obtained to identify whether the package will pass through severe conditions such as weather or traffic, and this information is then converted into an ambient risk score.

[0092] This risk score may then be used by the transportation planning system 226 to make a pre-shipment decision about the transportation plan and whether a different plan has a lower risk. An example was described above in connection with Figure 15, where a 73% risk level was caused by weather. Similarly, this example pre-shipment determination of risk 1600 may be applied by the second processing system 218 in real time at each location visited by the physical load along the route to determine the ambient risk that the transportation planning system 226 may consider when deciding to re-route the load from the visited locations.

[0093] The risk information determined for each package in transit within logistics network 100 can be extremely useful to both the entities operating logistics network 100 and the entities expecting to receive the shipment. This is especially true for packages with special handling requirements, such as temperature control, such as certain vaccine and other medical-related packages, and / or packages with extreme time sensitivity, such as certain vaccine or medical-related packages. Accordingly, the risk information may be provided in a display format to various parties to enable them to monitor packages of interest. Furthermore, this allows personnel at the shipping entities to monitor for points of failure in the network that cause delays that affect their ability to deliver packages by the specified time.

[0094] Figure 17 shows an example 1700 of a screen capture of such a user display provided by applications 222, 224 of Figure 2. Example 1700 allows a user to apply various filters to control the information displayed, such as filter 1702 for payer versus shipper, filter 1704 for selecting the payer or shipper account selected in filter 1702, and package service type, such as ground or express service. Depending on the filter selected, example 1700 further displays the total number of packages in transit in field 1708, the total number of packages at a sufficient level of risk of concern in field 1710, and the number of packages that experienced an exception, such as a missed event due to weather or other atypical factors, in field 1712. Example 1700 also includes a map 1714 showing the number of packages at risk of being delivered after a specified time to locations within a given geographic area, such as within each state in the United States.

[0095] Providing this information in example 1700 allows a person interested in monitoring packages to focus on packages with a sufficient level of risk, such as greater than 50%, that warrants attention. Thus, rather than monitoring all 446 packages in transit, the person may choose to focus on the 283 that pose a sufficient risk level. These packages can be identified by the user selecting field 1710 to view all 283 or by selecting a geographic area from map 1714 and focusing on packages at risk for that selected area. Furthermore, the user can focus on any packages at risk by selecting to view more information; in response to receiving the user's selection, the third processing system then displays a list of packages at risk, allowing the user to select a package of interest from the list. Once the third processing system receives the selection of a particular package from the list, the third processing system may display package-specific information.

[0096] It will be understood that a shipper has an account for packages for a given customer, such as a shipper or recipient. Each package may be tied to that account such that the third processing system provides information to the shipper account to display only risk information related to that shipper account's packages. Furthermore, packages for a given shipper account may have different package-specific final locations, and events that occur to a package during transit may be package-specific events. Thus, in the example of FIG. 17 , the 446 packages for a shipper account may be destined for hundreds of different final locations. Furthermore, these packages may be traveling independently, so even two packages with the same origin and final destination following the same transit route may be at different points along the transit route and therefore experience different package-specific events that result in separate delay and risk determinations. Example 1700 shows a screen capture captured at a first display time. The user may then select to view the display at a second display time, where the values ​​may have changed due to additional scoring occurring for these packages. For example, the number of packages at risk may be greater or less than the 283 packages at risk at the first display time shown in FIG.

[0097] Figure 18 shows another example 1800 of a screen capture of a user display provided by the applications 222, 224 of Figure 2. This example 1800 provides information 1802 including the total number of packages / shipments for a given criteria, such as a particular customer or a particular location, the number of packages at risk of delay, the number without a commit date, the number on schedule, the number near the commit date, and the number past the commit date. This allows personnel at the shipping entity to quickly view a snapshot of a given customer.

[0098] The bar graph in example 1800 also allows for a quick view of a snapshot of the status of shipments in chart 1804, including the number of late shipments 1806. A lateness status chart 1808 shows the number of shipments in each category of risk of being delivered past their committed time, including the number of shipments 1810 at a sufficient level of risk, such as at least 80%, that are considered likely to be late, the number of shipments 1812 at low risk, such as less than 40%, and the number of shipments 1814 that are considered a medium risk, such as between 40% and 80%. Other information is also shown, such as a chart 1816 showing the last known location of the shipments. Thus, personnel at the shipping entity can gather a snapshot of information that provides insight into the operation of the network and the status of shipments for a given customer.

[0099] 19 illustrates another example 1900 of a screen capture of a user display provided by applications 222, 224 of FIG. 2. This example 1900 is particularly suited for personnel at a shipping entity seeking to identify failure points in logistics network 100 that cause delays that pose a risk of packages being delivered after the specified committed time. Example 1900 includes a heat map 1902 depicting locations within logistics network 100 where delays are occurring based on the number of violated fingerprint thresholds discovered during reactive and proactive scoring. Delays may also be shown distributed across days of the week, as in chart 1904.

[0100] A set of filters 1906 may also be available for selection to allow the user to filter the information as needed and drill down into the data in various ways, taking into account that the risk data is stored in association with all other parameters of the package, including customer, origin, current location, final location, service type, specified commit time, etc. Filters may be applied individually or in combination. A first field 1908 provides for selection of a customer name (i.e., shipper) to filter the information for the provided display. A second field 1910 provides for selection of an EAN code to filter the information for the provided display. A third field 1912 provides for selection of a facility name to filter the information for the provided display. A fourth field 1916 provides for selection of a facility name to filter the information for the provided display. A fifth field 1918 provides for selection of a delivery date to filter the information for the provided display. A sixth field 1920 provides for selection of the number of service delay days to filter the information for the provided display. A seventh field 1922 provides for selection of the scan type that resulted in the event data, or the event type described above, to filter the information for the provided display. An eighth field 1924 provides a facility type selection for filtering the information provided for display, a ninth field 1926 provides an origin location selection for filtering the information provided for display, and a tenth field 1928 provides a destination location selection for filtering the information provided for display, with both fields 1926 and 1928 allowing the user to specify an origin / destination combination.

[0101] In addition to the heat map 1902 and chart 1904, a table of information 1930 is displayed to provide specific details to the user. For example, the shipments resulting from the application of a filter appearing in table 1930 may show the event type in column 1932, the event timestamp in column 1934, and the corresponding fingerprint threshold timestamp in column 1936. In this manner, the raw data generating the risk of delay can be viewed and filtered as needed by facility, customer, etc. Other charts, such as donut charts 1938, 1940, and 1942, may be shown to further illustrate the relative contribution to delay by scan type, facility type, origin / destination pair, etc. Learning points of failure by facility, facility type, scan type, customer, origin / destination pair, etc., allows the user to consider corrective actions to improve the operation of the logistics network 100.

[0102] Various examples and embodiments are described above for creating and applying network models in the form of package fingerprints to provide the ability to determine late delivery risks and exceptions for packages in transit, and to enable monitoring of such packages at risk and the occurrence of late delivery risks and exceptions. Improvements to computer systems related to logistics networks include the ability to create these thresholds from historical data and then apply these thresholds in real time to enable real-time monitoring of late delivery risks.

[0103] In summary, it will be appreciated by those skilled in the art that the sequences of operations for carrying out any of the methods and method variations described in the embodiments herein are merely exemplary, and it is emphasized that various sequences of operations may be followed as legal and in accordance with the principles of the present invention.

[0104] At least some portions of the exemplary embodiments outlined above may be used in conjunction with portions of other exemplary embodiments to enhance and improve logistics operations and related monitoring of packages at risk of delivery delays. For example, risk based on reactive and proactive scoring may be used in conjunction with pre-shipment risk analysis. Similarly, either or both of these risk assessments may be used solely for monitoring and intelligence purposes, or may be used to create a closed-loop package transportation planning. Furthermore, at least some of the exemplary embodiments disclosed herein may be used independently and / or in combination with each other and may be applicable to apparatuses and methods not disclosed herein. However, those skilled in the art will appreciate that the exemplary model training, model scoring, and related outputs described above provide enhancements and improvements to techniques used in logistics and shipment management.

[0105] Those skilled in the art will understand that embodiments may provide one or more advantages, and that not all embodiments necessarily provide all or more of the specific advantages described herein. Moreover, it will be apparent to those skilled in the art that various modifications and variations can be made to the structures and methods described herein. Accordingly, it is to be understood that the invention is not limited to the details set forth herein. Rather, the invention encompasses modifications and variations, as defined by the following claims.

Claims

1. 1. A computer system for monitoring the transportation of packages within a logistics network, comprising: an interface to at least one logistics network data source; a first data storage module including historical network data coupled to the interface, the first data storage module constructing the historical network data from data feeds from the logistics network data sources; a second data storage module containing cargo transportation model data; a first processing system accessing each of the first data storage module and the second data storage module, capturing historical event data including a probable location of the historical event, a probable type of the historical event, and a probable time of the historical event; and generating, from the historical event data, a series of predicted events for a virtual package being transported through the logistics network from a first location to a final location; and determining thresholds for each of the predicted events such that the virtual package will arrive at the final location by a specified time, each threshold being associated with the expected time of the predicted event occurring for the virtual package, and the predicted events being associated with expected locations and expected types. a first processing system that applies machine learning to the historical network data to train the cargo transportation model data by performing a second processing system coupled to the interface for receiving live data from the logistics network, the second processing system accessing the package transportation model data from the second data storage module, applying the thresholds to the predicted events for the package, and evaluating whether the package will be delivered as scheduled to the final location by the specified time for each predicted event based on the application of the thresholds; A computer system comprising:

2. The computer system of claim 1 , wherein the first processing system further calculates a table of risk amounts associated with delay amounts exceeding the threshold in any of the predicted events for the virtual cargo to reach the final location by the specified time.

3. The computer system of claim 2, wherein the second processing system determines the level of risk that the actual package will not be delivered to the final location by the specified time by accessing a table of risk amounts to determine the risk amount associated with a delay amount exceeding the threshold for a current event detected by the second processing system.

4. 4. The computer system of claim 3, wherein the second processing system further determines the level of risk that the actual package will not be delivered to the final location by the specified time by accessing a table of risk amounts to determine the risk amount associated with the delay amount exceeding the threshold for a next predicted event that has not yet been detected by the second processing system.

5. 4. The computer system of claim 3, further comprising a third processing system that receives the level of risk associated with the physical shipment and, upon receiving a request, generates a display indicating the level of risk for the physical shipment.

6. a fourth processing module for receiving the level of risk associated with the physical shipment; 4. The computer system of claim 3, wherein when the level of risk that the actual cargo will not be delivered to the final location by the specified time reaches a rerouting threshold, the fourth processing module determines a next event for the actual cargo that is different from a next event planned during transportation to the final location that is expected to reduce the level of risk.

7. 4. The computer system of claim 3, wherein the second processing system further receives external factor information, and the second processing system determines a future risk to the actual cargo reaching the location by the specified time based on the external factor information related to the predicted event expected to occur for the actual cargo during transportation.

8. The computer system of claim 7 , wherein the external factor information includes weather and traffic information related to the predicted event.

9. The computer system of claim 3 , wherein the current event comprises the physical package being scanned at a specified location within the logistics network.

10. The computer system of claim 9 , wherein the current event further comprises an arrival scan at the specified location within the logistics network.

11. The computer system of claim 9 , wherein the current event further comprises a departure scan from the specified location within the logistics network.

12. the first processing system determines the threshold for each predicted event by determining, for each predicted event that is a current predicted event, a time at which a desired percentile of packages historically arrive on time; The computer system of claim 1 , wherein the threshold is set based on the time for reactive monitoring of the current predictive event for the actual load.

13. 13. The computer system of claim 12, wherein the desired percentile of historical on-time arriving packages for the current forecast event is a 99th percentile.

14. 13. The computer system of claim 12, wherein the first processing system further determines the threshold for each current predicted event by determining, for each current predicted event, a next predicted event that is likely to follow the current predicted event by selecting the next predicted event location having a most recent threshold from a set of potential next event locations, wherein the threshold for each potential next event location for determining the most recent threshold is determined by determining, for each potential next event, a time that a desired percentile of packages traveling from the current event location to the potential next event location would historically arrive on time, and wherein the most recent threshold identifies a location and type of the next predicted event for purposes of proactively monitoring the next predicted event for the actual package.

15. For a first shipper account having a plurality of packages being transported within the logistics network, at least some of the plurality of packages have a first shipper location and a package-specific final location, and while each package is being transported within the logistics network, the second processing system captures event data for each package at each package-specific current event, retroactively compares the threshold value from a corresponding current predicted event for each package with an occurrence time of the package-specific current event to determine from a risk table a level of risk that the package will not be delivered to the final location by a specified package-specific time, and proactively compares the threshold value from a corresponding next predicted event for each package with a current time, 3. The computer system of claim 2, further comprising a third processing system that receives output from the second processing system, and the third processing system provides information for display to the first shipper account at the first display time, the information including the total number of packages among the plurality of packages that are at least at a specific risk level of not reaching the package-specific final location by the package-specific specified time.

16. While each package is being transported within the logistics network, the second processing system continuously captures event data for each package at each package-specific current event, retroactively compares the threshold value from the corresponding current predicted event for each package with the occurrence time of the package-specific current event to determine from the risk table the level of risk that the package will not be delivered to the final location by the package-specific specified time, and proactively compares the threshold value from the corresponding next predicted event for each package with the current time, The computer system of claim 15, wherein the third processing system provides, for the first shipper account, information for display at a second display time following the first display time, including the total number of packages among the plurality of packages at at least the risk level that will not reach the package-specific final location by the package-specific specified time.

17. For the first shipper account, the third processing system provides information for display, the information including information regarding packages at least at the specified risk level that will not reach the package-specific final location by the package-specific specified time; 16. The computer system of claim 15, wherein the third processing system receives a selection of one of the packages being displayed and provides information for display specific to the selected package.

18. 3. The computer system of claim 2, further comprising a third processing system that receives the output of the second processing system, the third processing system providing information for display at a first display time that includes aggregate information regarding packages that are at least at a particular risk level of not reaching their specific final location.

19. 20. The computer system of claim 18, wherein the logistics network includes multiple facilities, and the third processing system provides for selection of a particular facility to filter information for a provided display.

20. 20. The computer system of claim 18, wherein the third processing system provides for selection of specific event types to filter information for a provided display.

21. Each facility has a specific type, 20. The computer system of claim 19, wherein the third processing system provides a selection of a particular facility type to filter information for a provided display.

22. 20. The computer system of claim 18, wherein the third processing system provides a selection of package origin to filter information for a provided display.

23. 20. The computer system of claim 18, wherein the third processing system provides a selection of the package's last location to filter the information provided for display.

24. 20. The computer system of claim 18, wherein the third processing system provides for selection of the specified time of delivery of the package to filter information for a provided display.

25. 20. The computer system of claim 18, wherein the third processing system provides a selection of the package's last location to filter the information provided for display.

26. 20. The computer system of claim 18, wherein the third processing system provides a selection of package shippers to filter information for a provided display.

27. 20. The computer system of claim 18, wherein the third processing system provides information for display including the number of actual packages at least at the particular level of risk grouped by each day of the week on which a predictive event threshold underlying the particular level of risk for the actual package occurs.

28. 1. A computer-implemented method for monitoring transportation of packages in a logistics network, comprising: applying machine learning to historical network data for the logistics network to train parcel transportation model data; capturing historical event data including a probable location of the historical event, a probable type of the historical event, and a probable time of the historical event; and generating, from the historical event data, a series of predicted events for a virtual package being transported through the logistics network from a first location to a final location; and determining thresholds for each of the predicted events for the virtual package to arrive at the final location by a specified time, wherein each threshold is associated with the expected time of the predicted event occurring for the virtual package, and the predicted events are associated with expected locations and expected types. and applying the threshold to the predicted events for the actual shipment; evaluating, for each predicted event, whether the actual package will arrive at the final location as scheduled by the specified time based on application of the threshold; further calculating a table of risk amounts associated with delay amounts exceeding the threshold in any of the predicted events for the virtual load to reach the final location by the specified time; determining a level of risk that the physical package will not be delivered to the final location by the specified time by accessing the table of risk amounts to determine the risk amount associated with a delay amount exceeding the threshold for the detected current event; determining a level of risk that the physical package will not be delivered to the final location by the specified time by accessing the table of risk amounts to determine the risk amount associated with the amount of delay exceeding the threshold for a next predicted event that has not yet been detected; A computer-implemented method comprising:

29. For a first shipper account having a plurality of packages being transported within the logistics network, at least some of the plurality of packages have a first shipper location and a package-specific final location, and while each package is being transported within the logistics network, event data for each package is captured at each package-specific current event, and the threshold value from the corresponding current predicted event for each package is retroactively compared with the occurrence time of the package-specific current event to determine the level of risk of not being delivered to the final location by the package-specific specified time from the risk amount table, and the threshold value from the corresponding next predicted event for each package is proactively compared with the current time to further determine the level of risk of not being delivered to the final location by the package-specific specified time from the risk table. The computer-implemented method comprises: providing, at a first display time, information for display including a total number of packages among the plurality of packages that are at least at a specific risk level of not reaching the package-specific final location by the package-specific specified time; 30. The computer-implemented method of claim 28, further comprising:

30. 30. The computer-implemented method of claim 29, providing display information for the first shipper account including information regarding packages at least at the specified risk level that will not reach the package-specific final location by the package-specific specified time, receiving a selection of one of the displayed packages, and providing display information specific to the selected package.

Images