SYSTEMS AND METHODS FOR FACILITATING

LOADING AND MONITORING OF SHIPMENTS

Cross-reference to Related Application

[0001] This application claims priority to and the benefit of U.S. Provisional Patent

Application Serial No. 61/783,335, entitled "SYSTEMS AND METHODS FOR

FACILITATING LOADING AND MONITORING OF SHIPMENTS" and filed March 14, 2013, the entire disclosure of which is incorporated herein by reference.

Field

[0001] The present application relates generally to the field of transportation management and, more specifically, to systems and methods for facilitating loading carrier shipments and/or monitoring shipments in transit.

Background

[0002] Two of the major participants in the transportation industry are shippers and carriers. Typically a shipper has a need to move goods from one point, the origin, to another point, the destination. The shipper may be a manufacturer, a warehouse owner, or any entity having a reason to ship cargo from an origin to a destination. The origin may be, for example, a manufacturing plant, a warehouse, or a port of entry. The destination may be, for example, another manufacturing plant, a warehouse, a port, or directly to a consignee. The motor freight industry alone carries several million full load shipments per day, e.g., using trucks. Additional shipments are carried by rail, air, and water borne vessels, e.g., trains, planes, and ships, respectively.

Summary

[0003] In accordance with various exemplary embodiments, systems and methods are provided for facilitating loading carrier shipments and/or monitoring carrier shipments in transit.

[0004] One embodiment of the present disclosure relates to an in-transit tracking system that tracks a shipment comprising a vehicle carrying a shipping container. The in-transit tracking system includes logic configured to automatically transmit data to a computer remote from the in-transit shipment, the data indicating whether a closure of the shipping container is closed and whether a lock of the shipping container closure is locked; logic configured to store the data associated with the in-transit shipment; and logic configured to automatically display to a user on an electronic display a corresponding status of the in-transit shipment when the data indicates at least one of (i) the closure of the shipping container is not closed while in-transit and (ii) the lock of the shipping container closure is not locked while in-transit.

[0005] Another embodiment of the present disclosure relates to a computer-implemented method of in-transit tracking of a shipment comprising a vehicle carrying a shipping container. The computer-implemented method includes automatically transmitting data to a computer remote from the in-transit shipment, the data indicating whether a closure of the shipping container is closed and whether a lock of the shipping container closure is locked; storing the data associated with the in-transit shipment; and automatically displaying to a user on an electronic display a corresponding status of the in-transit shipment when the data indicates at least one of (i) the closure of the shipping container is not closed while in-transit and (ii) the lock of the shipping container closure is not locked while in-transit.

[0006] Still another embodiment of the present disclosure relates to a data storage device having a non-transitory machine -readable medium with instructions (e.g., computer executable instructions or instructions interpreted to generate computer executable instructions) stored thereon that cause one or more processors to perform various functions of a process in connection with in-transit tracking of a shipment comprising a vehicle carrying a shipping container. The steps of the process may include automatically transmitting data to a computer remote from the in-transit shipment, the data indicating whether a closure of the shipping container is closed and whether a lock of the shipping container closure is locked; storing the data associated with the in-transit shipment; and automatically displaying to a user on an electronic display a corresponding status of the in-transit shipment when the data indicates at least one of (i) the closure of the shipping container is not closed while in-transit and (ii) the lock of the shipping container closure is not locked while in-transit.

[0007] Yet another embodiment of the present disclosure relates to an in-transit tracking system that tracks a shipment comprising a vehicle carrying a shipping container. The in-transit tracking system includes logic configured to automatically transmit data to a computer remote from the in-transit shipment, the data indicating a location of at least one of the shipping container and the vehicle; logic configured to store the data associated with the in-transit shipment; and logic configured to automatically display to a user a corresponding status of the in-transit shipment when the data indicates that the location of at least one of the shipping container and the vehicle meets at least one predefined characteristic of unacceptable transit.

[0008] Another embodiment of the present disclosure relates to a computer-implemented method of in-transit tracking of a shipment comprising a vehicle carrying a shipping container. The computer-implemented method includes automatically transmitting data to a computer remote from the in-transit shipment, the data indicating a location of at least one of the shipping container and the vehicle; storing the data associated with the in-transit shipment; and automatically displaying to a user a corresponding status of the in-transit shipment when the data indicates that the location of at least one of the shipping container and the vehicle meets at least one predefined characteristic of unacceptable transit.

[0009] Still another embodiment of the present disclosure relates to a data storage device having a non-transitory machine -readable medium with instructions (e.g., computer executable instructions or instructions interpreted to generate computer executable instructions) stored thereon that cause one or more processors to perform various functions of a process in connection with in-transit tracking of a shipment comprising a vehicle carrying a shipping container. The steps of the process may include automatically transmitting data to a computer remote from the in-transit shipment, the data indicating a location of at least one of the shipping container and the vehicle; storing the data associated with the in-transit shipment; and automatically displaying to a user a corresponding status of the in-transit shipment when the data indicates that the location of at least one of the shipping container and the vehicle meets at least one predefined characteristic of unacceptable transit.

[0010] Yet another embodiment of the present disclosure relates to a shipping contents verification system. The shipping contents verification system includes logic configured to receive an electronic signature indicating that a driver of the vehicle has verified that the contents of the shipment match a predetermined list of contents; logic configured to receive an electronic signature indicating that a Customs agent has verified that the contents of the shipment match the predetermined list of contents; logic configured to receive an electronic signature indicating that a third person has verified that the contents of the shipment match the predetermined list of contents, each of the electronic signatures being stored; and logic configured to display on an electronic display at a location remote from the point of loading, data indicating (i) whether the driver of the carrier vehicle has verified that the contents of the shipment match the

predetermined list of contents, (ii) whether the Customs agent has verified that the contents of the shipment match the predetermined list of contents, and (iii) whether the third person has verified that the contents of the shipment match the predetermined list of contents; and logic configured to display on the electronic display at the location remote from the point of loading,

(i) the electronic signature indicating that the driver of the carrier vehicle has verified that the contents of the shipment match the predetermined list of contents, (ii) the electronic signature indicating that the Customs agent has verified that the contents of the shipment match the predetermined list of contents, and (iii) the electronic signature indicating that the third person has verified that the contents of the shipment match the predetermined list of contents.

[0011] Another embodiment of the present disclosure relates to a computer-implemented method of verifying the contents of a shipment at a point of loading. The computer-implemented method includes receiving an electronic signature indicating that a driver of the vehicle has verified that the contents of the shipment match a predetermined list of contents; receiving an electronic signature indicating that a Customs agent has verified that the contents of the shipment match the predetermined list of contents; receiving an electronic signature indicating that a third person has verified that the contents of the shipment match the predetermined list of contents, each of the electronic signatures being stored; displaying on an electronic display at a location remote from the point of loading, data indicating (i) whether the driver of the carrier vehicle has verified that the contents of the shipment match the predetermined list of contents, (ii) whether the Customs agent has verified that the contents of the shipment match the predetermined list of contents, and (iii) whether the third person has verified that the contents of the shipment match the predetermined list of contents; and displaying on the electronic display at the location remote from the point of loading, (i) the electronic signature indicating that the driver of the carrier vehicle has verified that the contents of the shipment match the predetermined list of contents,

(ii) the electronic signature indicating that the Customs agent has verified that the contents of the shipment match the predetermined list of contents, and (iii) the electronic signature indicating that the third person has verified that the contents of the shipment match the predetermined list of contents.

[0012] Still another embodiment of the present disclosure relates to a data storage device having a non-transitory machine -readable medium with instructions (e.g., computer executable instructions or instructions interpreted to generate computer executable instructions) stored thereon that cause one or more processors to perform various functions of a process in connection with verifying the contents of a shipment at a point of loading. The steps of the process may include receiving an electronic signature indicating that a driver of the vehicle has verified that the contents of the shipment match a predetermined list of contents; receiving an electronic signature indicating that a Customs agent has verified that the contents of the shipment match the predetermined list of contents; receiving an electronic signature indicating that a third person has verified that the contents of the shipment match the predetermined list of contents, each of the electronic signatures being stored; displaying on an electronic display at a location remote from the point of loading, data indicating (i) whether the driver of the carrier vehicle has verified that the contents of the shipment match the predetermined list of contents, (ii) whether the Customs agent has verified that the contents of the shipment match the predetermined list of contents, and (iii) whether the third person has verified that the contents of the shipment match the predetermined list of contents; and displaying on the electronic display at the location remote from the point of loading, (i) the electronic signature indicating that the driver of the carrier vehicle has verified that the contents of the shipment match the predetermined list of contents, (ii) the electronic signature indicating that the Customs agent has verified that the contents of the shipment match the predetermined list of contents, and (iii) the electronic signature indicating that the third person has verified that the contents of the shipment match the predetermined list of contents.

[0013] Any of the various systems can be modified to include logic configured to automatically transmit security data to the computer remote from the in-transit shipment, the security data indicating whether a closure of the shipping container is closed and whether a lock of the shipping container closure is locked and/or logic configured to automatically transmit communication data relating to the shipment in response to a person on the vehicle using a user interface while the shipment is in-transit, the communication data indicating that vehicle personnel has communicated a change in status of the shipment. [0014] Any of the various computer-implemented methods can be modified so that the computer-implemented method includes automatically transmitting security data to the computer remote from the in-transit shipment, the security data indicating whether a closure of the shipping container is closed and whether a lock of the shipping container closure is locked and/or automatically transmitting communication data relating to the shipment in response to a person on the vehicle using a user interface while the shipment is in-transit, the communication data indicating that vehicle personnel has communicated a change in status of the shipment.

[0015] Any of the various data storage devices having instructions stored thereon that cause one or more processors to perform various functions of a process can be modified so that the process includes automatically transmitting security data to the computer remote from the in-transit shipment, the security data indicating whether a closure of the shipping container is closed and whether a lock of the shipping container closure is locked and/or automatically transmitting communication data relating to the shipment in response to a person on the vehicle using a user interface while the shipment is in-transit, the communication data indicating that vehicle personnel has communicated a change in status of the shipment.

Brief Description of Drawings

[0016] Figure 1 is a high-level schematic block diagram showing an exemplary system;

[0017] Figure 2 is a medium-level schematic block diagram of an exemplary loading facility;

[0018] Figure 3 A is a schematic top view of a plurality of exemplary loading docks;

[0019] Figure 3B is a schematic front view an exemplary loading dock (shown facing a door of the dock);

[0020] Figure 4 is a schematic diagram of an exemplary loading site sensor system;

[0021] Figure 5 is a schematic representation of an exemplary an exemplary tractor-trailer during transit;

[0022] Figures 6A and 6B are a schematic diagrams of exemplary door sensor systems;

[0023] Figure 6C is a photograph showing a portion of a trailer door and latch;

[0024] Figure 7A is a schematic block diagram of an exemplary control unit for a carrier vehicle; [0025] Figure 7B is a schematic block diagram of an exemplary system with an optional remotely unlockable lock;

[0026] Figure 7C is a schematic diagram of an exemplary control unit for a carrier vehicle;

[0027] Figure 8 is a high-level flow chart showing an exemplary method of pairing devices to deal with the potential of cross-talk between adjacent vehicles;

[0028] Figure 9 is a flow chart showing an exemplary implementation of a method of pairing devices to deal with the potential of cross-talk between adjacent vehicles;

[0029] Figure 10 is a high-level diagram showing the general features built in to an exemplary software application.

[0030] Figure 11 is a high-level diagram showing specific modules and features implemented in the exemplary software application.

[0031] Figure 12 is an exemplary screenshot of a user login page of the exemplary software application.

[0032] Figure 13 is an exemplary screenshot of a home page of the exemplary software application.

[0033] Figure 14 is a high-level diagram showing sub-modules and features implemented in the Logistics module of the exemplary software application.

[0034] Figure 14A is a high-level diagram showing an alternate embodiment of the sub-modules and features implemented in the Logistics module of the exemplary software application.

[0035] Figure 15 is an exemplary screenshot of a Logistics module home page in the exemplary software application.

[0036] Figure 15A is an additional exemplary screenshot of a Logistics module home page in the exemplary software application.

[0037] Figure 16 is an exemplary screenshot of an Available Docks sub-module in the Logistics module of the exemplary software application.

[0038] Figure 16A is an additional exemplary screenshot of Available Docks sub-module in the Logistics module of the exemplary software application. [0039] Figure 17 is an exemplary screenshot of a Dock Details screen in the Logistics module of the exemplary software application.

[0040] Figure 18 is an exemplary screenshot of a Ship Builder sub-module in the Logistics module of the exemplary software application.

[0041] Figure 19 is an exemplary screenshot of a Shipments screen in the Logistics module of the exemplary software application.

[0042] Figure 20 is an exemplary screenshot of a Shipment Details screen in the Logistics module of the exemplary software application.

[0043] Figure 20A is an exemplary screenshot of a Trailer Map feature in the Logistics module of the exemplary software application.

[0044] Figure 21 is a high-level diagram showing sub-modules and features implemented in the Distribution module of the exemplary software application.

[0045] Figure 22 is an exemplary screenshot of a Distribution screen in the Distribution module of the exemplary software application.

[0046] Figure 23 is an exemplary screenshot of a Shipment screen in the Distribution module of the exemplary software application.

[0047] Figure 24 is an exemplary screenshot of a Document Details screen in the Distribution module of the exemplary software application.

[0048] Figure 25 is an exemplary screenshot of a Show Fields screen in the Distribution module of the exemplary software application.

[0049] Figure 26 is a high-level diagram showing sub-modules and features implemented in the Customs module of the exemplary software application.

[0050] Figure 27 is an exemplary screenshot of a Customs screen in the Customs module of the exemplary software application.

[0051] Figure 28 is an exemplary screenshot of a Customs Order Form screen in the Customs module of the exemplary software application. [0052] Figure 29 is a high-level diagram showing sub-modules and features implemented in the Security module of the exemplary software application.

[0053] Figure 30 is an exemplary screenshot of a Security module home page in the exemplary software application.

[0054] Figure 31 is an exemplary screenshot of a 17 Points sub-module in the Security module of the exemplary software application.

[0055] Figure 32 is an exemplary screenshot of a 17 Points Validation screen in the Security module of the exemplary software application.

[0056] Figure 33 is an exemplary screenshot of a Shield sub-module in the Security module of the exemplary software application.

[0057] Figure 34 is an exemplary screenshot of a Shield sign-on screen in the Security module of the exemplary software application.

[0058] Figure 35 is an exemplary screenshot of a Driver specific login screen in the Security module of the exemplary software application.

[0059] Figure 35 A is an exemplary screenshot of a digital signature capture screen in the Security module of the exemplary software application.

[0060] Figure 36 is a high-level diagram showing sub-modules and features implemented in the Monitoring module of the exemplary software application.

[0061] Figure 37 is an exemplary screenshot of a Monitoring module home page in the exemplary software application.

