Patent Application
20180165635
The present disclosure relates generally to computer systems for shipping management. More particularly the present disclosure relates to online computer systems for predicting delivery exceptions and resolving delivery exceptions. More particularly, the present disclosure relates computer systems for multi-carrier shipping management with predictive exceptions and exception resolution.
The shipment of goods between shippers and recipients is typically carried out by carriers that own assets (trucks, cars, cargo ships, airplanes, rail cars) and that are contracted by manufacturers and retailers of those goods. In general, shipments are divided into two modes: “parcel” and “freight.” Parcels are generally small, individual shipments handled by common carriers. Individual shippers can drop off these shipments at numerous locations (or have the shipments picked up) at their convenience. Pricing is generally determined by dimensional and/or weight. Carriers typically limit parcel shipments to particular weight and/or dimensions (e.g., 150 lbs. and 165″ in length plus girth).
A shipment that exceeds the parcel limits is typically categorized as freight. Freight may be further divided into freight modes such as Full Truckload (FTL), Partial Truckload, Less Than Truckload (LTL), Air Freight, Ocean Freight, Rail Freight and Intermodal Freight. Freight pricing is determined on a number of factors including mode, route distance, fuel costs, density and value (weight, length, height), stow-ability, handling, liability, freight class, etc. Freight shipments are generally arranged with a carrier. Arrangements may include how the freight is to be loaded, how long it will take in transport, specialized equipment required or other information to facilitate the delivery.
Many carriers provide in-transit tracking data that identifies when goods have passed through various designated tracking locations along the route. This tracking information is typically accessible via web pages, links or spreadsheets. The data varies in quality, completeness and accuracy across carriers and modes, particularly as it relates to identifying issues that lead to late delivery (referred to as “exceptions”).
Organizations that do a large amount of shipping may have a computer system that is tightly integrated with a carrier's system to facilitate shipping and shipment tracking. However, these systems suffer shortcomings with respect to exception management. As one problem, systems used by shippers do not typically identify exceptions across multiple carriers because there is a lack of consistency across carriers and modes as to what constitutes an exception. Moreover, conventional systems rely on the carriers to flag exceptions, but in many cases, the carriers do not flag all actual exceptions.
In addition to the lack of consistency, carriers do not update exception information in a timely manner. Accordingly, exceptions are often not exposed to shippers or intended recipients in a timely fashion that would allow the shipper or recipient to resolve the exception or take action in light of the exception.
The aforementioned issues create consistency and reliability issues for the shipper and recipient, leading to a host of experience, cost and product availability problems that ripple through supply chains of shippers and recipients.
One particular embodiment is directed to a shipping management system having one or more computer systems coupled to a network and a data storage device. The shipping management system uses one or more ingest modules to collect shipping information from the computer systems of multiple carriers over a network. The shipping management system uses one or more normalization modules to normalize collected carrier specific data. The shipping management system uses one or more prediction modules to analyze the normalized shipping information using a set of prediction rules. The shipping management system identifies carrier exceptions and generates predicted exceptions based on the normalized shipping information. The shipping management system can selectively generate notifications, take actions, and/or resolve identified and generated exceptions.
The systems, methods, and products include one or more dashboards (for example, a web based dashboard generated by an interface module) accessible by a user that is associated with an account holder. From the dashboard, the user can view various metrics and access functions of a shipping system, such as scheduling shipments. In some embodiments, a user can click on an exceptions menu item to see all shipments associated with the account holder that have exceptions.
Numerous other embodiments are also possible.
These, and other, aspects of the disclosure will be better appreciated and understood when considered in conjunction with the following description and the accompanying drawings. It should be understood, however, that the following description, while indicating various embodiments of the disclosure and numerous specific details thereof, is given by way of illustration and not of limitation. Many substitutions, modifications, additions and/or rearrangements may be made within the scope of the disclosure without departing from the spirit thereof, and the disclosure includes all such substitutions, modifications, additions and/or rearrangements.
The drawings accompanying and forming part of this specification are included to depict certain aspects of the disclosure. It should be noted that the features illustrated in the drawings are not necessarily drawn to scale. A more complete understanding of the disclosure and the advantages thereof may be acquired by referring to the following description, taken in conjunction with the accompanying drawings in which like reference numbers indicate like features and wherein:
The invention and the various features and advantageous details thereof are explained more fully with reference to the nonlimiting embodiments that are illustrated in the accompanying drawings and detailed in the following description. Descriptions of well-known starting materials, processing techniques, components and equipment are omitted so as not to unnecessarily obscure the invention in detail. It should be understood, however, that the detailed description and the specific examples, while indicating preferred embodiments of the invention, are given by way of illustration only and not by way of limitation. Various substitutions, modifications, additions and/or rearrangements within the spirit and/or scope of the underlying inventive concept will become apparent to those skilled in the art from this disclosure.
Embodiments described herein provide a shipping management system that uses time-based and event-based information to predict whether an exception condition, such as a pickup or delivery delay or other shipment issue, is likely to be reached. Once an exception condition is flagged the system notifies interested parties through different means (API calls, SMS notifications, SQL updates) and takes other actions to resolve exceptions (including predicted exceptions).
The system is time-based because each update to a shipment history has a specific time value which is either in the past (e.g., shipment was scheduled on a specific date and time), current (e.g., latest status) or in the future (e.g., estimated delivery date and time). The system uses the time information to trigger predictive exceptions based on time cut-off triggers (e.g., scheduled pickup date is in the past and the shipment status is not updated) and duration triggers (e.g., expected delivery date is 2 days away but historically the shipment transit days from its current location is 3 days). Each of those triggers can be specific to a state, such as a “scheduled for pickup”, “in transit” or “out for delivery” state or other defined state. The triggers may also be specific to a carrier or carrier and mode.
The system is event-based because each update to the shipment history is associated with a descriptive event status code or text. The system applies logic to extract relevant information from either the status code value or other pieces of information such as the status text, to trigger predictive exceptions.
The system combines time-based and event-based signals to trigger predictive exceptions that identify potential issues earlier than would normally be the case. The system further includes a framework for classifying and resolving exceptions.
Embodiments of the systems and methods of the present invention may be better explained with reference to
Shipping management system 120 may comprise one or more computer systems with central processing units executing instructions embodied on one or more computer readable media where the instructions are configured to perform at least some of the functionality associated with embodiments of the present invention. These applications may include a shipping management application 130 comprising one or more applications (instructions embodied on a computer readable media) configured to implement an interface module 132, data ingest modules 134, a normalization module 135, a predication module 136 and an exception management module 138 utilized by the shipping management system 120.
Furthermore, shipping management system 120 may include data store 122 operable to store obtained data 124 collected from carrier systems 150, normalized data 126, predicted exception data 128, user accounts 129 and other data. User accounts 129 can include account information for account holders of accounts with shipping management system 120. The account holder information may be associated with an individual, shipper or an entity, such as a retailer, that uses drop shippers. The account holder information 129 may include credentials for one or more carrier systems 150 so that shipping management system 120 may log into a carrier system 150 on behalf of the account holders to schedule a pick up, request tracking information, etc.
Carrier systems 150 may provide in-transit tracking data through a variety of mechanisms.
Some carriers systems 150 may provide public application program interfaces (APIs) 151 that allow external systems to access tracking data. For systems with an API, an ingest module 134 may be programmed to make calls to the API 151 to collect tracking data related to shipments by that carrier being tracked by shipping management system 120.
Other carrier systems 150 allow users to register to receive files, such as spreadsheet 152 or other files, containing tracking data for one or more shipments. Accordingly, an ingest module 134 may be configured to request and receive files containing tracking information.
Other carrier systems 150 may only provide tracking data through a web page interface, such as web page 154. However, since the structure of a web page can be understood through observation, an ingest module 134 may be programmed to submit information, such as tracking numbers, through a web page and collect the returned data.
Ingest modules 134 may also be programmed to collect tracking data through other mechanisms. In addition, ingest modules may be programmed to collect data from other types of systems, such as weather tracking systems, mapping and traffic systems and other systems that provide data on events that may affect the timeliness of deliveries.
Ingest modules 134 may be configured to gather carrier data from multiple sources on a per-carrier basis in a variety of ways, including, but not limited to:
Ingest modules 134 use a set of scheduling rules to schedule how often tracking data is requested from the different sources, unless the update frequency is controlled by the carrier as is the case when receiving shipment reports via email attachments. The scheduling rules take into consideration the current status of the shipment, the type of shipment, the expected delivery date, the carrier and whether a person or system is subscribed for updates (e.g. SMS text updates).
Some examples of scheduling rules include:
Thus, in some embodiments, information about a shipment is collected from carrier systems 150 based on the last known status of the shipment.
The collected data may include, among other information, both temporal (“when”) and location (“where”) information that is used to build a full context of each tracking update. Each tracking update can contain one or more of status (status code or description), exception, location and time information for a shipment. The exception information will either be extracted as-is (if the carrier provides such information) or will be computed through status mapping using carrier-specific rules. In some embodiments, the system can intelligently fill in gaps in the collected information by leveraging known information about the shipment, such as origin and destination information. For example, if the location information for a “delivered” tracking update is not available, the shipment destination information can be used to fill in that information.
Normalization module 135 is configured to map between the carrier specific formats used by each carrier system 150 and normalized data. In accordance with one embodiment, normalization module 135 includes normalization rules to map the carrier tracking codes in the received carrier data to (internal) normalized tracking codes, examples of which are discussed below.
According to one embodiment, normalization module 135 is implemented using a set of carrier-specific status mappings that map specific status code values or status description values or both to one of a number normalized status with an exception flag available on each; along with an exception category when appropriate. It can be noted that more or fewer normalized statuses can be used. In general, the statuses correspond to various stages of a shipment (e.g., pickup scheduled, picked up, arrived at origin terminal, arrived at destination terminal, arrived at (other) terminal, departed terminal, out for delivery, delivered).
In one embodiment, shipping management system 120 defines a status mapping document (e.g., in JavaScript Object Notation (JSON) format or other format) which defines:
By defining a carrier-specific status mapping, normalization module 135 allows shipping management system 120 to compensate for differences between carriers using more or less specific rules based on the granularity for the source data.
In the example where shipping management system 120 defines a status mapping document in JSON format, the JSON document can be used to define rules per carrier and per status code and/or status description. The general structure of an exemplary JSON documents is as follows:
Essentially, the JSON document provides a tree of decisions, starting with determining the carrier, since the rules are carrier-based. Next, a matching rule determines if the status pattern matches a status code value. In some examples, the status pattern could match a status code exactly. In other examples, the status pattern does not match exactly, but the status pattern “starts with”, “ends with”, etc. a value. If the rules do not match a status code, the system can map a fallback value, such as “in transit”. Other examples are also possible.
Following is an example of a rules JSON document that can be used to define rules per carrier and per status code and/or status description:
As described above, normalization module 135 is configured to map between the carrier specific formats used by each carrier system and internal normalized tracking codes. Table 1 provides an example of normalized codes to which the normalization module 135 maps. The example shown in Table 1 shows exception categories. Column 1 of Table 1 lists the name of each exception type (e.g., “attempted_delivery”, “available_for_pickup”, etc.). Column 2 of Table 1 lists a description of each exception type listed in Column 1 (e.g., “Attempted Delivery”, “Available for pickup by recipient at carrier terminal or access location”, etc.).
Table 2 is an example showing transaction information from multiple carriers (Carrier A, Carrier B, Carrier C) being mapped to normalized data. As shown, Column 1 of Table 2 identifies the carrier for each transaction. Column 2 of Table 2 shows a status code provided by the carrier. As described above, status codes from different shippers are not standardized. Column 3 of Table 2 shows the normalized status (in this example, one of the normalized exceptions listed in Table 1).
Table 3 is a table showing examples of shipping records. In the example shown, each shipment has an internal shipment id (Column 1) that the shipping management system 120 uses to identify each shipment. Column 2 of Table 3 shows the normalized status of each respective shipment. Column 3 of Table 3 identifies the carrier. Each shipment includes a unique tracking number, provided by the carrier. If the shipment has an exception, the normalized exception type is identified in Column 5 of Table 3. In general, the most recent exception may be stored in a shipping record. Finally, Columns 6 and 7 show the origin and destination of each shipment. A shipping record will typically include more information than is shown in Table 3, which, for clarity, shows just a few exemplary fields.
Table 4 is a table showing shipment events for shipment_id 1000. In the example shown, each shipment event has an internal id (Column 1). Column 2 of Table 4 shows the shipment_id, which identifies the shipment. Column 3 of Table 4 shows the normalized status value. Column 4 of Table 4 shows the normalized exception value, if the shipment event has an exception (for example, event 1002 show exception “held_at_terminal”). Finally, Column 5 of Table 4 shows the time and date that the event was created. The time and date values can be used to determine the order in which the events occurred, since they may not all be received in order.
Prediction module 136 is configured to evaluate the normalized data and predict exceptions. Prediction module 136 may be programmed with rules to identify potential exceptions. If a predicted exception is determined for shipment 1000, the predicted exception can be added as an event to the shipment events in Table 4 for shipment 1000. The shipping record for shipment_id 1000 may also be updated to reflect the predicted exception as the most recent exception.
For example, a rule may specify that if a shipment is marked as “pickup scheduled”, but no action has occurred on a shipment for “x” number of hours, the shipment can be flagged as having a potential exception (also referred to as a “predicted exception” herein). For example a rule can specify that if a shipment is scheduled but is not in transit within 12 hours of the ship date, then a missed pickup exception can be set (e.g., an event with “convey_missed_pickup” from Table 1 can be added to the event records for the shipment and the shipping record updated). In another example, if a shipment is not delivered and the estimated delivery date has passed then, then a missed estimated delivery date can be set (e.g., “convey_missed_estimated_delivery_date” from Table 1).
The prediction rules may be carrier specific. Predictive exceptions can be deduced from carrier status values based on actual shipment research. For example, if it is known that a particular carrier typically takes 18 hours to update its tracking data after picking up a shipment, a rule associated with the carrier may be configured to flag an exception if there is no action on a shipment (as can be determined from the carrier's tracking data) for 24 hours. This accounts for both the time it takes the carrier to pick up the shipment and the time it takes the carrier to update its tracking data. However, if it is known that a second carrier updates its tracking data within an hour of pickup, a rule for that carrier could be configured to mark an exception if there is no action on the shipment for 8 hours or other configured time period.
Rules may also be applied based on tracking data indicating that a shipment has arrived at or departed from a tracking location (e.g., a terminal). For example, a rule may be configured to flag a potential exception if the normalized tracking data for a shipment indicates that the shipment arrived at a tracking location but does not show further action on the shipment within 12 hours (or other time period, which in some embodiments may be carrier dependent). Similarly, a rule may be configured to flag a potential exception if the normalized tracking data for the shipment indicates that the shipment left a tracking location, but shows no further action on the shipment for 12 hours (or other time period, which in some embodiments may be carrier dependent).
In addition, rules may incorporate historical data to identify exceptions. For example, shipping management system 120 may track transit times by carrier and mode from origin zip codes to destination zip codes. Even more particularly, the transit times may be tracked based on time of year, class of package ship, weight of package and other factors. A rule may be specified such that prediction module 136 flags an exception if the transit time for a shipment by a carrier/mode from an origin zip code to a destination zip code exceeds by a specified amount, the average historical transit time for that zip code pair and time year for the carrier/mode.
In addition to analyzing in-transit tracking information, prediction module 136 may use information from other systems 180 to predict exceptions. For example, shipping management system may maintain information on historical routes between origin zip codes and destination zip codes by carrier/mode (e.g., such as the most common tracking locations for deliveries from an origin to destination zip code). If prediction module 136 detects a forecasted severe weather event along the route, prediction module 136 may predictively identify a possible exception based on forecasted weather event.
Prediction module 136 may also apply other rules to identify events that, while not being exceptions, may affect the delivery of a package. As one example, certain carriers may require a recipient to sign for a package under particular circumstances. If an order meets the criteria requiring a recipient signature, prediction module 136 can flag the event when prediction module 136 detects that the package has reached the final terminal or achieved a particular status (e.g., “out for delivery”). For example, in one embodiment, parcel packages can be marked as requiring a signature if the order or carrier data provides this information, whereas freight packages are marked as requiring a signature (appointment) if carrier data provides this information or if the package reaches the destination terminal.
Exception management module 138 is configured with rules for classifying exceptions and taking actions based on exceptions (e.g., exceptions contained in the ingested (normalized) tracking data or predictive exceptions identified by prediction module 136) or other events (e.g., a signature required event). In accordance with one embodiment, each exception can be classified as follows:
The rules for classifying an exception may take into account a variety of information. In some cases, exception management module 138 may be configured to query other sources 180 for data relevant to a shipment (or review data collected previously collected from other sources 180) and apply rules to the data to classify predicted exceptions. For example, if prediction module 136 flags an exception due to a delay at a particular tracking location (a predicted delay), exception management module 138 may query a weather tracking system 180 or analyze weather data to determine the weather in the area of the tracking location. If severe weather is indicated, exception management module 138 may classify the predicted exception as a weather delay as noted above.
In another embodiment, exception management module 138 may be configured to generate a notification to a carrier alerting the carrier of the potential delay so that the carrier can determine if there is an actual delay in the shipment.
When exception management module 138 determines that a shipment has an exception, exception management module 138 may trigger various actions to resolve the exception. Exception management module 138 can use an exception code classification that identifies if an exception is a candidate for automated resolution and, if so, generates the required notifications and communication (via SMS, email, API, database updates (e.g., SQL updates) data ingestion).
Each exception can be resolved as follows based on the exception classification:
The rules specifying the actions to take for an exception may depend on the exception classification, the shipper, the carrier/mode, the recipient, location where the exception occurred and other information.
Actions may include sending notifications to account holders, shippers, recipients or carriers, interacting with shipper or carrier systems to resolve an exception or taking other actions. For example, a missed pick up exception may trigger an action to notify the shipper to reschedule the pickup or, in another example, a missed pick up exception may trigger an action that causes shipping management system 120 to automatically reschedule the pick up on behalf of the shipper (e.g., through an API 151).
As another example, a weather delay exception may trigger sending a notification of a potential weather delay to the intended recipient of the shipment. In another example, exception management module 138 may automatically re-route a shipment or source the shipment from a different originating location if possible.
In some cases, notifications may include information to facilitate resolving the exception. For example, in
In some embodiments, a shipper may specify content for notifications sent to recipients of shipments from that shipper. For example, the shipper may specify that, if an exception occurs (or certain type of exception occurs) in a shipment, the recipient should be sent a notification indicating that the next shipment to that recipient will be shipped free.
Exception management module 138 may also include rules for taking actions on other events identified by prediction module 136. For example, exception management module 138 can provide the notification to the intended recipient of the delivery that requires a signature so that the intended recipient knows he or she should be available to sign for the package or risk delaying delivery.
As noted above, the rules may take into various factors for determine what actions to take in light of an exception. In one embodiment, shipping management system 120 may track recipient value to a customer. This information may be provided explicitly by a user (e.g., a user may classify each recipient as “tier 1” recipient, “tier 2” recipient, etc.) or shipping management system 120 may apply rules to shipping data to determine recipient value. The “tier 1” recipients of a shipper (or account holder) may be, for example, a recipient that receives x number of shipments a month from an account holder, or greater than a particular percentage of an account holder's shipments, or is in the top y recipients for the account holder. The recipient status may be a factor used by exception management module 138 in determining the exceptions/predicted exceptions to surface to the account holder (if different than the shipper), shipper, the recipient notification channel(s) used, the indicated urgency of a notification.
Exception management module 138 may further include rules for clearing exceptions. A predictive exception, in some embodiments, is cleared when a more recent tracking update is received that negates an existing predictive exception. Once a package has been shipped an existing “missed pickup” predictive exception will be cleared.
For example, if prediction module 136 flags an exception because the tracking data for a shipment indicated no action on a shipment within 12 hours of the shipment arriving at a tracking location, but then the next update of the tracking data indicates that the shipment left the tracking location, exception management module 138 may be configured to clear the exception, send a follow-up notification to the account holder, shipper or recipient, remove a prior notification from a web page or take another action.
As can be understood from the foregoing, shipping management system 120 can predict exceptions according to a defined set of rules and provide notifications to account holders (e.g., online retailers) shippers, recipients or carriers based on the predicted notifications. In addition, shipping management system can detect other types of events and take actions based on those events.
Shipping management system 120 may provide a wide degree of functionality including utilizing one or more interface modules 132 configured to, for example, receive and respond to queries from users at computing devices 110. It will be understood that the particular interface module 132 utilized in a given context may depend on the functionality being implemented by shipping management system 120, the type of network 170 utilized to communicate with any particular entity, the type of data to be obtained or presented, the time interval at which data is obtained from the entities, the types of systems utilized at the various entities, etc. In some embodiments, these interfaces may include, for example web pages, web services or APIs.
In operation, shipping management system 120 may provide a system through which shippers can select carriers, schedule pick up of shipments and track shipments. Shipping management system 120 may include account information 129 so that shipping management system 120 may log into a carrier system 150 on behalf of an account holder (e.g., a retailer or shipper) to schedule pick up of a shipment, request tracking information, etc. In this case, a carrier system 150 may provide a tracking number directly to shipping management system 120 because, from the perspective of the carrier system 150, shipping management system 120 is a shipper's computer system. In other cases, a shipper may make a shipment without going through shipping management system 120, but can provide a tracking number to shipping management system 120 so that shipping management system 120 can request the appropriate tracking information from the carrier system 150.
A user at a computing device 110 may access the shipping management system 120 through the provided interfaces provided by interface modules 132 and specify certain parameters, such as a carrier, mode, shipping information, a tracking number and other information. Shipping management system 120 can generate interfaces using interface module 132 and data determined from the processing, and present these interfaces to the user at the user's computing device 110. More specifically, in one embodiment interfaces may visually present shipping information, including predicted exceptions to the user.
The shipping management system 120 may receive a request from a client computer for an interface containing data associated with a user account and substantially simultaneously initiate generation of a responsive interface, such as a web page. The responsive interface may include predicted exception data. Because the predicted exceptions returned are, in some embodiments, determined prior to receiving the request and stored in a normalized format across carriers, the shipping management system can quickly retrieve the predicted exceptions for shipments related to an account and generate an interface that presents predicted exceptions from multiple carriers. Thus, shipping management system 120 can respond to a request for an interface in the times expected by users of the Internet and without a web browser timing out.
According to one embodiment, the user can click on “Exceptions” 610 to see all shipments associated with that account holder that have exceptions, including, in some embodiments, shipments by drop shippers shipping on behalf of the account holder. One embodiment of an exceptions dashboard is illustrated in
The shipping management system 120 also allows customers to provide input that can be used to generate exceptions. For example,
The shipping management system 120 can also generate notifications to end users either suggesting an action and/or providing notification of a future action.
Embodiments of a hardware architecture for implementing certain embodiments is described herein. One embodiment can include one or more computers communicatively coupled to a network. As is known to those skilled in the art, the computer can include a central processing unit (“CPU”), at least one read-only memory (“ROM”), at least one random access memory (“RAM”), at least one hard drive (“HD”), and one or more input/output (“I/O”) device(s). The I/O devices can include a keyboard, monitor, printer, electronic pointing device (such as a mouse, trackball, stylus, etc.), or the like. In various embodiments, the computer has access to at least one database over the network.
ROM, RAM, and HD are computer memories for storing computer instructions executable (in other which can be directly executed or made executable by, for example, compilation, translation, etc.) by the CPU. Within this disclosure, the term “computer-readable medium” is not limited to ROM, RAM, and HD and can include any type of data storage medium that can be read by a processor. In some embodiments, a computer-readable medium may refer to a data cartridge, a data backup magnetic tape, a floppy diskette, a flash memory drive, an optical data storage drive, a CD-ROM, ROM, RAM, HD, or the like.
At least portions of the functionalities or processes described herein can be implemented in suitable computer-executable instructions. The computer-executable instructions may be stored as software code components or modules on one or more computer readable media (such as non-volatile memories, volatile memories, DASD arrays, magnetic tapes, floppy diskettes, hard drives, optical storage devices, etc. or any other appropriate computer-readable medium or storage device). In one embodiment, the computer-executable instructions may include lines of compiled C++, Java, HTML, or any other programming or scripting code.
Additionally, the functions of the disclosed embodiments may be implemented on one computer or shared/distributed among two or more computers in or across a network. Communications between computers implementing embodiments can be accomplished using any electronic, optical, radio frequency signals, or other suitable methods and tools of communication in compliance with known network protocols.
As used herein, the terms “comprises,” “comprising,” “includes,” “including,” “has,” “having” or any other variation thereof, are intended to cover a non-exclusive inclusion. For example, a process, article, or apparatus that comprises a list of elements is not necessarily limited only those elements but may include other elements not expressly listed or inherent to such process, article, or apparatus. Further, unless expressly stated to the contrary, “or” refers to an inclusive or and not to an exclusive or. For example, a condition “A or B” is satisfied by any one of the following: A is true (or present) and B is false (or not present), A is false (or not present) and B is true (or present), and both A and B are true (or present).
Additionally, any examples or illustrations given herein are not to be regarded in any way as restrictions on, limits to, or express definitions of, any term or terms with which they are utilized. Instead, these examples or illustrations are to be regarded as being described with respect to one particular embodiment and as illustrative only. Those of ordinary skill in the art will appreciate that any term or terms with which these examples or illustrations are utilized will encompass other embodiments which may or may not be given therewith or elsewhere in the specification and all such embodiments are intended to be included within the scope of that term or terms. Language designating such nonlimiting examples and illustrations includes, but is not limited to: “for example,” “for instance,” “e.g.,” “in one embodiment.”
Benefits, other advantages, and solutions to problems have been described above with regard to specific embodiments. However, the benefits, advantages, solutions to problems, and any component(s) that may cause any benefit, advantage, or solution to occur or become more pronounced are not to be construed as a critical, required, or essential feature or component.
This application claims a benefit of priority under 35 U.S.C. § 119 to U.S. Provisional Patent Application No. 62/432,514 filed Dec. 9, 2016, entitled “SYSTEMS AND METHODS FOR PREDICTIVE IN-TRANSIT SHIPMENT DELIVERY EXCEPTION NOTIFICATION AND AUTOMATED RESOLUTION”, which is hereby fully incorporated by reference in its entirety.
| Number | Date | Country | |
|---|---|---|---|
| 62432514 | Dec 2016 | US |