[0062] Figure 38 is an exemplary screenshot of a Shipment Status sub-module in the Monitoring module of the exemplary software application.

[0063] Figure 39 is an exemplary screenshot of a Shipment Details screen in the Monitoring module of the exemplary software application.

[0064] Figure 40 is an exemplary screenshot of a Times screen in the Monitoring module of the exemplary software application. [0065] Figure 41 is an exemplary screenshot of a Map View screen in the Monitoring module of the exemplary software application.

[0066] Figure 41 A is an additional exemplary screenshot of a Map View screen in the

Monitoring module of the exemplary software application.

[0067] Figure 4 IB is an exemplary screenshot of a Truck Dashboard screen in the Monitoring module of the exemplary software application.

[0068] Figure 42 is an exemplary screenshot of a Warehouse screen in the Monitoring module of the exemplary software application.

[0069] Figure 43 is an exemplary screenshot of a Shipment screen in the Monitoring module of the exemplary software application.

[0070] Figure 43A is an exemplary screenshot of a Signs screen in the Monitoring module of the exemplary software application.

[0071] Figure 44 is a high-level diagram showing sub-modules and features implemented in the Administrator module of the exemplary software application.

[0072] Figure 44A is a high-level diagram showing sub-modules and features implemented in the Management module of the exemplary software application

[0073] Figure 45 is an exemplary screenshot of an Administrator module home page in the exemplary software application.

[0074] Figure 46 is an exemplary screenshot of a Producer screen in the Administrator module of the exemplary software application.

[0075] Figure 47 is an exemplary screenshot of a Producer List screen in the Administrator module of the exemplary software application.

[0076] Figure 48 is a high-level logic diagram for an exemplary portable application for the 17 Points sub-module in the Security module.

[0077] Figure 49 is a high-level logic diagram for an exemplary portable application for the Shield sub-module in the Security module. [0078] Figure 50 is a high-level logic diagram for an exemplary portable application for a user to create and send alerts as part of the Monitoring module.

[0079] Figure 51 shows a flow chart of the steps involved in creating a geo fence for an exemplary route as part of the Logistics module and/or Monitoring module.

[0080] Figure 52 illustrates at a high level an exemplary plurality of modules implemented in a portable application.

[0081] Figure 53 is a schematic block diagram of an exemplary server.

[0082] Figure 54 is a schematic block diagram of an exemplary server memory.

[0083] Figure 55 is a schematic block diagram of an exemplary computer for use by various users of the various systems and methods herein.

Detailed Description

[0084] The specification and accompanying drawings illustrate exemplary embodiments of the invention and exemplify general principles of the invention.

[0085] Referring generally to the drawings, and initially to Figure 1 , a first exemplary embodiment of a system 10 for facilitating loading carrier shipments and monitoring carrier shipments in transit is shown. System 10 includes one or more shippers 12 in communication with a server 14 via one or more communications systems 16, such as the Internet. The server 14 is also in communication with at least one control unit on each of a plurality of carrier vehicles 18 that haul, pull, or carry (collectively, "carry") shipping containers 19.

[0086] "Shipping containers" as used herein is used generically and refers to any containers in which goods are carried and includes but is not limited to semi-trailers and intermodal freight containers (a/k/a simply "intermodal containers").

[0087] In one embodiment, the type of "communication" referenced above in relation to System 10 may be a "Circuit communication" type. Circuit communication as used herein is used to indicate a communicative relationship between devices. Direct electrical, optical, and electromagnetic connections and indirect electrical, optical, and electromagnetic connections are examples of circuit communication. Two devices are in circuit communication if a signal from one is received by the other, regardless of whether the signal is modified by some other device. For example, two devices separated by one or more of the following— satellites, routers, gateways, transformers, optoisolators, digital or analog buffers, analog integrators, other electronic circuitry, fiber optic transceivers, etc.— are in circuit communication if a signal from one reaches the other, even though the signal is modified by the intermediate device(s). As a final example, two devices not directly connected to each other (e.g. keyboard and memory), but both capable of interfacing with a third device, (e.g., a CPU), are in circuit communication.

[0088] Carrier vehicles 18 are shown in Figure 1 as trucks, but they may be any one or more of road, rail, air, or water borne vehicles. The carrier vehicles 18 may communicate with the server 14 via multiple communications protocols, e.g., via General Packet Radio Service ("GPRS") 22 and the Internet 16, or via other protocols such as Code Division Multiple Access ("CDMA"), Long-term Evolution ("LTE"), WiFi, and Worldwide Interoperability for Microwave Access ("WiMax"). A GPRS gateway can be used to communicate GPRS data to the server 14 via the Internet 16. A plurality of users 20 use user computers access data pertaining to the shipments from the server 14 via one or more communications protocols, e.g., via the Internet 16.

Communications can be wired communications, wireless communications, or a combination of wired and wireless communications.

[0089] The server 14 facilitates loading carrier shipments and monitoring carrier shipments while in transit. As will be discussed below, the server 14 includes one computer system or a plurality of computer systems in communication to receive loading data from shippers 12 and monitoring data from the carrier vehicles 18 and selectively present data to users 20 to facilitate loading carrier shipments and monitoring carrier shipments. For example, the server 14 may include a loading server (receiving loading data and presenting data to loading users) in communication with a monitoring server (receiving monitoring data and presenting data to monitoring users). Alternatively, the server 14 can perform the functions of both a loading server and a monitoring server. As discussed in more detail below, the loading data received by the server 14 may include any one or more of the following: the contents of shipping containers; the identification numbers of carrier vehicles; identification information of drivers, pilots, or crew of carrier vehicles; verification data (verification that the shipping container contains the listed contents); inspection data (e.g., results of an inspection of the carrier vehicle and/or results of an inspection of the shipping container and/or results of an inspection of goods being shipped); whether a particular loading dock is available to be used for loading; etc. As additionally discussed in more detail below, the monitoring data received by the server 14 may include any one or more of the following: carrier vehicle data (e.g., location of the carrier vehicle, engine temperature, engine pressure, and/or other vehicle parameters, etc.); shipment data (e.g., location of the shipping container, open/closed status of one or more openings of the shipping container, temperature of the shipping container, and/or other vehicle parameters, etc.); and/or vehicle driver data (e.g., status of user inputs such as "panic" button and/or "at Customs, expect delay" button, etc.), etc.

[0090] Referring now to Figure 2, an exemplary loading facility 30 of a shipper 12 is shown. Loading facility 30 may include a plurality of loading sites 32, e.g., loading docks, in

communication with a loading server 34 via one or more networks, such as the Internet 16. The loading server 34 may be a portion of server 14 or one of a plurality of interconnected computer systems forming server 14. Each dock 32 provides loading data to the loading server 34. More specifically, each dock provides a signal 36 indicating whether that particular loading dock is available to be used for loading. The signals 36 are transmitted to the loading server 34 via one or more networks, such as the Internet 16. Each dock 32 can send its own respective signal 36 indicating whether that particular loading dock is available to be used for loading, as shown in Figure 2. As shown in that figure, each loading dock transmits a signal (e.g., an 802.11 signal, an 802.15.4 signal, a GPRS signal, a CDMA signal, an LTE signal, WiMax signal, or some other wireless or wired signal) to a router, and the signals are routed to the loading server 34. In exemplary embodiments, each dock 32 sends real-time data indicating whether that particular loading dock is available to be used for loading. As used herein, the term "real-time data" means data that is used, stored, or transmitted for use or storage at the same time it is being generated or promptly after it is generated. Real-time data is transmitted often enough to influence a process accepting the real-time data as an input used by the process. For example, each dock 32 can generate and promptly transmit every 10 seconds its respective data indicating whether that particular loading dock is available to be used for loading. This is considered to be real-time data for purposes of facilitating loading a shipment. Shorter transmission periods would obviously also be considered to be real-time data. Transmission periods as slow as once every 2 to 5 minutes may also be considered to be in real time for purposes of facilitating loading a shipment. As another example, data about the open/closed state of a shipping container can be transmitted to the vehicle control unit once about every 2 seconds, which may be considered to be real-time data for purposes of monitoring a shipment. Shorter transmission periods may also be considered to be real-time data. Transmission periods as slow as once every 1 or 2 minutes may also be considered to be in real-time for purposes of monitoring a truck shipment expected to take at least 1 hour. In the alternative to each dock 32 sending its own respective real-time data signal 36 to the loading server 34 as discussed above, real-time data about whether a plurality of docks are available to be used for loading can be collected by a local control unit (not shown) and transmitted to the loading server 34 together in real-time.

[0091] With further reference to Figure 2, the loading server 34 also can receive verification data from the loading facility 30, which verification data indicates that the shipping container contains the listed contents. The verification data will typically be generated by one or more verification personnel 40 who are present at the time a shipping container 19 is loaded and thus can verify that the shipping container has been loaded with the contents listed on the manifest or shipping or packaging list. Exemplary verification personnel include any one or any two or more of the following: security personnel of the loading facility 30, Customs officials, and the driver of the carrier vehicle 18 (C-D-S in Figure 3 A), and/or other trusted individuals. In an embodiment, the verification personnel 40 can send a signal 42 having verification data from a location proximate the vehicle 18 being loaded. Thus, the verification personnel 40 can transmit real-time verification data to the loading server 34. In this case, the verification personnel 40 may use a portable computer, such as a tablet computer (e.g., an iPad) or a smart phone (e.g., an iPhone), executing an application permitting the verification personnel 40 to verify the contents of a particular shipment. The application executing on the portable computer may, for example, permit verification personnel 40 to select a shipment, enter a user identifier (e.g., a user name), and enter a user authorization code (e.g., a PIN or other password) to verify the contents of the shipment. In response, the portable computer will transmit to the loading server 34 the signal 42, which may be a wireless signal (such as an 802.11 signal) sent via a router 68 (Figure 3A). The verification data may include either a binary verification (e.g., a Yes/No response), or a detailed verification, or a combination of both. A detailed verification may include one or more fields of verified data. For example, the verified data fields may include a Shipment Number, an

Inspection Number, a Checkpoint Result (e.g., Y/N, or T/F), and Notes (or some other free-text field). In the alternative, the verification personnel 40 can verify that the shipping container has been loaded with the contents listed on the manifest or shipping or packaging list and then move to a different location where there is a computer system or other communication device with which the verification personnel 40 can transmit the verification data signal 42 to the loading server 34.

[0092] With further reference to Figure 2, the loading server 34 also can receive inspection data from the loading facility 30, which inspection data indicates that the shipping vehicle has been inspected and has passed certain inspection criteria and/or indicates that the shipping container has been inspected and has passed certain inspection criteria. The inspection data will typically be generated by one or more inspection personnel 44 who have access to the shipping vehicle and/or the shipping container to perform the inspection(s). In an exemplary embodiment, the inspection personnel 44 can send a signal 46 having inspection data from a location proximate the vehicle 18 that will be loaded. Thus, the inspection personnel 44 can transmit real-time inspection data to the loading server 34. In this case, the inspection personnel 44 may use a portable computer, such as a tablet computer (e.g., an iPad) or a so-called smart phone (e.g., an iPhone), executing an application facilitating the inspection(s) by the inspection personnel 44. The application executing on the portable computer may, for example, permit inspection personnel 44 to select a shipment and display an inspection checklist for the vehicle and/or the container. After the inspection, the portable computer will transmit to the loading server 34 the signal 46, which may be a wireless signal (such as an 802.11 signal) sent via a router 68 (Figure 3A). The inspection data may include either a binary verification of the inspection (e.g., a Yes/No response, or a Pass/Fail response), or a detailed verification of the inspection, or a combination of both. A detailed verification of the inspection may include one or more fields of inspected data. For example, the inspected data fields may include a Shipping Vehicle Number, a Shipping Container Number, an Inspection Number, one or more Inspection Data field values, and Notes (or some other free-text field). In the alternative, the inspection personnel 44 can inspect the shipping vehicle and/or container and then move to a different location where there is a computer system or other communication device with which the inspection personnel 44 can transmit the inspection data signal 46 to the loading server 34.

[0093] One or more loading users 38 (users at the loading facility 30) can use loading user computers to view loading data via loading server 34 to facilitate loading shipments. For example, a loading user 38 can view in a user interface real-time data indicating which loading sites 32 are available to be used for loading and, in response, direct a carrier vehicle to a loading site 32 that is currently available to be used for loading. As another example, a loading user 38 can view in a user interface real-time data indicating whether a vehicle and/or container has passed its inspection as a condition precedent to permitting the shipment to depart from the loading facility. As still another example, a loading user 38 can view in a user interface realtime data indicating whether the contents of a shipping container have been verified as a condition precedent to permitting the shipment to depart from the loading facility. In this sense, server 14 and loading server 34 are real-time systems. As used herein, the term "real-time system" means a computer system in which the computer(s) perform tasks within time restraints of a process or simultaneously with the system it is assisting. The time restraints of the process or the system are either limited by the software and/or hardware limitations of the process and/or the system itself, or in the alternative, the time restraints may be set up as part of the system 10. If the time restraints are set up as part of the system 10, said restraints may be set up by any user, e.g. users 20. Additionally, the loading server can be configured to permit other users 50 (users not at the loading facility 30, e.g., recipients of the shipment) to use other user computers to view any or all of the loading data via the loading server 34, e.g., via the Internet 16. Carrier vehicles 18 are shown and described herein as trucks, but they may be any one or more of road, rail, air, or water borne vehicles. Similarly, loading sites 32 are shown and described herein as docks for loading trucks, but they may be respective loading sites for any one or more of road, rail, air, or water borne vehicles.

[0094] Referring now to Figures 3A-3B, exemplary loading sites 32 are shown. In the context of these examples, the loading sites include one or more docks for loading trucks 18 having associated trailers 19. Each dock 32 has associated therewith an exemplary sensor system 60 having a sensing region 62 positioned to detect the presence of a truck at the loading dock 32. A trailer 19 (or other object) being sensed in the sensing region 62 of sensor system 60 indicates that that particular loading dock 32 is not available to be used for loading. In contrast, the absence of any trailer 19 (or other object) being sensed in the sensing region 62 of sensor system 60 tends to indicate that that particular loading dock is available to be used for loading (there may still be something outside the sensor region 62 preventing that dock from being used). Each sensor system 60 may have an associated transmitter 63 permitting the exemplary sensor system 60 to transmit sensor data to the loading server 34. For example, as shown in Figures 3A-3B, the sensor system 60 can be configured to transmit a wireless signal 64 (e.g., an 802.11 signal, an 802.15.4 signal, a GPRS signal, a CDMA signal, an LTE signal, WiMax signal, or some other wireless signal) to an internet modem or router 68, which retransmits the signal toward the loading server 34 via signal 36 and via the Internet 16. In Figure 3A, sensor systems 60a and 60c would be transmitting signals 64a, 64c, respectively, indicating that a trailer 19 (or other object) is positioned at their respective dock 32a, 32c, and those docks 32a, 32c are unavailable. In contrast, sensor system 60b would be transmitting signal 64b indicating that nothing is being detected at its respective dock 32b and that dock 32b is presumably available to back up an empty trailer 19 for loading. In Figure 3B, the signal 36 is shown being sent via the Internet to a database (cloud stored) 70, which can form part of the loading server 34.

[0095] Figure 4 shows an exemplary embodiment of the loading site sensor system 60 and transmitter 63. Exemplary sensor system 60 and transmitter 63 include a sensor 80, a local power supply 82, an opto-isolator 84, a transmitter chip 86, and associated hardware, which may be connected as shown in Figure 4. In an exemplary embodiment, transmitter chip 86 comprises a Wifly (from Roving Networks), which transmits via 802.11. The sensor 80 can be an optical diffuse sensor (e.g., part number CX3-AP-1 A from Automation Direct) having a sensing region 62 (shown schematically in Figures 3A-3B) that is positioned to detect the presence of a trailer at the loading dock 32 and outputs a corresponding sensor signal 90. The sensor 80 can be positioned on a post 92 (Figure 3A) to offset the sensor from the dock 32. The transmitter 86 is pre-programmed to accept the opto-isolated data signal 92 and transmit a corresponding signal 64 directed toward the loading server 34, which signal 64 can be an 802.11 wireless signal in this exemplary embodiment. The transmitter chip 86 is also pre-programmed to connect to an specific WiFi network (can be open or password protected), auto connect to said network when powered up, send a customized string to a database on a desired interval (with the information of its inputs). Each dock availability server 60 can be programmed to periodically transmit its respective availability status, such as every n seconds (e.g., every 10 seconds) or every occurrence of a user-defined period.

[0096] For monitoring shipments during transit, the carrier vehicle and shipping container have been modified to collect and transmit to the server 14 (or a separate monitoring server) in real time monitoring data such as any one or more of the following: carrier vehicle data (e.g., location of the carrier vehicle, engine temperature, engine pressure, and/or other vehicle parameters, etc.); shipment data (e.g., location of the shipping container, open/closed status of one or more openings of the shipping container, temperature of the shipping container, and/or other vehicle parameters, etc.); and/or vehicle driver data (e.g., status of user inputs such as "panic" button and/or "at Customs, expect delay" button, etc.), etc. Thus, the carrier vehicle and the shipping container will have one or more associated control units in communication with the server 14 (or a separate monitoring server).

[0097] Referring to Figure 5, an exemplary carrier vehicle and shipping container (here a tractor 18 and trailer 19) are shown in transit. The exemplary tractor 18 has a control unit 100 that determines the location of the shipment and sends it and other information to the server 14 (or a separate monitoring server) in real time via a signal 101, e.g., via a GPRS wireless signal. The exemplary trailer has a door integrity sensor system 102 that detects whether the door of the trailer 19 is still closed and/or latched and communicates that information to the control unit 100 in real time via a signal 103, e.g., via an 802.15.4 (a/k/a "Zigbee") wireless signal, for transmission to the server 14 (or a separate monitoring server) by the control unit 100 in real time.

[0098] The door integrity sensor system 102 can use an active sensor (having, e.g., power, ground, and output signals), or a passive sensor (having, e.g., two leads and either making or breaking an electrical connection between the two leads), or both an active sensor and a passive sensor. Figure 6A shows an exemplary door integrity sensor system 102 having a local transmitter 104 (local in the sense that it transmits to the vehicle) and an active sensor 110. Exemplary door integrity sensor system 102 includes active sensor 110, a local power supply 112, an opto-isolator 114, a transmitter chip 116, and associated hardware, which may be connected as shown in Figure 6A. The local transmitter 104 can be the transmitter of a bidirectional transceiver. The sensor 110 can be any of a number of active sensors, e.g., an inductive sensor sensing magnetic materials, such as iron and steel (e.g., sensor part number PY4-AP-1 A from Automation Direct) and outputting a corresponding sensor signal 120. The transmitter 116 is pre-programmed to accept the opto-isolated data signal 122 and transmit a corresponding signal 103 directed toward the loading server 34, which signal 103 can be an 802.15.4 (a/k/a "Zigbee") wireless signal in this exemplary embodiment. In the alternative, an 802.11 signal, an 802.15.4 signal, a GPRS signal, a CDMA signal, an LTE signal, WiMax signal, or some other wireless signal can be used. The transmitter chip 116 is also preprogrammed to connect to an specific Personal Area Network, sample an input each time an specified period of time has passed, send the sampled values to the GPS attached device each time an specified period of time has passed. The active sensor 110 can be positioned in any of a number of locations to detect whether the door of the shipping container is closed and/or latched, e.g., positioned to detect whether a hook is securing the door of a typical trailer 19 (Figure 6C) or whether the trailer is locked. The rest of the circuitry in Figure 6A can be positioned, for example, inside the shipping container, i.e., mounted inside trailer 19. Each door integrity sensor system 102 can be programmed to periodically transmit its respective door status, such as every n seconds (e.g., every 2 seconds) or every occurrence of a user-defined period.

[0099] Figure 6B shows another exemplary door integrity sensor system 102 using a passive sensor 130. Exemplary door integrity sensor system 102 includes passive sensor 130, a local power supply 132, a transmitter chip 136, and associated hardware, which may be connected as shown in Figure 6B. The sensor 130 can be any of a number of passive sensors, e.g., "make"- type switch sensors that are normally open or "break"-type switch sensors that are normally closed outputting a corresponding sensor signal 140. The transmitter 136 is pre-programmed to accept the data signal 140 and transmit a corresponding signal 103 directed toward the loading server 34. Signal 103 can be an 802.15.4 (a/k/a "Zigbee") wireless signal in one exemplary embodiment. In the alternative, an 802.11 signal, an 802.15.4 signal, a GPRS signal, a CDMA signal, an LTE signal, WiMax signal, or some other wireless signal can be used. The transmitter chip 136 is also pre-programmed to connect to a specific Personal Area Network, sample an input each time an specified period of time has passed, send the sampled values to the GPS attached device each time an specified period of time has passed. The passive sensor 130 can be positioned in any of a number of locations to detect whether the door of the shipping container is closed and/or latched, e.g., positioned in a place close enough to the door, in such a way that it opens or closes the contact in the switch/reed switch when it is opened or closed. The rest of the circuitry in Figure 6B can be positioned, for example, inside the shipping container, i.e., mounted inside trailer 19.

[0100] As mentioned above, an exemplary door sensor system 102 may have both one or more active sensors (positioned, for example, in any one or more of the exemplary locations mentioned above) and one or more passive sensors (positioned, for example, in any one or any two or more of the exemplary locations mentioned above) to detect whether the door of the shipping container is closed and/or latched. The signals from those sensors could each have a dedicated transmitter for communication of the door status to the control unit 100 or two or more of the sensor signals can use the same transmitter for communication of the door status to the control unit 100 (the XBEE-1 chip used in Figures 6 A and 6B can accept multiple inputs for transmission via the same wireless signal 103). Additionally, the circuitry for the shipping container can also include additional sensors that measure parameters pertinent to the shipping container, e.g., the temperature inside a trailer 19 or inside a cooled enclosure (not shown) inside a trailer 19. Signals from such sensors could also be sent to the control unit 100 via the transmitter 116, 136 in real time and relayed from the control unit 100 to the monitoring server or the loading server in real time.

[0101] Referring now to Figure 7 A, an exemplary control unit 100 is shown. The control unit 100 includes a processor 150 in communication with a vehicle driver interface 152, a local receiver 154, a location receiver 156, and a transmitter 158 and, optionally, one or more vehicle sensors 160. In short, the local receiver 154 of the control unit 100 receives container data (e.g., door open/closed, door latched/unlatched, temperature of container, etc.) from the local transmitter 104 via the signal 103, which is preferably a wireless signal, as discussed above. The local receiver 154 can be a receiver of a bidirectional transceiver. The processor 150 of the control unit 100 has code causing it to obtain the container data from the local receiver 154 and transmit that container data to the monitoring server via the transmitter 158. More specifically, transmitter 158 transmits signal 101 having the container data toward the monitoring server, e.g., via GPRS and then via the Internet (Figures 1, 5, and 7A). The transmitter 158 can be a transmitter of a bidirectional transceiver.

[0102] The location receiver 156 receives location signals 170 transmitted from location transmitters 172, e.g., global positioning system (GPS) satellites, long range navigation

(LORAN) transmitters, or other transmitters, from which the location of the vehicle 18 and/or the container 19 is determined. The location receiver 156 may also receive location signals 170 by way of triangulating cellular signals or other emitted from (or transmitted to) the vehicle 18 and/or the container 19. The location receiver 156 can be a receiver of a bidirectional transceiver. The processor 150 of the control unit 100 obtains the location data from the location receiver 156 and transmits that location data to the monitoring server via the transmitter 158. More specifically, transmitter 158 transmits signal 101 having the location data toward the monitoring server, e.g., via GPRS and then via the Internet (Figures 1, 5, and 7A). The processor 150 has code causing the processor 150 to obtain location data from the location receiver 156 and transmit to the server with the transmitter 158 the vehicle location data.

[0103] The vehicle driver interface 152 contains one or more means for obtaining input from the driver of the vehicle 18 carrying the container 19. For example, the vehicle driver interface 152 may contain a pushbutton with which the driver would indicate that the vehicle has entered a Customs area and those monitoring the shipment should expect a delay. As another example, the vehicle driver interface 152 may include a "Panic button" with which the driver can indicate that the driver needs assistance or is in peril. Such pushbuttons would be in communication with the processor 150 and vehicle driver data obtained by the processor from the vehicle driver interface 152 would be passed on to the monitoring server via the transmitter 158. More specifically, transmitter 158 transmits signal 101 having the vehicle driver data toward the monitoring server, e.g., via GPRS and then via the Internet (Figures 1, 5, and 7A). Of course other user interface devices could be placed in communication with the processor 150, e.g., a keyboard, a keypad, and/or a touch screen, etc., and vehicle driver data from those devices would be transmitted to the monitoring server, as discussed above. The processor 150 has code for each device in the vehicle driver interface 152 causing the processor 150 to implement the device, obtain vehicle driver data from the device, and transmit with the transmitter 158 vehicle driver data.

[0104] The vehicle driver interface 152 may also include one or more means for communicating with the driver that are in communication with the processor 150, e.g., one or more message lights and/or a visual display such as an n rows by m columns textual display or a graphical display displaying information to the driver as icons or words on the display. The processor 150 has code for each such device causing the processor 150 to implement the device and display information to the driver via the device. For example, the vehicle driver interface 152 may include one or more message light, e.g., an LED that automatically indicates, when illuminated, that the container is open or unlatched (as indicated by the container data received by the local receiver 154). Optionally, the transmitter 158 can be a configured as a transceiver that also receives data from a monitoring user of the system, e.g., via the Internet and GPRS. Thus, the processor 150 could obtain via transceiver 158, for example, a command from the monitoring user to disable the vehicle. Disabling the vehicle may include simply shutting off the vehicle's ignition or perhaps decelerating the vehicle and then shutting off the vehicle's ignition using a vehicle control circuit 160 in communication with the engine. In addition, or in the alternative, the processor 150 could obtain via transceiver 158, for example, received data causing the processor 150 to communicate a message from the monitoring user to the vehicle driver via the vehicle driver interface 152, e.g., present a textual message from the monitoring user to the driver. As another example, the processor 150 could obtain via transceiver 158, for example, a command from the monitoring user to illuminate a particular message light on the vehicle driver interface 152 (such as a message light indicating that the vehicle driver is to phone a dispatcher). In these cases, the computer system used by the monitoring user would have a user interface permitting the monitoring user to send data to the processor 150 on the vehicle 18 in question causing the processor 150 to perform one or more of the foregoing actions.

[0105] The control unit optionally includes one or more vehicle sensors 160 in communication with the processor 150 that sense one or more parameters of the vehicle and transmit vehicle data to the processor 150 corresponding to the sensed parameter(s). For example, sensors detecting any one or more of the following may be in communication with the processor 150: door sensors, generating data indicating the open or closed status of any of the doors of the particular vehicle 18; and/or an engine temperature sensor, generating data corresponding to the temperature of the engine of the particular vehicle 18 (or data indicating whether the temperature of the engine has exceeded a particular upper or lower threshold); and/or an engine pressure sensor, generating data corresponding to the pressure of the engine of the particular vehicle 18 (or data indicating whether the pressure of the engine has exceeded a particular upper or lower threshold); etc. The processor 150 has code for each such device causing the processor 150 to obtain data from the device and transmit that data to the server. Such vehicle data obtained by the processor 150 from the vehicle sensors 160 would be passed on to the monitoring server via the transmitter 158. More specifically, transmitter 158 transmits signal 101 having the vehicle data toward the monitoring server, e.g., via GPRS and then via the Internet (Figures 1, 5, and 7A).

[0106] Figure 7B shows an exemplary system 200 with an optional remotely unlockable lock 202. The remotely unlockable lock 202 has a shackle 204, which secures the container 19 containing the shipment. Control unit 100' can be substantially the same as described above with respect to control, unit 100 in Figure 7A, except that the transmitter 154 in Figure 7A is a transceiver 154' in Figure 7B and the processor 150 will have code causing the control unit 100' to interact with the remotely unlockable lock 202 based on instructions received from the monitoring user or on its own in certain circumstances, as discussed below. In general, the remotely unlockable lock 202 has at least a receiver in communication with a shackle release, which is operatively connected to the shackle 204, e.g., coupled to a catch (not shown) retaining the shackle 204. The transceiver 154' receives an external signal to release the shackle 204 and generates a signal causing the shackle release 210 to release the shackle 204, e.g., release the catch retaining the shackle, which permits a user to manually move or remove the shackle to permit the container 19 to be opened. Thus, in certain circumstances, discussed below, the processor 150 will cause a local transmitter to transmit a signal to the receiver, which receives the signal and generates a signal causing the shackle release to release the shackle 204, e.g., release the catch retaining the shackle.

[0107] The remotely unlockable lock 202 shown in Figure 7B includes a processor 208 in communication with a local transceiver 206, a shackle release 210, a shackle sensor 212, and, optionally, a shackle actuator 214. The processor 208 has code causing the processor to interact with the local transceiver 206, the shackle release 210, the shackle sensor 212, and, optionally, the shackle actuator 214. The processor 208 can be integral with the local transceiver 206, e.g., an XBEE programmable transceiver. The local transceiver 206 receives an external signal 220 to release the shackle 204 and indicates via signal 221 to the processor 208 the reception of the signal 220. In response, the processor 208 causes the shackle release 210 to release the shackle 204, e.g., release a catch (not shown) retaining the shackle 204, which permits a user to move or remove the shackle 204 to permit the container 19 to be opened. The shackle release 210 can be, for example, a solenoid or motor and gear train (all not shown) operatively coupled to the shackle 204 or the catch retaining the shackle. The processor 208 of the remotely unlockable lock 202 has code causing it to receive the signal 221 and interact with the shackle release 210, as described above.

[0108] The shackle sensor 212 interacts with the shackle and generates one or more signals 222 to indicate to the processor 222 when the shackle 204 is in a locking position and/or when the shackle 204 is in a position permitting the container 19 to be opened. The shackle sensor 212 can be, for example, an inductive sensor, or a magnetic sensor, or the shackle can complete a circuit that will be electrically disconnected ("broken") when the shackle is removed. The processor 208 of the remotely unlockable lock 202 has code causing it to receive the signal 221 and transmit shackle status data to the control unit 100' monitoring server via the local transceiver 206. The processor 150 of the control unit 100' has code causing it to obtain the shackle status data from the local transceiver 206 and transmit that shackle status data to the monitoring server via the transmitter 158 (Figure 7A).

[0109] As discussed above, the shackle release 210 selectively releases the shackle 204 in response to the signal 202 and the processor 208, which permits a user to manually move or remove the shackle to permit the container 19 to be opened. In addition, or in the alternative, the remotely unlockable lock 202 can have a shackle actuator 214 operative ly connected to the shackle to physically move or remove the shackle 204 to permit the container 19 to be opened in response to the signal 220 and the processor 208. In response to the signal 221 from the local transceiver 206, the processor 208 causes the shackle actuator 214 to physically move or remove the shackle 204 to permit the container 19 to be opened (perhaps after causing the shackle release 210 to release the shackle 204, e.g., release a catch (not shown) retaining the shackle 204, which permits the shackle actuator 214 to move or remove the shackle 204 to permit the container 19 to be opened). The shackle actuator 214 can be, for example, a solenoid or motor and gear train (all not shown) operatively coupled to the shackle 204. The processor 208 of the remotely unlockable lock 202 has code causing it to receive the signal 221 and interact with the shackle actuator 214, as described above.

[0110] Optionally, in system 200, the vehicle driver interface 152 (Figure 7A) permits the driver to attempt to unlock the remotely unlockable lock 202, e.g., via button or menu selection (not shown). As discussed below, the processor 150 of control unit 100' is programmed in such a way that processor 150 may or may not permit the driver to unlock the remotely unlockable lock 202 using the vehicle driver interface 152, depending on various factors, e.g., the geographic location of the vehicle 18 and/or the geographic location of the container 19.

[0111] Figure 7C shows an exemplary implementation of an exemplary control unit 100, showing processor 150 (a preprogrammed ATMEGA328P processor) and transceiver 154' (a preprogrammed XBEE transceiver). Connector GPS COM in the particular implementation of Figure 7C connects to a SKYPATROL brand TT8750 Vehicle GPS Tracking Device, which implements a GPS receiver (implementing location receiver 156 of Figure 7A as a GPS receiver) and a GPRS transceiver (implementing transmitter 158 of Figure 7 A as a GPRS transceiver). The ATMEGA328P processor is preprogrammed as discussed herein. [0112] The processor 150 is programmed to communicate with the server via transceiver 158, as discussed above and as discussed in more detail below, to receive data about the shipment, e.g., data about the vehicle 18, data about the container 19, data about the remotely unlockable lock 202, data from the driver via vehicle driver interface 152, and data about the location of the vehicle/container and transmit that data to the server via transmitter 158. The processor 150 is also programmed to communicate with the server via receiver of transceiver 158, as discussed above and as discussed in more detail below, to receive and affect commands from the server, e.g., commands to release or secure the remotely unlockable lock 202, commands to affect the vehicle 18 (e.g., disable the ignition), communicate with the driver, etc.

[0113] In addition, or in the alternative, the processor 150 can be programmed with various functions to be executed independently from the remote server, e.g., in case the communication link 101 between the control unit 100, 100' and the remote server is lost. For example, the control unit 100, 100' can be programmed with any one or any combination of any two or more of the following independently of the remote server:

A. The control unit 100, 100' can be programmed to prevent the remotely unlockable lock 202 from being unlocked unless and until the location data from location receiver 156 indicates that the vehicle/container has (i) reached, crossed, or left a particular location, (ii) reached, crossed, or left a particular geographic line or (iii) reached, crossed, or left a particular geographic area.

B. The control unit 100, 100' can be programmed to disable the vehicle 18, e.g., disable the ignition of the vehicle 18 when the location data from location receiver 156 indicates that the vehicle/container has (i) reached, crossed, or left a particular location, (ii) reached, crossed, or left a particular geographic line or (iii) reached, crossed, or left a particular geographic area.

C. The control unit 100, 100' can be programmed to send an alert/message until/when the location data from location receiver 156 indicates that the vehicle/container has (i) reached, crossed, or left a particular location, (ii) reached, crossed, or left a particular geographic line or (iii) reached, crossed, or left a particular geographic area.

D. The control unit 100, 100' can be programmed to make a phone call until/when the location data from location receiver 156 indicates that the vehicle/container has (i) reached, crossed, or left a particular location, (ii) reached, crossed, or left a particular geographic line or (iii) reached, crossed, or left a particular geographic area.

E. The control unit 100, 100' can be programmed to automatically unlock the unlockable lock 202 when location data from location receiver 156 indicates that the

vehicle/container has (i) reached, crossed, or left a particular location, (ii) reached, crossed, or left a particular geographic line or (iii) reached, crossed, or left a particular geographic area (e.g., once the vehicle/container has reached the location of the shipping destination).

F. The control unit 100, 100' can be programmed to send an alert/message in response to a speed limit reached by the Vehicle 18 and/or Container 19.

G. The control unit 100, 100' can be programmed to send an alert/message in response to the door on Vehicle 18 and/or Container 19 being opened.

[0114] As discussed below, a monitoring user user-interface can be implemented to permit a monitoring user to select which, if any, of the above actions the control unit 100, 100' will be permitted to perform independently of the remote server. Such a user-interface can also provide a graphical user interface or other interface to permit a monitoring user to define the specific geographic points, geographic lines, and/or geographic areas to be used by the control unit 100, 100' to trigger actions independently of the remote server.

[0115] Additionally, if the control unit 100, 100' determines that the communication link 101 between the control unit 100, 100' and the remote server 14 has been lost, the control unit 100, 100' can keep receiving data from the various sensors and storing that data to memory, and later transmit that stored data to the server 14 once the communication link is reestablished.

[0116] As described above, each container 19 is supposed to communicate with its own respective vehicle, and vice versa, using local transmitters, local receivers, and/or local transceivers. Applicants have realized that with many vehicles 18 using the systems and methods described herein proximate one another (e.g., in slow traffic or stopped traffic or simply because two vehicles are driving near one another such as in adjacent lanes), there is the potential for cross-communication between a vehicle 18 and a container 19 of a different vehicle 18. For example, in Figure 1, the vehicles 18a, 18b are positioned such that the left end of the lower container 19a is closer to the upper tractor 18b than the lower tractor 18 a; therefore, the signal 103 from the lower container 10a will likely be stronger at the upper tractor 18b than the lower tractor 18a, which presents the possibility of cross-talk if vehicles are using the same or overlapping frequencies. Such cross-talk has the potential to seriously interfere with effective communication between a vehicle 18 and its respective container 19.

[0117] One way to avoid the risks of cross-talk is to accept cross-talk and simply permit any vehicle to transmit to the remote server any data it receives from any signal 103 from any container 19 and transmit that data to the remote server and have the software sort out which data corresponds to which shipment using a unique ID for each container 19. For example, in the implementations discussed herein, XBEE modules are used to generate the Zigbee wireless communication protocol for local communications. Every XBEE module (and each of the other known Zigbee protocol modules) has a unique ID number, which can be transmitted as part of each transmission via signal 103 and then further transmitted to the remove server via signal 101. Software at the server level will associate particular ID numbers of the various containers 19 with respective vehicles 18 and respective shipments so that data received at the server can be properly stored in the server and associated with the correct shipment and vehicle.

[0118] Another way to avoid the risks of cross-talk is to use the unique ID of each local transmitter to pair a container 19 with its respective vehicle 18 prior to beginning transit. In short, each vehicle control unit 100 will be pre-paired with its respective door integrity sensor system(s) 102 and optionally paired with its respective optional remotely unlockable lock(s) 202. A high level flow chart showing a method 300 of pairing the devices is shown in Figure 8.

Initially, a hardware reset is done of the vehicle control unit 100 and the door integrity sensor system 102 (optionally the optional remotely unlockable lock 202), at step 302. If the devices are already paired with their respective other devices, at 304, then transmissions of monitoring signals 101 can begin, at 306. The devices may already be paired because either (a) they are statically pre-paired (such as a tractor that typically uses the same trailer) with the ID numbers pre-programmed or (b) because the devices automatically receive transmissions, determine their respective devices (e.g., based on signal strength), and store the ID numbers of their respective devices. [0119] If the devices are not already paired, at 304, then the devices are manually paired. Figure 9 shows a flow chart of an exemplary implementation of a method of pairing a vehicle control unit 100 with its respective door integrity sensor system 102. Initially, at 402, the door integrity sensor system 102 is put into a pairing mode. The door integrity sensor system 102 is turned off or reset by pressing its reset button (not shown). While the reset button is being held or the door integrity sensor system 102 is off, a pairing button (not shown) of the door integrity sensor system 102 is pushed and held, at 404. While the pairing button of the door integrity sensor system 102 is being held, the door integrity sensor system 102 is turned on or the reset button is released, at 406. The door integrity sensor system 102 can be programmed to indicate to the user attempting to pair the devices that the door integrity sensor system 102 is in its program mode, e.g., by flashing an LED (not shown), at 408. If the door integrity sensor system 102 is not yet in its pairing mode, at 410, the process starts again at 402. While the door integrity sensor system 102 is in its pairing mode, it repeatedly transmits its ID via signal 103. Additionally, while the door integrity sensor system 102 is in its pairing mode, it will transmit to all different PAN networks possible (i.e., broadcast its signal to different networks to allow for devices currently in another network to connect with it).

[0120] With the door integrity sensor system 102 in its pairing mode, a pairing button (not shown) of the vehicle control unit 100 is pressed, at 420, to put the vehicle control unit 100 into its pairing mode. The vehicle control unit 100 can be programmed to indicate to the user attempting to pair the devices that the vehicle control unit 100 is in its program mode, e.g., by flashing an LED (not shown), at 422. While the vehicle control unit 100 is in its pairing mode, it repeatedly receives the signal 103 and stores the ID numbers of transmitters in range.

Additionally, while the vehicle control unit 100 is in its pairing mode, it will be possible for the control unit 100 to change its' PAN network ID or the network ID on the transmitter(s). After the vehicle control unit 100 determines the ID number of the door integrity sensor system 102 to which it is being paired (e.g., by identifying the ID number that it received most often over about four or five seconds), it turns off the LED, at 426, and indicates to the user that it has determined an ID to pair with, at 428, e.g., by generating an audible tone, at 428, or by changing the LED flash duration or period. Once the devices are paired with their respective other devices, at 430, then transmissions of monitoring signals 101 can begin, at 432. [0121] If after about five seconds, at 426, the vehicle control unit 100 indicates that it is still in its pairing mode, the user resets both devices, at 440, and begins the process again, at 442 (by starting again at 402). If after about five seconds, at 426, the vehicle control unit 100 indicates that it has left its pairing mode, but does not indicate, at 428, for about 50 seconds, at 450, that it has identified the ID number of its respective device, the user resets both devices, at 440, and begins the process again, at 442 (by starting again at step 402).

[0122] Figures 10-50 show, and the text below describes, various aspects of various exemplary software applications for use with the systems and methods herein. Although the carrier vehicles 18 and containers in Figures 10-50 and the accompanying text are referred to as "trucks," as discussed above, the present systems and methods are not limited to use with shipments carried by trucks, and the carrier vehicles and containers may be any of the various vehicles and containers identified herein.

[0123] Reference is now made to Figure 10 of the drawings, which illustrate a high-level view of the general features built in to a software application ("app") of one exemplary embodiment. "Software," "application," and "app" as used herein, include but are not limited to one or more computer readable and/or executable instructions that cause a computer or other electronic device to perform functions, actions, and/or behave in a desire manner. The instructions may be embodied in various forms such as routines, algorithms, modules or programs including separate applications or code from dynamically linked libraries. Software applications may also be implemented in various forms such as a stand-alone program, a function call, a servlet, an applet, instructions stored in a memory, part of an operating system or other type of executable instructions. It will be appreciated by one of ordinary skill in the art that the form of software is dependent on, for example, requirements of a desired application, the environment it runs on, and/or the desires of a designer/programmer or the like. The features of the app may be described in terms of Transportation Logistics 1010. Figure 10 illustrates various features within the app, which may be categorized as Load Truck 1020 (i.e., load vehicle or load container), Track Truck 1050 (i.e., track shipment, track vehicle, or track container), and Administration 1090.

[0124] The features under Load Truck 1020 are various features associated with the loading of a truck in preparation for transport. Build Shipment 1025 represents features associated with building a shipment; Distribution 1030 represents features associated with building a distribution plan for said shipment; Customs 1035 represents features associated with enabling said shipment for customs inspections; and Validation/Security 1040 represents features associated with validating the shipment in accordance with pre-defined security protocols.

[0125] The features under Track Truck 1050 are various features associated with the tracking of a truck (and presumably the contents of the shipment associated with the truck). Some of these features will be done during transit and some of these features will typically be done prior to transit, e.g., contemporaneously with Load Truck 1020 after preparation of the truck for transport. Trailer Sensor 1055 represents features associated with monitoring a door of a trailer or other container associated with a truck; Location, Speed, Direction 1060 represents features associated with tracking the location, speed, and direction of a truck; Panic Button 1065 represents features associated with the ability of a truck driver to communicate with a remote location with a status update; Virtual Fence 1070 represents features associated with the ability to track a truck's route with respect to a pre-determined geographical boundary; Pressure Sensor 1075 represents features associated with monitoring the engine pressure of a truck; and

Temperature Monitor 1080 represents features associated with monitoring the engine

temperature of a truck.

[0126] Administration 1090 represents the various features associated with the administration of users and the app. For instance, Administration 1090 may include of features which enable an administrator to set user access to the app, user access to specific modules or features within the app, and the ability to define and/or edit the various features associated with the loading and tracking/monitoring of a truck within the app.

[0127] Reference is now made to Figure 11 which illustrates at a high level an exemplary plurality of features implemented in an exemplary app. User access to the app is represented at 1110. Once a user gains access to the app, e.g., by logging in by entering a username and password, the user is presented with multiple application modules ("modules") which allow the user to access various functions of the app, generally described with reference to Figure 10 above. The modules are organized as Logistics module 1120, Distribution module 1130, Customs module 1140, Security module 1150, Monitoring module 1160, and Administrator module 1170. [0128] The exemplary modules of Figure 11 may also be implemented by way of a portable application 1180 (not shown) executing on a portable computer, e.g., a tablet computer or a so- called smart phone. The portable application is an application which may be implemented on a portable computing device such as a tablet computer or a smart phone, and is designed to run on the portable computing device without being installed in a way that modifies the computer's hardware and/or software configuration. A portable application may also refer to a mobile application which is installed on a portable computing device and modifies the computer's configuration information. The latter variety are typically referred to commercially as "mobile apps." The term portable application is used in this application to refer to both stand-alone portable applications (typically configured on portable storage devices such as a Universal Serial Bus Drive) as well as installable portable applications ("mobile apps" on smart phones and/or tablets). Figure 52 illustrates at a high level the specific groups of features implemented in a portable application 1180. User access to the portable application 1180 is represented at 1110 ¹ . Once a user gains access to the application 1180, e.g., by entering a username and password, the user is presented with multiple application modules ("modules") which allow the user to access various functions of the application 1180, generally described with reference to Figure 10 above. The modules of the exemplary portable application 1180 are organized as Logistics module 1120 ¹ , Distribution module 1130 ¹ , Customs module 1140 ¹ , Security module 1150 ¹ , Monitoring module 1160 ¹ , and Administrator module 1170 ¹ . Access to one or more of the modules 1120, 1130, 1140, 1150, 1160, 1170 (and sub-modules within those modules) can be permitted or restricted for particular users on a user-by-user basis based on permissions stored in the system. For example, personnel data can indicate that a particular person has a particular job or job description or role and module data can indicate which modules can be accessed by each job or job description or role. Thus, when a user logs in, the app can refer to the personnel data and module data and determine which of these modules 1120, 1130, 1140, 1150, 1160, 1170 (and sub-modules within those modules) are to be presented to the particular user who logged in.

[0129] Figure 12 represents an exemplary embodiment of the user access 1110. User 1210 is an input field which allows a user to enter a Username (not shown) associated with the access to the app. Password 1220 is an input field which allows a user to enter a Password (not shown) associated with the Username. Once the Username and the associated Password are entered in 1210 and 1220 respectively, the user selects Login 1230 to request access to the app. The Username and Password are then transmitted to an Authentication Routine (not shown) via a Secure Channel (not shown). Exemplary Secure Channels include an encryption channel such as a Secure Socket Layer (SSL). Once user access is requested, the app undertakes the

Authentication Routine to either grant or deny the user access to the app. The Authentication Routine may include a 2-factor authentication, which checks for both the user-level credentials (Username, Password) as well as a Device-level Authentication (not shown). Device-level Authentication includes the app's ability to check for specific Device-level Parameters (not shown) in granting/denying access. Examples of Device-level Parameters include an IP address or a MAC address.

[0130] Authentication Routine may also include the usage of a Firewall (not shown). The Firewall may be further strengthened by deploying an Intrusion Detection System (IDS) (not shown) and an Intrusion Prevention System (IPS) (not shown). The Intrusion-detection System watches for data packets from a monitoring port, compares the data packets to a set of Firewall rules defined by an Administrator (not shown), and sends a signal to the Administrator if it encounters data packet(s) which do not meet the defined rules. The Intrusion-detection System also helps with the blockage of undesired data packets from passing through the Firewall. The Intrusion-detection System helps the Firewall extend its detection capabilities by detecting additional traffic such as network attacks on services, unauthorized login attacks, virus attacks, and Trojan horse attacks. The Intrusion-detection System may achieve this by employing various detection mechanisms such as signature-based detection, anomaly-based detection, and stateful protocol analysis. The IPS System is in-line with the network traffic flow and includes the Intrusion-detection System features, but additionally possesses the ability to stop undesired traffic as they are transmitted over a Network (not shown). The IPS System also has the ability to terminate a network connection or a user session by blocking access to the target resource from the inflicting user. IPS may also be configured to dynamically re-configure the Firewall. A User Access Control Policy as described in Figure 45 may be implemented to enable the administration of user access to the app.

[0131] Referring now to Figure 13, if a user is granted access to the app, the user is presented with a list of available modules in accordance with the User Access Control Policy specific to said user. Home 1310 represents the landing page/home page of the user. In case of Home 1310 in Figure 13, an exemplary view of modules available to a logged-in user is presented. Exemplary Home module 1310 includes modules Logistics 1120, Customs 1140, Distribution 1130, Security 1150, Administrator 1170, and Monitoring 1160. A detailed view of each of these modules is presented below.

[0132] Figure 14 describes the various exemplary sub-modules available to the user in the exemplary Logistics module 1120. Logistics module 1120 includes 4 sub-modules - Available Docks 1420, Ship Builder 1430, Reports 1440, and Ship Progress 1450.

[0133] Figure 14A describes an alternate embodiment of the various sub-modules available to the user in the Logistics module 1120. In this embodiment, Logistics module 1120 includes 6 sub-modules - Available Docks 1420 ¹ , Ship Builder 1430 ¹ , Reports 1440 ¹ , Ship Progress 1450 ¹ , Cancel Shipment 1460 and Driver Receipt 1470. Cancel Shipment 1460 enables the user to close and/or cancel a shipment. In one embodiment, choosing the Cancel Shipment 1460 option does not completely remove the associated shipment data from the system 10, but instead cancels the shipment and sends a communication to the user regarding said cancellation. Although the Cancel Shipment 1460 feature is described herein with reference to the Logistics Module 1120, the same feature may be implemented with respect to any other module or sub-module of the present invention. Further, the Cancel Shipment 1460 feature may be designed such that the feature is restricted to only those users who have the appropriate permissions to cancel shipment data with reference to the selected module. For example, if the Cancel Shipment feature were to be implemented in the Monitoring Module 1160, only those users who have permissions to operate within the Monitoring Module 1160 may be granted permission to utilize the Cancel Shipment 1460 feature. The Driver Receipt 1470 sub-module may be used in conjunction with a shipment, wherein selecting the Driver Receipt 1470 option would enable a user to print a receipt with a bar code and the shipment information associated with the selected shipment.

[0134] Referring now to Figure 15, an exemplary embodiment of the Logistics module is presented. Specifically, Logistics module 1120 and its sub-modules Available Docks 1420, Ship Builder 1430, Reports 1440, and Ship Progress 1450 are represented in an exemplary

embodiment of the app. Figure 15A shows an additional exemplary embodiment of the Logistics module 1120 and its sub-modules Available Docks 1420 ¹ , Ship Builder 1430 ¹ , Reports 1440 ¹ , Ship Progress 1450 ¹ , Cancel Shipment 1460 and Driver Receipt 1470, represented in an exemplary embodiment of the app. When a user selects the sub-module Available Docks 1420, a sub-module specific screen is displayed within the app.

[0135] Referring now to Figure 16, when a user selects Available Docks 1420 in Figure 15, a sub-module specific screen Available Docks 1610 is presented. On this screen, the user is able to view a graphical representation of the docks made available to the app, via a graphical user interface. Further, the user is also able to ascertain the availability status of each of the displayed docks via the same graphical user interface. The app or the server can make a determination of the availability status of each of the docks using the dock sensor data transmitted to the server 14, 34 (see Figures 3A, 3B, and 4 and accompanying text). In the alternative, other ways of determining availability can be used, such as inspection by dock personnel, who upload the availability of dock status to the server 14, 34 using a computer. For example, in Figure 16, docks that are available to the user for building a shipment (e.g., as determined from data transmitted by the dock sensor systems 60) are represented by one icon, color (e.g., green), or shade (see Docks 1610, 1620, 1630, 1640, 1650), and docks that are presently unavailable to the user for building a shipment (e.g., as determined from data transmitted by the dock sensor systems 60) are represented by a different icon, color (e.g., red), or shade (see Docks 1660, 1670, 1680). In an embodiment, a user may ascertain the availability status of each of the displayed docks and/or filter the availability status of each of the docks using the Results Filter 1690 option presented in Figure 16A. Results Filter 1690 displays various icons 1695 showing the availability and/or unavailability of the docks. Users may select one of the icons 1695 to "filter" out any statuses that do not pertain to the selected icon's status. This way, the user is able to refresh the screen and view only those docks which represent the status of the selected icon 1695.

[0136] A user may obtain additional information about a specific dock by selecting the desired dock from Figure 16. For instance, with reference to Figure 16, the user selects a dock 1610. Thereafter, the user is directed to a Dock Details 1710 screen as represented in Figure 17. On this screen, the user is able to view additional information regarding the selected dock 1610. Specifically, the user is able to view a Dock Number 1720, Dock Owner 1730, Dock Description 1740, and a Dock Status 1750 (e.g., as determined from data transmitted by the dock sensor systems 60) for the selected dock 1610. The user may choose to utilize the information regarding the availability and non-availability of docks presented in Figures 16 and 17 in further building a shipment. The user may also edit any of the dock details (1720, 1730, 1740, 1750) on this screen. Further, while the Dock Status 1750 of a selected dock 1610 is advantageously determined from the data transmitted by the dock sensor systems 60, the Status 1750 may also be manually configured by the user. For example, in the event of a dock 1610 malfunction, although the data transmitted by the dock sensor systems 60 may indicate an available dock 1610, a user may manually set the dock 1610 as unavailable on the Dock Details 1710 screen. In an additional embodiment, the user may also "lock" the Status 1750 of a dock 1610. Such "lock" may be helpful to users during routine dock maintenance Status 1750 may then be "unlocked" by the user at any time. After making the desired edits, the user may choose to save the edits by selecting a Save 1770 icon presented on this screen 1710. Any changes made to the dock details 1720, 1730, 1740, 1750 are then transmitted to a central server 14 for storage and retrieval. The user may also select the Save 1770 icon even without making any edits to the dock details. The user may choose to exit this screen by selecting either the Save 1770 icon, or the Exit 1760 icon. Exiting this screen takes the user back to the Available Docks 1610 screen of Figure 16.

[0137] Referring again to Figure 15, the user selects Ship Builder 1430 in order to begin the process of building a shipment. When the user selects Ship Builder 1430, the user is directed to a sub-module specific screen in Figure 18. Referring now to Figure 18, the sub-module specific screen Ship Builder 1810 is presented within the app. Here, the user is able to view a graphical representation of the Docks 1820, and the Boxes 1830, available within the app, along with a graphical representation of a truck 1840. The user may then select an individual Dock along with an individual Box, to begin the process of building a shipment. For instance, in Figure 18, the user may select individual Dock 1850 along with an individual Box 1860. In selecting the desired dock, the user may utilize the information previously presented with reference to Figures 16 and 17 (showing the availability and non-availability of docks). The user may also wish to return to the Home 1310 screen by selecting Home 1870 icon. Home 1870 icon is made available throughout the app in various module specific and sub-module specific screens. In each of these various instances, a user selecting the Home 1870 icon returns the user's app screen to the Home 1310 screen as shown in Figure 13.

[0138] Once the user selects a combination of a Dock 1850 and Box 1860, the user selects the Save icon 1862, and is then directed to a Shipments 1910 screen, as shown in Figure 19. On this screen, the user is able to view the Shipment Trucks (1920 to 1990) made available to the app, including the truck 1840 previously shown in Figure 18. Truck 1840, which now has Dock 1850 and Box 1860 associated with it, is represented as Shipment Truck 1920 in Figure 19. The user is able to select a shipment truck to view additional details about the shipment, as well as to add or edit additional details about the shipment. For instance, when the user selects Shipment Truck 1920 in Figure 19, the user is directed to a Shipment Details 2010 screen in Figure 20.

[0139] Referring now to Figure 20, the Shipment Details 2010 screen presents additional details regarding the selected shipment. For instance, Shipment Details 2010 includes fields that represent an ID 2020, Dock 2030, Box 2040, Date 2050, Route 2060, Driver 2070, and Tractor 2080. On this screen, the user is able to view and/or modify any of the shipment details. Also, the user may be presented with some shipment details which are pre-filled as a result of the user selection in prior screens, whereas some shipment details fields may be left open awaiting user input. For instance, in the exemplary Shipment Details 2010 screen, the ID 2020, Dock 2030, Box 2040 are pre-filled based on the selections the user has made in Figures 18 and 19.

Additionally, Date 2050 is pre -populated with the current date and time, as determined by either local time set on the computer/terminal accessing the app, or the time set on the central server 14. Figure 20, however, provides the user the ability to add additional details information within the app. For instance, Route 2060, Driver 2070, and Tractor 2080 are initially left blank for the user to fill in with the appropriate selections. In the embodiment presented in Figure 20, the Route 2060, Driver 2070, and Tractor 2080 fields may be filled in by selecting an appropriate entry from a list of pre-populated entries presented in a drop-down menu format. One or more drivers may be added using the Driver 2070 option. The user may also choose to add additional drivers via a Check Extra icon 2071 (not shown). Check Extra 2071 allows the user to add an extra driver in addition to the initial driver(s) designated. Once the user makes the desired selections and/or modifications, the user then proceeds to save these selections by selecting the Save 2090 icon. Once the user saves the shipment details information, that information is transmitted to a central server 14 for storage and retrieval. The user may select a Export/Import Icon 2594 (not shown) to designate the shipment as either an export shipment or an import shipment. The user may also select an exit icon 2095 to return to the Shipments 1910 screen in Figure 19. [0140] Referring now to Figure 20A, a virtual view of a truck and a truck pallet are shown displaying data corresponding to a selected shipment. According to Figure 21 A, a user is able to select and view a "virtual" view of a tractor/trailer. An exemplary trailer 2081 is shown. Also shown are several layers 2082 which represent the several layers of pallets arranged in the trailer 2081. When a user selects one of the layers 2082, a top-down view 2086 of the selected trailer 2081 is shown. In the top-down view 2086, a user is presented with all pallets 2085 on the selected layer 2082. A user is then able to select one particular pallet 2083 by either clicking on the desired pallet 2083 or by hovering over the desired pallet 2083. Once selected, data describing the contents of the pallet 2083 are displayed on a screen 2084. Screen 2084 may either be displayed on the same view as the view 2086, or may be set in a separate view (not shown).

[0141] Figure 21 shows at a high level the Distribution module 1130, as well as exemplary sub- module Shipments 2110, along with features Documents 2120 and Map 2130.

[0142] When a user selects Distribution module 1130 from Figure 13, the user is then directed to the Distribution module 1340 screen in Figure 22. On this screen, the user is able to view and select the Shipment Trucks ready for distribution. Distribution Trucks 2210 though 2280 represent trucks which have been assigned a Dock and a Box, and which are now ready to be assigned specific items to be shipped. Shipment Truck 1920 of Figure 19 is represented by Distribution Truck 2220 in Figure 22. When the user selects Truck 2220 from Figure 22, the user is directed to a sub-module specific screen Shipment 2310 in Figure 23. In Figure 23, the user is able to select Documents 2320 and Map 2330 for Truck 2220. Alternatively, user is able to return to the previous screen in Figure 22 by selecting the Return 2340 icon of Figure 23.

[0143] When a user selects the Documents 2320 icon of Figure 23, user is directed to a

Documents Detail screen 2410 of Figure 24. Documents Details screen 2410 shows Quantity Built 2420 and Comment 2430 for the Shipment ID 2440. Shipment ID 2440 is the ID of the shipment associated with Truck 2220 selected in Figure 23. Documents Detail Screen 2410 further allows the user to select and upload a pre-existing file from either the computer/terminal currently accessing the app, or from a central server 14, or from a network location. When the user selects and uploads a Shipment File (not shown), by selecting Choose File 2450, the Shipment File is associated with the Shipment ID 2410 and is uploaded to the central server 14. The user also is able to show the various fields associated with the Shipment ID 2410 by selecting Show Fields 2460, which then directs the user to the Show Fields screen 2510 of Figure 25. The user is able to save any information viewed and/or modified on Documents Details screen 2410 by selecting the Save 2470 icon on Figure 24. Selecting Save 2470 saves the information on the Documents Details screen 2410, transmits the saved information to a central server 14 for storage and retrieval, and returns the user to the Shipment Screen 2310 in Figure 23. The user may also select an exit icon 2485 to return to the Shipment Screen 2310.

[0144] When the user selects Show Fields 2460 in Figure 24, the user is then directed to a Show Fields screen 2510 in Figure 25. Show Fields screen 2510 provides the user with an opportunity to view and/or modify further information about the Shipment ID 2410 presented in Figure 24. For instance, the user may view and/or modify an LP Number 2525, a Box Quantity 2530, a Carrier 2540, and a Letter 2545 on this screen. When the user enters information in the fields 2525, 2530, 2540, and 2545, the user may choose to add this information to the existing set of information presented by Table 2535 by selecting the Add 2550 icon. Once the user selects the 2550 icon, information from fields 2525, 2530, 2540, and 2545 is displayed as a new row in Table 2535.

[0145] The user is able to make additional edits to a row of information in Table 2535 by selecting an edit icon 2580 placed adjacent to the desired row of information. When the user selects the edit icon 2580, the existing values in fields 2560, 2570, 2575, 2565 are populated in the fields 2525, 2530, 2540, 2545 respectively, allowing the user to made edits. The user may also choose to delete a desired row of information by selecting a delete icon 2585 placed adjacent to the desired row of information. As is evident from Table 2535, any additions made using fields 2525, 2530, 2540, and 2545 are represented by fields 2560, 2570, 2575, and 2565 in Table 2535 respectively. As is also evident from Show Fields screen 2510, Carrier 2540 and Letter 2545 may be selected from a pre-populated list represented within the app via a dropdown menu. The user may also choose to email a copy of contents of fields 2525, 2530, 2540, 2545 or the contents of Table 2535 via an email to another user or non-user by selecting the Send E-Mail 2555 icon.

[0146] A user may also select Map 2330 from Figure 23 to view a graphical representation (not shown) of the contents of a shipment. Alternately, the user may be presented with the contents of the shipment in a grid-like format (not shown). Presenting the user with the content of the shipment in an easy to understand and usable format such as a graphical representation or a grid provides the user an opportunity to re-evaluate the positioning and/or the content of the shipment on a dynamic basis.

[0147] Referring now to Figure 26, the Customs Module 1140 is presented including the File Entry mechanism 2610. When a user selects Customs Module 1140 in Figure 13, the user is directed to the Customs Module screen of 2710 in Figure 27. Here, the user is able to select a truck from a plurality of Distribution Trucks, previously presented in Figure 22, now referred to as Customs Trucks 2720 through 2790. The user is able to select a desired Customs Truck from Figure 27 to view a truck-specific Customs Order Form 2810 in Figure 28. Customs Order Form 2810 includes a shipment number 2820 of the desired shipment. The Order Form 2810 further includes a Seal 2830 and an Entry Number 2840. The user is also able to associate a Customs File (not shown) along with the shipment number 2820 by selecting Choose File 2850 in Figure 28. The Customs File may be located either on the computer/terminal hosting the app, or a central server 14, or a network location. Once the user completes data entry in the Customs Order Form 2810, the user may then select the Upload icon 2860 to transmit the customs order information associated with shipment number 2820 to a central server 14 for storage and retrieval.

[0148] Figure 29 shows the Security Module 1150 along with exemplary sub-modules inspection sub-module (e.g., 17-Point Inspection 2910) and contents confirmation sub-module (e.g., Shield 2920). When a user selects the Security Model 1150 in Figure 13, the user is then directed to a Security Module specific screen 3010 presented in Figure 30 of the app. Figure 30 also includes a graphical representation of the security sub-modules Shield 2920 and 17-point inspection 2910. Although the inspection is herein referred to as a 17-point inspection 2910, it should be apparent that an inspection with more points or fewer points could be done in the context of this application. Also, in one embodiment, the 17-point inspection is made to comply with C-TPAT, the Customs-Trade Partnership Against Terrorism.

[0149] The Security Module and the associated sub-modules 17-Point Inspection and Shield may also be represented as part of a portable application ("portable app"). In addition thereto, the 17- point inspection and Shield sub-modules may also be represented as separate portable applications. The portable app may be implemented on a portable computing device such as a tablet computer or a smart phone. Since the Security Module receives touch points (inputs) from several users, implementing this module on a portable computing device enhances the efficiency and the speed with which tasks associated with this module may be completed.

[0150] The software code for implementing the portable app could be derived (at least in part) from the software code utilized to develop the app. However, the portable app may also include portable computer device specific implementations of the software code in order to enable the rendering of the portable app in a native manner on the portable computing device. For instance, the display resolution of the portable app may differ in size as compared to the display resolution of the app, based on the specific type of portable computing device the portable app is accessed from. Such modifications would be evident to those ordinarily skilled in the art. Regardless of the type of application used (app, portable app), the data associated with the security module will be accessed from and stored in the central server 14.

[0151] When a user selects the 17-point inspection sub-module 2910 in Figure 30, the user is then directed to the sub-module specific screen for 17-point inspection in Figure 31. The sub- module specific screen is represented by reference numeral 3110 in Figure 31. 17-point inspection selection screen 3110 represents a plurality of trucks made available to the app after said trucks undergo the logistics and distribution routines described earlier. The user selects a desired truck for a 17-point inspection and validation.

[0152] When a user selects a particular truck 3120 in Figure 31, the user is directed to a 17-point inspection validation screen 3210 in Figure 32. The specific type of user utilizing 17-point inspection validation may be different from a user utilizing the logistics and distribution modules in the app. For the purposes of this discussion, we refer to this user as a Technician User (not shown). In Figure 32, a checklist is provided to facilitate a 17-point inspection of the truck 3120 by the Technician User. The 17-point inspection criteria are represented by reference numerals 3230 through 3246 in Figure 32. The 17-point inspection screen is coded to permit the

Technician User to touch each item to "check off that item, which indicates that the item has been checked and passes criteria applicable to that test. The Technician User may also enter additional notes 3250 with reference to the inspection of the truck 3120. The 17 Point Validation screen 3210 also presents the Technician User with a view of the truck number along with additional information such as the driver of the truck and the plates of the truck represented in box 3270. After the Technician User completes the 17-point inspection validation, the

Technician User may save the information entered by selecting the Save icon 3290. Once the user selects the Save icon 3290, data from fields 3230 though 3246 and 3250 is transmitted to a central server 14 for storage and retrieval. The Technician User may also choose to exit the screen 3210 by selecting the exit icon 3280 in Figure 32, which then takes the Technician User back to 17-point inspection selection screen 3110 in Figure 31.

[0153] Referring now to Figure 48, a high-level logic diagram for an exemplary portable app 4800 is presented. Portable app 4800 represents the 17-point inspection sub-module discussed above, but on a portable computing device. At step 4810, the inspection process begins. At step 4820, the Technician User makes a truck selection. The truck selected at step 4820 may either be a Shipment Truck or a Distribution Truck or a Truck which is unassigned as either a Shipment Truck or a Distribution Truck. An unassigned Truck is one which is not currently associated with either a shipment or a distribution. An exemplary shipment truck is represented by

Shipment Truck 1920 of Figure 19. An exemplary distribution truck is represented by

Distribution Truck 2220 in Figure 22. If the Technician User chooses an unassigned Truck, the logic flows to step 4830, where the 17 point check for the unassigned truck begins. Initially, at step 4835, one or more items (preferably 17 items) of inspection are presented to the Technician User. At step 4840, the Technician User enters responses to the one or more items of inspection presented at the previous step. These responses are then accepted by the portable app 4800. At step 4845, the Technician User may choose to either save the responses, or save and submit the responses, or to exit the system without saving and/or submitting the responses. In any case, the portable app returns to step 4810 to begin another inspection process. Similarly, if the

Technician User chooses a Shipment Truck or a Distribution Truck, the logic flows to step 4848, where the 17 point check for the Shipment Truck or the Distribution Truck begins. Initially, at step 4850, one or more items (preferably 17 items) of inspection are presented to the Technician User. At step 4855, the Technician User enters responses to the one or more items of inspection presented at the previous step. These responses are then accepted by the portable app 4800. At step 4860, the Technician User may choose to either save the responses, or save and submit the responses, or to exit the system without saving and/or submitting the responses. In any case, the portable app returns to step 4810 to begin another inspection process. [0154] When a user selects the Shield 2920 in Figure 30, the user, is then directed to a sub- module specific Shield screen 3310 in Figure 33. As in Figure 31, Shield screen 3310 represents a plurality of trucks made available to the app after said trucks undergo the logistics and distribution routines described earlier. The user selects a desired truck for an inspection by three different persons to verify that the truck (the trailer or other container) actually contains the correct goods as listed by an authoritative list of the contents to be shipped in this shipment.

[0155] When a user selects a particular truck 3320 for a shield inspection, the user is directed to a Shield sign-on screen 3410 in Figure 34. On this screen, the user is presented with the selected truck at 3460. The user may select the exit icon 3420 to return to Shield screen 3310.

Additionally, Shield sign-on screen 3410 presents an authentication point for three types of users - a Security user 3430, a Customs User 3440 and a Driver User 3450. Once a desired user selects the appropriate login icon, that user is directed to a user-specific verification screen to enter their respective verification-level credentials to give their personal verification that the shipment contains the correct goods.

[0156] For instance, Figure 35 shows a Driver specific login screen 3510 which is presented when the Driver authentication icon 3450 is selected in Figure 34. 3510 includes a user name field 3520 and a password field 3530 to enable a Driver User 3450 to enter a Driver Username (not shown) and a Driver Password (not shown) respectively. Similar to the authentication routine described with reference to Figure 12, the Driver Username and Driver Password are transmitted to an Authentication Routine (not shown) via a Secure Channel (not shown).

Exemplary Secure Channels include an encryption channel such as a Secure Socket Layer, SSL. Once user access is requested, the app undertakes the Authentication Routine to either grant or deny the user the ability to verify the contents of that shipment. Having each of the three verification inspectors separately enter their own respective verification-level credentials permits each of them to use the same computer to perform the verification (which computer may have been initially logged in by a different person who may or may not have verification-level credentials). The Authentication Routine may include a 2-factor authentication, which checks for both the user-level credentials (Driver Username, Driver Password) as well as a Device-level Authentication (not shown). Device-level Authentication includes the app's ability to check for specific Device-level Parameters (not shown) in granting/denying the ability to verify the shipment. Examples of Device-level Parameters include an IP address or a MAC address. [0157] Authentication Routine may also include the usage of a Firewall (not shown). The Firewall may be further strengthened by deploying an Intrusion Detection System (IDS) (not shown) and an Intrusion Prevention System (IPS) (not shown). The Intrusion-detection System watches for data packets from a monitoring port, compares the data packets to a set of Firewall rules defined by an Administrator (not shown), and sends a signal to the Administrator if it encounters data packet(s) which do not meet the defined rules. The Intrusion-detection System also helps with the blockage of undesired data packets from passing through the Firewall. The Intrusion-detection System helps the Firewall extend its detection capabilities by detecting additional traffic such as network attacks on services, unauthorized login attacks, virus attacks, and Trojan horse attacks. The Intrusion-detection System achieves this by employing various detection mechanisms such as signature-based detection, anomaly-based detection, and stateful protocol analysis. The IPS System sits in-line with the network traffic flow and includes the Intrusion-detection System features, but additionally possesses the ability to stop undesired traffic as they are transmitted over a Network (not shown). The IPS system also has the ability to terminate a network connection or a user session by blocking access to the target resource from the inflicting user. IPS may also be configured to dynamically re-configure the Firewall. A User Access Control Policy as described in Figure 45 may be implemented to enable the administration of user access to the app.

[0158] Each of the Security User 3430, Customs User 3440, Driver User 3450 indicate their verification of the shipment contents by typing in their user-specific verification credentials, an example of which is shown in Figure 35. Further, there may be additional steps made available for the approval of the Shield Security. For example, after entering their verification level credentials, another screen or screens may be brought up into which the Security User 3430, Customs User 3440, Driver User 3450 may be required to select a "pass" or "verify" checkbox, or any other similar mechanism to indicate verification that the container contains the correct contents for that shipment. In one embodiment, as shown in Figure 35A, signature 3545 of any one or two or more of the Security User 3430, Customs User 3440, Driver User 3450 may be collected in a Digital Signature Capture screen 3540. The signature 3545 may either be saved at Save 3550, or cleared for making way for a new signature entry by selecting the clear icon 3555.

[0159] Referring now to Figure 49, a flow chart for an exemplary portable standalone Shield app 4900 is presented. Portable app 4900 represents the Shield sub-module discussed above, but on a portable computing device. At step 4910, the Shield process begins. At step 4920, a user chooses a truck, selected from a truck which previously passed the logistics and distribution routines described earlier. At step 4930, the user selects his/her role in the module (e.g. Security User 3430, Customs User 3440, Driver User 3450). At step 4940, the user enters his/her verification credentials. An optional step 4950 is provided to enter any additional information by the user. The verification credentials and any additional information are accepted by the portable app 4900. At step 4960, the user may choose to either save the responses to the server 14, or save and submit the responses, or to exit the system without saving and/or submitting the responses. In any case, the portable app returns to step 4910 to begin another Shield process.

[0160] Referring now to Figure 36, the monitoring module 1160 is represented. Additionally, exemplary sub-modules of monitoring module 1160 are also represented. These sub-modules include a Shipment Status 3620, an Alert 3630, and a Map View 3640.

[0161] When a user selects the Monitoring Module 1160 in Figure 13, the user is presented with the module specific Monitoring Screen 3710 as shown in Figure 37. The Monitoring Screen 3710 further includes icons 3620 and 3640 representing the sub-modules Shipment Status, and Map View respectively. With reference to Figure 41 A, an additional sub-module Archived 4191 may also be available in the Monitoring Module 1160. When a user selects Archived 4191, the user is presented with a repository of all the completed and/or canceled shipments (not shown on Figure 41 A). Another sub-module Truck Dashboard 4191 may also be available in the

Monitoring Module 1160. When a user selects Truck Dashboard 4191, the user is presented with the truck dashboard map 4194. Here the user can view a list of all active shipments associated with a truck. The list may either be presented in a textual form 4193 (e.g. a legend), or in graphical form, as represented by icons 4192 on map 4194. Both the textual form 4193 and graphical form 4192 can be equipped to show additional information regarding the shipment. For example, item 4196 displays a driver's name and the truck number of the selected truck.

[0162] When a user selects the shipment status 3620 sub-module in Figure 37, the user is presented with a sub-module specific screen Shipment Status 3810, as shown in Figure 38. The Shipment Status 3810 screen represents a plurality of trucks which have been enabled for transportation, and are ready to be tracked and monitored by users within the app. The graphical user interface enables a user to ascertain broadly the overall shipment status of a certain truck by viewing Shipment Status screen 3810 in Figure 38. For instance, trucks 3820, 3840, and 3870 represent an on-schedule shipment status, are represented by one icon, color (e.g., green), or shade. Trucks 3850 and 3860 represent a potential issue with the shipment status, are represented by a different icon, color (e.g., yellow), or shade. Shipments 3830, 3880, 3890 represent an issue with the shipment status, are represented by still a different icon, color (e.g., red), or shade.

[0163] A user may select a desired truck from plurality of trucks represented in Figure 38 to obtain additional information regarding the truck's shipment status. Referring now to Figure 39, Shipment Details screen 3910 represents a detailed view of the status of a shipment of a truck selected in Figure 38. Shipment Details 3910 further includes additional information regarding the shipment such as Ship Owner 3930, Origin 3931, Destination 3932, Date Dispatched 3933, Date Delivered 3934, Driver 3935, Status 3936, and Speed 3937. Additionally, Shipment Details screen 3910 includes a Times icon 3940, and a Map View icon 3950. Shipment Details 3910 also includes an exit icon 3920, by selecting, which the user returns to screen 3810 of Figure 38.

[0164] Referring now to Figure 40, when a user selects the Times icon 3940 in Figure 39, the user is directed to a Times Screen 4010 in Figure 40. The Times screen 4010 presents a graphical representation of the times at which the selected truck was present at pre-determined locations. The pre-determined locations selected in the exemplary embodiment of Figure 40 are Producer 4020, Mexican Customs 4030, Mexican Broker 4050, US Broker 4060, US Customs 4070, US DOT 4080, and Warehouse 4090. A user may hover over or click on any of these predetermined locations to ascertain the "time-in" and "time-out" of the selected truck at that particular location. For instance, the user selected US Customs 4070 in Figure 40 whereby a time entry box 4095 is presented to the user showing a time-in 4096 and time-out 4097 of the selected truck at that customs location 4070.

[0165] The user may select to view a representation of the truck on a map by selecting either the Map View icon 3640 in Figure 37, or Map View icon 3950 in Figure 39, or Map View icon 4040 in Figure 40. Regardless of the particular Map View icon selected, once a Map View icon is selected, the user is directed to the Map View Screen 4110 in Figure 41.

[0166] Figure 41 shows a Map View of the selected truck in a map area 4120. The map area 4120 further includes a geographical boundary area 4130, which is pre-determined within the app by an administrator or a client of the app with suitable authority. The geographical boundary area 4130 represents a virtual geographical fence, the outer boundaries or geographical limits within which a truck is expected to be situated at any point during its shipment. A geographical boundary area is route-specific, and may be further modified in an ad-hoc fashion by an administrator or a client of the app, for each truck and/or for each route. The use of a

geographical fence (geo fence) allows the administrator or a client of the app to determine within the app which areas are safe for transportation for a particular truck/route. The geo fence may be enabled not only through the software of app, but also via a GPS unit disposed in the truck. For example, a pre-determined "safe" area may be pre-programmed into the GPS unit traveling with the truck. This enables the GPS unit to recognize and act upon the safe area, even without communicating with the central server 14. This is especially helpful in situations where the truck loses its GPRS signal to the central server 14. The geo fence arrangement and the automatic secure area recognition in both the software and GPS variety is particularly useful in situations where the truck passes through known points of travel, such as customs and security checkpoints.

[0167] Figure 4 IB shows another embodiment of a Map View of the selected truck in a map area 4120. The map area 4120 shows a geographical boundary area 4181 which is not represented by a rectangular outer border as it is represented in the map area 4120 of Figure 41. This feature allows the user to dynamically move the enhanced geographical boundary area 4181 and get a close up view of the selected area 4181, as represented by the box 4183.

[0168] Figure 51 shows a flow chart of the steps involved in creating a geo fence 5180 for a particular route. In order to provide context, the construction of the geo fence 5180 is shown here with reference to the Monitoring Module 1160. However, it is understood that the geo fence 5180 may be configured initially as part of the Logistics Module 1120. Specifically, the geo fence 5180 may be created as part of configuring Route 2060 in Figure 20, as part of the Ship Builder 1430 sub-module. Referring to Figure 51, a starting point 5160 of a particular shipment is entered at step 5105. Next, a destination point 5165 of the shipment is entered at step 5110. At step 5115, one or more routes are calculated and presented to the user. The route(s) may calculated based on pre-configured route information in the app, e.g. a mapping software, or may be calculated in "real-time" by connecting the app to a communications protocol such as Internet 16, or may be calculated "real-time" by accessing a global positioning system (GPS) receiver in communication with the app. At step 5120, the user selects one route 5170 from the list of presented route(s). At step 5125, a group of geographic pointers ("geo pointers") 5175 are calculated based on the route 4170 chosen. In one embodiment, geo pointers 5175 are a set of four distinct pointers. Two of the four geo pointers 5175 are associated with the starting point 5160 of the selected route 5170 and the other two geo pointers 5175 are associated with the destination point 5165 of the selected route 5170. For example, if the starting point 5160 is considered a central point, the pair of geo pointers 5175 associated with starting point 5160 may be placed equidistant on either side of the starting point 4160. Similarly, for example, if the destination point 5165 is considered a central point, the pair of geo pointers 5175 associated with destination point 5165 may be placed equidistant on either side of the destination point 5165. In one embodiment, there may be other geo pointers 5175 located somewhere between the starting point 5160 and the destination point 5165. At step 5130, a virtual geo fence 5180 is plotted and created by using the geo pointers 5175 as references. An exemplary geo fence 510 is shown in Figure 41, represented by the geographical boundary area 4130. In the area 4130, the four corners of the "rectangle" may be representative of the four geo pointers 5175 previously discussed. While, for the sake of convenience, the geo pointers 5175 are discussed as including a set of 4 pointers, it may be understood that any number of pointers may be utilized to create a geo fence. Further, in another embodiment, geo pointers 5175 may be calculated solely based on a pre-determined distance from the starting point 5160 and the destination point 5165, and may not depend on the specific route 5170 chosen in step 5120. For example, a geo fence may be created from geo pointers 5175 which are a selected predetermined distance (e.g., 100 meters) on either side of a plotted route of accepted directions beginning at the starting point 5160 and ending at the destination point 5165.

[0169] When a truck goes outside the geographical boundary area 4130, the Alert sub-module 3630 of the Monitoring Module is activated and a Message (not shown) (e.g., an e-mail or an SMS or MMS text message) is sent to an administrator and/or a client (or a pre-determined user or plurality of users) by the Alert sub-module 3630. In the alternative, a so-called pop-up can be generated on a computers associated with the shipment to be sure that the message is given wide distribution. The Alert sub-module 3630 may route this information via the central server 14. In either case, a command may then be sent from the administrator and/or the client to disable the vehicle. Disabling the vehicle may include simply shutting off the vehicle's ignition or perhaps decelerating the vehicle and then shutting off the vehicle's ignition using a vehicle control circuit 160 in communication with the engine. The Alert sub-module 4130 may also be programmed to trigger additional events upon the dispatch of the Message. For example, the Alert sub-module 4130 may be programmed to contact law enforcement officials every time a specific Message is transmitted to an administrator and/or client. In addition to the geo fence implementation, the Alert sub-module 4130 may be programmed to include alerts and messages for any other type of event. For instance, if a truck's speed decreases below an assigned threshold speed in a particular region, an automatic alert or message may be transmitted by the Alert sub-module 4130. It will be evident to one of ordinary skill in the art that the Alert sub-module 4130 may be programmed to handle any event. The Alert sub-module 3630 may also be programmed to work with the GPS unit in the truck. Accordingly, the GPS unit in the truck may be pre-programmed with event codes and event descriptions. In the event of a particular pre-programmed event being triggered by the GPS unit (e.g., truck goes outside geo fence; truck goes too fast or slow), an appropriate event code and event description are sent to the central server 14, where an administrator or a client may access the event information.

[0170] Alert sub-module 3630 may also be activated by the Driver User 3450. For instance, Driver User 3450 may press a Panic Button (not shown) on the vehicle driver interface 152 (Figure 7 A) in the truck to communicate to the central server 14 that there is a risk of harm to the driver or the shipment. As another example, Driver User 3450 may press a Delay Button (not shown) on the vehicle driver interface 152 (Figure 7 A) in the truck to communicate to the central server 14 that there is an expected delay in the shipment, e.g., a delay at a customs site. The Driver's communication with the central server 14 may also be implemented as a separate portable app. Referring now to Figure 50, a portable app 5000 is presented. Portable app 5000 enables a driver to send alerts and/or textual messages to an administrator or a client or an assigned user through the central server 14. At step 5010, the Alert process is initiated and the Driver makes a choice on whether to select a pre-loaded event or whether to generate a free form alert. At step 5020, the Driver chooses to select one or more pre-loaded events that describe the Alert. Any number of pre-loaded events may be presented to the Driver. For instance, an exemplary pre-loaded event may be an event describing a customs stop. Another exemplary preloaded event may be an event describing an accident. Still another exemplary pre-loaded event may be an event describing a potential risk of harm to the driver or the shipment. One of ordinary skill in the art will appreciate any number and variety of pre-loaded events may be presented to the driver. At step 5030, the Driver chooses to communicate the Alert through a free-form textual message alert. In this step, the Driver would simply type with a keyboard or keypad a textual description of the Alert that he/she wants to communicate with the administrator or a client or an assigned user through the central server 14. The Driver could use either steps 5020 or 5030 to communicate with the administrator that an updated route 5170 is needed. For example, if a Driver is stranded, the Driver could take photographs of the problem (e.g. road damage) and send them to the administrator. The photograph may be sent as a free-form message 5030, and the communication of the problem may be sent as a pre-loaded event 5020. It is understood that any combination of these two types of events 5020 or 5030 may be utilized by the Driver. When this request is communicated with the administrator, the administrator may either simply choose a new route from a pre-configured list of routes, or select a route based on undertaking the steps outlined in Figure 51. In either case, the newly selected route 5170 will be communicated to the Driver either manually or via the GPS unit located in the vehicle. After either steps 5020 or 5030, whether the driver selects one or more pre-loaded events or a textual message, the user uses the user interface, e.g., a virtual or actual button, to save the Alert and transmit it to central server 14, at 5040, which central server 14 correlates the message(s) with the particular shipment and sends alerts, as discussed above. The portable app 5000 returns to step 5010.

[0171] Map View 4110 also includes a Search Options area 4150 wherein the user viewing the map from a remote area could apply additional filters such as Shipment 4160, Device 4170, Dates 4180, Planned Route 4185, and Places Geofence 4190 to further restrict the search results on the map. Once the user makes selection(s) in the Search Options Area 4150, the user may apply the selections to the map by selecting the Apply icon 4195, to view a restricted search result in the map area 4120.

[0172] Referring now to Figure 42, a Warehouse screen 4210 is presented. The user may select from a plurality of trucks in the Warehouse screen 4210. When the user selects a particular truck 4220 from the Warehouse screen 4210, the user is directed to a Shipment screen 4310 of Figure 43. The Shipment screen 4310 further includes icons Documents 4320, Map 4330, Position 4340, and Delayed indicator 4350. When the user selects Documents 4320, one or more

Warehouse Documents (not shown) associated with the selected truck 4220 are displayed.

Warehouse Documents are the documents uploaded and saved by the user in the Distribution module 1130. When the user selects Map 4330, a map of the contents of the Box associated with the selected truck 4220 are displayed, as they were configured in the Distribution module 1130. When the user selects the Position icon 4340, a geographical positioning system (GPS) based location of the truck 4220 is displayed to the user. When the user selects the Delayed indicator 4350, the user is presented with the status of the truck, including any delays, and the reasons for such delays as recorded within the app. The user may also be able to select a Signs icon 4360 (short for signatures), as shown in Figure 43 A. Figure 43A is an exemplary screenshot of additional icons which may be presented with reference to the Shipment screen 4310, as represented by the modified Shipment Screen 4310 ¹ . When the user selects the Signs icon 4360, a display 4370 appears, which shows a display of all the signatures 4380 that were collected as part of the selected shipment on the Shipment screen 4310.

[0173] Referring now to Figure 44, an Administrator module 1170 is presented. Further, exemplary sub-modules associated with the Administrator module 1170 are also presented. These sub-modules include Producer 4410, Vehicle 4420, Device 4430, Users 4440, Dock 4450, and Receiver 4460. The Administrator module 1170 enables an administrator to view, set, and modify permissions to the app, as well as view, set, and modify the various features available in the app. For instance, the Administrator module 1170 may be used to set the plurality of trucks made available to the app.

[0174] Referring now to Figure 44 A, an exemplary Management module 4470 is presented. Further, sub-modules associated with the Management module 4470 are also presented. These sub-modules include Vehicle 4420, Dock 4450, and Driver 4480. The Management module 4470 may be configured as a sub-set of the Administrator module 1170 to enable a manager to view, set, and modify a corresponding sub-set of various features available in the app. For instance, the Management module 4470 may be used to assign one or more drivers to one or more of the plurality of trucks made available to the app.

[0175] Referring now to Figure 45, when a user selects the Administrator module 1170 from Figure 13, the user is directed to the Administrator module screen 4510 in Figure 45. In Figure 45, the Administrator module screen 4510 further includes icons for the sub-modules Producer 4410, Vehicle 4420, Device 4430, Users 4440, Dock 4450, and Receiver 4460. An

Administrator User (not shown) may select any of the sub-module icons presented on this screen to administer the usage and functioning of the app. For instance, the Administrator User may set a User Access Control Policy (not shown) for each user's access to the app. The User Access Control Policy would regulate if and how the user accesses the app. To illustrate, a Driver user 3450 may only have access to the Security module 1150, and an Administrator User may have access to all the module and sub-module specific screens in the app. As another example of the functionality of the Administrator User, Administrator User may add and remove Producers from the app using this Administrator module screen 4510. To add a producer, the Administrator User selects the Add icon 4580, and to remove a producer, the Administrator User selects the Delete icon 4590.

[0176] When the Administrator User selects the Add icon 4580 to add a Producer (not shown), the Administrator User is directed to a Producer screen 4610 shown in Figure 46. In Figure 46, Administrator User may add details regarding Producer and make Producer available to the app. The Producer screen 4610 allows Administrator User to enter several pieces of information regarding Producer, comprising fields Company Name 4621, Business Name 4622, R.F.C. 4623, Address 4624, City 4625, State 4626, Country 4627, Zip 4628, Latitude 4629, Longitude 4630, and Radio 4631. Once Administrator User enters information in one or more of the fields, the user is able to register the Producer information to make it available in the app. Accordingly, Administrator User may select the Register 4640 icon to register the information in the app. Once the Administrator User selects the Register 4640 icon, information entered in the fields is transmitted to a central server 14 for storage and retrieval. The Administrator User may also use the Clear icon 4650 to clear the information entered in the fields. Alternately, the Administrator User may choose to return to screen 4510 by selecting the exit icon 4660 in Figure 46.

[0177] Administrator User may also choose to view a list of current producers in the app by selecting the Producer icon 4410 in Figure 45. When a user selects the Producer icon 4410 in Figure 45, Administrator User is directed to the Producer list 4710 screen in Figure 47. Here, Administrator User may view a list of the active and inactive producers in the app. Figure 47 also includes additional information regarding the producers, such as a Location ID 4720, Company Name 4721, Business Name 4722, R.F.C. 4723, Address 4724, City 4725, State 4726, Country 4727, Zip 4728, Active status indicator 4729, Latitude 4730, Longitude 4731, and Alias 4732. In addition to viewing the list of producers, Administrator User may also choose to edit the details of any of the producers by selecting an appropriate edit icon located adjacent to the desired producer. For instance, Administrator User may select Edit icon 4750 associated with Location ID 13 to view and edit details of the producer in a separate screen. When

Administrator User selects Edit icon 4750, Administrator User is directed to the Producer screen 4610 shown in Figure 46. However, since Administrator User selected a producer with which some information was previously associated in the app, at least a portion of the previously associated information would be pre-populated in the fields on screen 4610. Administrator User may then choose to either edit or leave in place any information on the producer before registering the updated information with the app.

[0178] The servers 14, 34 and/or the computers of users 20, loading users 38, verification personnel 40, inspectors 44, other users 50, and drivers have logic configured to perform the various functions and processes described herein. "Computer" or "processor" as used herein includes, but is not limited to, any programmed or programmable electronic device or

coordinated devices that can store, retrieve, and process data and may be a processing unit or in a distributed processing configuration. Examples of processors include microprocessors, microcontrollers, graphics processing units (GPUs), floating point units (FPUs), reduced instruction set computing (RISC) processors, digital signal processors (DSPs), etc. "Logic," synonymous with "circuit" as used herein includes, but is not limited to, hardware, firmware, software and/or combinations of each to perform one or more functions or actions. For example, based on a desired application or needs, logic may include a software controlled processor, discrete logic such as an application specific integrated circuit (ASIC), programmed logic device, or other processor. Logic may also be fully embodied as software. "Software," synonymous with "module" as used herein, includes but is not limited to one or more computer readable and/or executable instructions that cause a processor or other electronic device to perform functions, actions, processes, and/or behave in a desired manner. The instructions may be embodied in various forms such as routines, algorithms, modules or programs including separate applications or code from dynamically linked libraries. Software may also be implemented in various forms such as a stand-alone program, a web-based program, a function call, a subroutine, a servlet, an application, an app, an applet (e.g., a Java applet), a plug-un, instructions stored in a memory, part of an operating system, or other type of executable instructions or interpreted instructions from which executable instructions are created. It will be appreciated by one of ordinary skill in the art that the form of software is dependent on, for example, requirements of a desired application, the environment it runs on, and/or the desires of a designer/programmer or the like. The computers of users 20, loading users 38, verification personnel 40, inspectors 44, other users 50, and drivers can be identical or substantially the same, e.g., they have the same software stored thereon or accessible thereto that provides different functionality for different users based on data that determines which user is permitted to use certain logic (e.g., some software is permitted to be executed only by certain users) and data that determines which users are permitted to read, write, and/or modify specific data (e.g., some data is available only to certain users).

[0179] Figure 53 is a high-level block diagram of an exemplary server 14, 34 (Figure 1). The server 14, 34 of Figure 2 has one or more processors 20 in communication with a server memory 5302 and one or more communication circuits 5304. Server memory 5302 includes one or more non-transitory computer readable media of one or more local or remote data storage devices. As used herein, "data storage device" means a device for non-transitory storage of code or data, e.g., a device with a non-transitory computer readable medium. As used herein, "non-transitory computer readable medium" mean any suitable non-transitory computer readable medium for storing code or data, such as a magnetic medium, e.g., fixed disks in external hard drives, fixed disks in internal hard drives, and flexible disks; an optical medium, e.g., CD disk, DVD disk, and other media, e.g., ROM, PROM, EPROM, EEPROM, flash PROM, external flash memory drives, so-called thumb drives, etc.

[0180] Data for the various functions and processes described herein can be stored on server memory 5302 permitting that data to be accessed by the computers of users 20, loading users 38, verification personnel 40, inspectors 44, other users 50, and drivers using the communication circuits 5304. The software used by the computers of users 20, loading users 38, verification personnel 40, inspectors 44, other users 50, and drivers perform the various functions and processes herein can be stored on one or more data storage devices local to the computers of users 20, loading users 38, verification personnel 40, inspectors 44, other users 50, and drivers can be downloaded or otherwise accessed from the server memory 5302, or some combination of both. Thus, server memory 5302 can also be used to store software for use by some of the computers of users 20, loading users 38, verification personnel 40, inspectors 44, other users 50, and drivers to perform the various functions and processes described herein. For example, the computers of users 20, loading users 38, verification personnel 40, inspectors 44, other users 50, and drivers can use a browser to access web-based software or other remote software hosted by the server 14, 34. The communication circuits 5304 can include any suitable bus interface circuits for communicating with the computers 14, 16 over wired or wireless communication media (e.g., radio frequency or optical communication media).

[0181] Referring now to Figure 54, an exemplary server memory 5302 is shown. Server memory 5302 includes one or more non-transitory computer readable media of one or more local or remote data storage devices having stored thereon (or having a pointer thereto stored thereon) any one or any two or more of the following software modules described herein and any associated data: Logistics - Available Docks 1420, Logistics - Ship Builder 1430, Logistics - Reports 1440, Logistics - Ship Progress 1450, Logistics - Cancel Shipment 1460, Logistics - Driver Receipt 1470, Distribution - Shipments 2110, Distribution - Documents 2120,

Distribution - Map 2130, Customs 1140, Security - Inspection 2910, Security - Contents

Confirmation 2920, Monitoring - Shipment Status 3620, Monitoring - Alert 3630, Monitoring - Map View 3640, Administrator - Producer 4410, Administrator - Vehicle 4420, Administrator - Device 4430, Administrator - Users 4440, Administrator - Dock 4450, Administrator - Receiver 4460, etc. "Pointer" as used immediately above in connection with data or software includes, but is not limited to, storing on a non-transitory computer readable media of a data storage device one or more data indicating the location on another data storage device from where the data or software can be downloaded or otherwise accessed.

[0182] Figure 55 is a schematic block diagram of an exemplary computer 5500 for use by various users of the various systems and methods herein, e.g., for use by users 20, loading users 38, verification personnel 40, inspectors 44, other users 50, and drivers. Exemplary computer 5500 comprises one or more processors 5502 in communication with a memory circuit 5504, one or more user input circuits 5506, a display circuit 5508, and one or more communication circuits 5510. Memory circuit 5504 comprises one or more non-transitory computer readable media of one or more data storage devices. In the context of a handheld computer, this memory circuit might include flash memory and/or RAM and/or ROM memories. In the context of a desktop or laptop computer, this memory circuit might include one or more fixed disk drives and/or RAM and/or ROM memories. Memory circuit 5504 will have stored thereon logic modules for performing the various functions and processes described herein or a program to access such logic modules from a remote memory, such as server memory 5302 (e.g., a browser program to access such logic modules from server memory 5302). User input circuits 5506 can include any one or more of buttons, keyboards, keys, touchpads, touchscreens, and associated support chips, and/or one or more communication circuits (e.g., RS-232 or USB) for an external keyboard or other external user input device, such as a mouse, track pad, or other pointing device, or other user input devices. Display circuit 5508 can include any one or more of LEDs, NxM textual displays, matrix displays on which a graphical user interface ("GUI") can be presented, e.g., a color or monochrome liquid crystal display ("LCD") or organic light-emitting diode ("OLED") display, with associated drive chips, and/or one or more graphics circuits (e.g., VGA or HDMI) for an external display, or other displays. Communication circuits 5510 include antennas and/or data ports and driver chips for sending and receiving communications with devices external to the computer 5500. Communication circuits 5510 can include any one or more of WiFi antennas and circuitry, LTE antennas and circuitry, GPS antennas and circuitry, CDPD antennas and circuitry, GPRS antennas and circuitry, GSM antennas and circuitry, UMTS antennas and circuitry, and other antennas and circuitry, USB ports and circuitry (e.g., standard, micro, mini, etc.), RS-232 ports and circuitry, proprietary ports and circuitry (e.g., APPLE 30 pin and

Lightning ports), RFID antennas and circuitry, NFC antennas and circuitry, bump technology antennas and circuitry, a Bluetooth antenna and circuitry, and other antennas, ports, and circuitry.

[0183] The various computers 5500 used by users 20, loading users 38, verification personnel 40, inspectors 44, other users 50, and drivers can be a computer, such as a portable computer (such as a tablet computer (e.g., an iPad) or a smart phone (e.g., an iPhone)) with an app stored thereon having some or all of the software modules shown in Figure 54, with associated data being stored on the server 14, 34. In the alternative, the computers 5500 used by users 20, loading users 38, verification personnel 40, inspectors 44, other users 50, and drivers can be a computer running browser software and some or all of the software modules in Figure 54 and associated data are hosted on the server 14, 34 with the computers used by users 20, loading users 38, verification personnel 40, inspectors 44, other users 50, and drivers being client devices. In exemplary embodiments, respective memories of these computers include stored logic to cause the processor(s) of the various computers herein to perform any one or any two or more of the functions, steps, and processes herein. Accordingly, in exemplary embodiments, a data storage device having a non-transitory machine-readable medium has stored instructions (e.g., computer executable instructions or instructions interpreted to generate computer executable instructions) that cause one or more processors to perform any one or any two or more of the functions, steps, and processes herein.

[0184] In exemplary embodiments, systems and method for tracking a carrier shipments (a carrier vehicle carrying a separate shipping container) include (a) a shipping container sensor system having (i) a sensor circuit configured to automatically generate in real time a shipping container sensor signal indicating at least one of whether a closure of the shipping container is closed and whether a lock of the shipping container closure is locked and (ii) a shipping container transmitter circuit that automatically receives the shipping container sensor signal and automatically in real time transmits a wireless shipping container sensor signal indicating at least one of whether the closure of the shipping container is closed and whether the lock of the shipping container closure is locked; and (b) a carrier vehicle system having (i) a carrier vehicle location circuit configured to automatically generate in real time a carrier vehicle location signal indicative of the location of the carrier vehicle, (ii) a driver user interface with which a driver of the carrier vehicle can input at least one status of the carrier shipment, (iii) a carrier vehicle transmitter circuit that automatically receives the carrier vehicle location signal and

automatically in real time transmits a wireless vehicle signal indicating at least one of the location of the carrier vehicle and the at least one status of the carrier shipment, and (iv) a processor in communication with at least the driver user interface and the carrier vehicle transmitter, the processor accepting via the driver user interface the at least one status of the carrier shipment and the processor communicating the at least one status of the carrier shipment to the a carrier vehicle transmitter circuit; and wherein one of the shipping container transmitter circuit, the carrier vehicle transmitter circuit, and an optional third transmitter circuit includes a non-local wireless transmitter that automatically in real time wirelessly transmits a non-local signal at least a kilometer away from the carrier vehicle indicating (i) at least one of whether the closure of the shipping container is closed and whether the lock of the shipping container closure is locked and (ii) at least one of the location of the carrier vehicle and the at least one status of the carrier shipment. In exemplary embodiments, the shipping container transmitter circuit includes a local transmitter that locally transmits the wireless shipping container sensor signal, the carrier vehicle transmitter circuit includes a local receiver circuit that receives the wireless shipping container sensor signal; and/or the non-local wireless transmitter is part of the carrier vehicle transmitter circuit and is configured to automatically in real time wirelessly transmit a non-local signal at least a kilometer away from the carrier vehicle indicating (i) at least one of whether the closure of the shipping container is closed and whether the lock of the shipping container closure is locked, (ii) the location of the carrier vehicle, and (iii) the at least one status of the carrier shipment. Exemplary embodiments further include a server system that receives and stores data corresponding to the information about the carrier shipment indicated in the nonlocal signal and that generates a user interface to provides information in response to client requests.

[0185] The description of specific embodiments herein has been given by way of example. From the disclosure given, those skilled in the art will not only understand the general inventive concepts and attendant advantages, but will also find apparent various changes and modifications to the structures and methods disclosed. For example, the general concepts are not typically limited to the implementation of the invention as a software application ("app"). Thus, for example, use of alternative user implementations, such as portable apps, is within the spirit and scope of the general concepts. As another example, although the embodiments disclosed herein have been primarily directed to a personal computer or a terminal, the general concepts could be readily extended to a portable computing device or other similar devices, and may be pursued with reference to a website and/or other online or offline mechanisms. It is sought, therefore, to cover such changes and modifications as fall within the spirit and scope of the general inventive concepts, as described and claimed herein, and equivalents thereof.

[0186] While the present invention has been illustrated by the description of exemplary embodiments thereof, and while the embodiments have been described in some detail, it is not the intention of the applicant to restrict or in any way limit the scope of the invention or appended claims to such detail. Additional advantages and modifications will readily appear to those skilled in the art. For example, any or all of the transmitters referred to herein as "local" transmitters may instead have a transmitter sufficiently powerful to communicate directly with the server, instead of communicating to the server via the control, unit 100. As another example, the general inventive concepts are not typically limited to the implementation of the invention as a software application ("app"). Thus, for example, use of alternative user implementations, such as portable apps running on standalone portable computers such as so-called smart-phones and tablet computers, are within the spirit and scope of the general inventive concepts. As another example, although certain aspects of the embodiments disclosed herein have been primarily directed to a personal computer or a terminal, the general inventive concepts could be readily extended to a portable computing device or other similar devices, and may be pursued with reference to using a browser to access data from the central server 14 via a website and/or other online or offline mechanisms. Additionally, the steps of methods herein may generally be performed in any order, unless the context dictates that specific steps be performed in a specific order. Therefore, the invention in its broader aspects is not limited to the specific details, representative apparatus and methods, and illustrative examples shown and described.

Accordingly, departures may be made from such details without departing from the spirit or scope of the applicant's general inventive concept.