Controlling access to compartments of a cargo transportation unit

In some examples, a controller directs transport of a cargo transportation unit (CTU) to a plurality of pickup locations or a plurality of destination locations in response to requests of a plurality of requesters. The controller controls access to a plurality of compartments in the CTU, wherein controlling the access comprises selecting respective compartments of the plurality of compartments in which to place cargo items for the requests, the selecting based on characteristics of the cargo items and characteristics of the respective compartments.

BACKGROUND

Trucks, tractor-trailers, or tractors that are connected to chassis for carrying containers can be used to transport cargo that includes goods. Cargo can be transported from an origin (such as a factory, a warehouse, a retail outlet, etc.) to a destination (such as retail outlet, a warehouse, customer premises, etc.) along a route.

DETAILED DESCRIPTION

A cargo transportation unit (CTU) in the form of a moveable platform can be used to carry cargo items between different geographic locations. A “cargo item” can refer to any physical item that is to be delivered from one location to another location. “Cargo” can refer to one or more cargo items. In some examples, a CTU can be a container (that is attached to a tractor), a cargo carrying portion of a truck, or a trailer, where the container provides an enclosed space in which the physical items can be stored during shipment. In other examples, the CTU can include another type of carrier structure that is able to carry cargo items. More generally, the CTU can be part of, mounted on, or attached, as applicable, to a vehicle, such as a truck, a trailer, a tractor, a car, a railed vehicle (e.g., a train), a watercraft (e.g., a ship), an aircraft, a spacecraft, and so forth. The vehicle can haul the CTU that is part of, mounted on, or attached to the vehicle.

In some examples, a vehicle to which a CTU is attached to, mounted on, or part of, can be a driverless vehicle that can be self-driving. A driverless vehicle refers to a vehicle that is without a driver, i.e., a human that controls the movement of the vehicle while the driver is located on the vehicle. A self-driving vehicle has the intelligence and self-awareness to perform driving tasks, including driving itself from an origin to a destination, without any human driver on the vehicle.

When using driverless vehicles, the drop-off and/or pickup of cargo items (the “last mile of deliveries”) can present various issues. For example, there may not be a person to deliver the package to the doorstep of the recipient, or alternatively, there may not be a person to help load a cargo item onto the CTU. Moreover, when the CTU is to carry cargo items for multiple senders and/or recipients (where senders and/or recipients can generally be referred to as “tenants”), securing the cargo items to prevent theft or unauthorized access can also pose an issue. Additionally, a CTU can include multiple compartments of different characteristics (e.g., different sizes, different abilities to hold fragile or perishable cargo items, etc.), such that management of loading of different cargo items into the different compartments has to be performed. Also, when a CTU is used to transport cargo items to different recipients at different locations, the CTU may take a sub-optimal route that leads to inefficiencies.

In accordance with some implementations of the present disclosure, a controller is provided to manage access of a CTU to manage placement of cargo items in compartments of the CTU, to secure the storage of the cargo items in the CTU, and to select a more optimal route (based on one or more predefined criteria) of the CTU based on the cargo items carried by the CTU.

In the ensuing discussion, reference is made to example implementations where CTUs are moved by driverless vehicles. In other examples, CTUs can be moved by vehicles driven by human drivers.

FIG. 1illustrates a CTU100that is towed by a vehicle102(such as a tractor or other type of vehicle). In examples according toFIG. 1, the CTU100is separate from the vehicle102, and the CTU100can be attached to a tow platform106of the vehicle102to allow the vehicle102to tow the CTU100. In other examples, the vehicle102can be a truck, and the CTU100can be part of the truck. In further examples, the vehicle102can have a support structure on which the CTU100is placed.

In some examples, the CTU100includes a controller106that is able to perform various management tasks as discussed in the present disclosure. The controller106can include a hardware processing circuit which can include any one or more of the following: a microprocessor, a core of a multi-core multiprocessor, a microcontroller, a programmable gate array, a programmable integrated circuit device, or another type of hardware processing circuit. In further examples, the controller106can include a combination of a hardware processing circuit and machine-readable instructions (software or firmware) executable on the hardware processing circuit.

The CTU100includes multiple compartments108-1,108-2,108-3,108-4, and108-5. Although a specific number of compartments are shown inFIG. 1, it is noted that in other examples, a different number of compartments can be present in the CTU100. A “compartment” of the CTU100refers to any identifiable space (separated by a partition, for example) in the CTU100that can be used to store a specific cargo item (or a group of cargo items). In some cases, a compartment can have an access cover that is moveable between an open position (to allow access to the inner chamber of the compartment) and a closed position (to secure the inner chamber of the compartment). In some examples, the access cover can have a lock that can be actuated to lock the access cover to secure the compartment. In further examples, some compartments do not have access covers, but rather can have at least one side that is open to the inside of the CTU100.

The CTU100can be used to carry cargo items of a single requester or of multiple requesters. A “requester” can refer to any entity (a human, a machine, a software application, etc.) that is able to request that a specific cargo item (or group of cargo items) be transported from an origin to a destination.

In examples where there are multiple requesters that have requested the transport of cargo items by the CTU100, the different compartments108-1to108-5of the CTU100can be used to store cargo items for the different requesters. For example, a first compartment can be used to store cargo item(s) for a first requester, a second compartment can be used to store cargo item(s) for a second requester, and so forth.

The controller106is able to control access to the multiple compartments108-1to108-5in the CTU100, where controlling the access includes selecting respective compartments of the multiple compartments108-1to108-5in which to place corresponding cargo items for requests received from requesters. The selecting of compartments to store respective cargo items can be based on characteristics of the cargo items and characteristics of the respective compartments.

The characteristics of cargo items can be any or some combination selected from among: a size of a cargo item, a type of a cargo item, a weight of a cargo item, a fragility of the cargo item (e.g., a measure can be provided to indicate how fragile the cargo item is, such as fragile, not fragile, or some level of fragileness), a perishable status of a cargo item (e.g., an amount of time before the cargo item may perish, such as spoliation of fruits or vegetables, expiration of medicines or food items, etc.), an origin of a cargo item, a destination of a cargo item, and so forth.

The characteristics of compartments of the CTU100can include any or some combination selected from among: a size of a compartment, a type of cargo items that a compartment can accommodate, a location of a compartment within the CTU100, an air conditioning capability of a compartment (i.e., whether the compartment is capable of being heated or cooled), a shock absorption capability of a compartment (i.e., whether the compartment is attached to a shock absorbing element to protect the content of the compartment from shock), and so forth.

Although the controller106is shown as being part of the CTU100in examples according toFIG. 1, it is noted that in other examples, the controller106can be part of the vehicle102(and in communication with components of the CTU100), or alternatively, the controller106can be a remote controller that is able to communicate with the CTU100over a network108. The CTU100includes a communication transceiver110that is able to communicate with the network108. The communication transceiver110is able to transmit and receive information for the network108, which can be a wireless network.

In some examples, the network108can include a cellular network, a wireless local area network (WLAN), or any other type of wireless network. An example cellular network can operate according to the Long-Term Evolution (LTE) standards as provided by the Third Generation Partnership Project (3GPP). The LTE standards are also referred to as the Evolved Universal Terrestrial Radio Access (E-UTRA) standards. In other examples, other types of cellular networks can be employed, such as second generation (2G) or third generation (3G) cellular networks, e.g., a Global System for Mobile (GSM) cellular network, an Enhanced Data rates for GSM Evolution (EDGE) cellular network, a Universal Terrestrial Radio Access Network (UTRAN), a Code Division Multiple Access (CDMA) 2000 cellular network, and so forth. In further examples, cellular networks can be fifth generation (5G) or beyond cellular networks. In additional examples, a wireless network can include a WLAN, which can operate according to the Institute of Electrical and Electronic Engineers (IEEE) 802.11 or Wi-Fi Alliance Specifications. In other examples, other types of wireless networks can be employed by the controller108to communicate with a remote service, such as a Bluetooth link, a ZigBee network, and so forth. Additionally, some wireless networks can enable cellular IoT, such as wireless access networks according to LTE Advanced for Machine-Type Communication (LTE-MTC), narrowband IoT (NB-IoT), and so forth.

As noted above, the controller106can receive requests for transporting cargo items from requesters. InFIG. 1, a requester device112is shown coupled to the network108. The requester device112can include any type of computing device, such as any or some combination of the following: a desktop computer, a notebook computer, a tablet computer, a smartphone, a wearable device (e.g., a smart watch, smart eyeglasses, a head-mounted device, etc.), or any other type of electronic device that a requester can use to send a request to the controller106to request transport of a cargo item (or a group of cargo items) from an origin to a destination. In some examples, characteristics of a cargo item(s) can be entered by the requester for submission with the request. Alternatively, the requester can take a picture of the cargo item, and the controller106can determine the characteristics (e.g., size, type, weight, special needs, etc.) of the cargo item based on the picture of the cargo item, by performing image processing of the picture.

Although one requester device112is shown inFIG. 1, it is noted that in other examples, multiple requester devices112can be coupled to the network108to send requests to transport cargo items to the controller106. In response to the requests received from the requester device(s)112to transport cargo item, the controller106is able to direct transport of the CTU to multiple pickup locations and/or multiple destination locations. For example, in response to a request to transport a given cargo item, the controller106can direct the transport of the CTU100to a respective pickup location to pick up the given cargo item. The controller106can cause the vehicle102to move the CTU100to the respective pickup location.

The controller106is able to direct the CTU100to a point of exchange (drop-off of a cargo item or pickup of a cargo item) anywhere a person can meet the CTU100to perform the exchange. For example, a requester can direct the CTU100to drop off at an office location, at a home location, at a mall, or at any other location depending on which is more convenient. Also, in the context where there is a fleet of multiple CTUs capable of transporting cargo items for requesters, a selected CTU of the fleet of CTUs can be used to satisfy requests from the requesters.

In response to a request to transport the given cargo item, the controller106can select one of the compartments108-1to108-5to store the given cargo item, based on comparing characteristics of the given cargo item with characteristics of the compartments108-1to108-5.

For example, the given cargo item may be large, so that the controller106selects a compartment that has a size large enough to accommodate the given cargo item. As another example, the given cargo item may be perishable and thus should be protected with heat or cooling—in such case, the controller106selects a compartment with an air conditioning capability. As a further example, the destination of the given cargo item is far from the origin and thus likely to be one of the last cargo items to be delivered—in such case, the controller106selects a compartment that is farther away from the door of the CTU100so that access to cargo items that are likely to be dropped off earlier can be placed closer to the door of the CTU100for easier access. In further examples, other characteristics of cargo items and compartments can be used for selecting compartments to store respective cargo items.

At the pickup location (an origin for the pickup of cargo item(s) for transport to a destination), the controller106can unlock (without input from any human driver) the selected compartment(s), and can direct the requester, or other person who is dropping off the cargo item(s), to the selected compartment(s). For example, the controller106can send a message to the requester device112, or another device of the person dropping off the cargo item(s), informing the requester, or other drop-off person, that the cargo item(s) is (are) to be stored in the selected compartment(s). Each compartment of the CTU100can have an identifier. The message sent to the device of the person dropping of the cargo item(s) can include the identifier(s) of the selected compartment(s), so that the person can load the cargo item(s) into the identified compartment(s). An identifier of a compartment can include a number, a name (e.g., a string of alphanumeric characters), or any other distinguishing mark that is recognizable by the person dropping off the cargo item(s). The message sent to the device of the drop-off person can also include a secure token that allows the drop-off person to unlock the selected compartment(s). A discussion of secure tokens is provided further below.

In other examples, instead of sending a message to the device of the drop-off person, the CTU100can have a display that displays the identifier(s) of the selected compartment(s) in which the drop-off person is to place the cargo item(s).

In yet further examples, each compartment can have a light indicator that lights up (such as to a given color) to direct the drop-off person to the selected compartment(s). In alternative examples, the CTU100can be equipped with a speaker that can provide an audio announcement to direct the drop-off person to the selected compartment(s).

Once the drop-off person has loaded the cargo item(s) into the selected compartment(s), the controller106can cause locking of the selected compartment(s) to secure the cargo item(s), in examples where the selected compartment(s) is (are) equipped with an access cover and a lock. By locking a cargo item within a selected compartment, unauthorized retrieval of the cargo item, such as by another drop-off person at another pickup location or by a person picking up a cargo item(s) at a destination, is prevented.

Assuming that the CTU100has received more requests for transport of cargo items, the controller106can direct the transport of the CTU100to other pickup locations to pick up additional cargo items, and to select additional compartments for storing the other cargo items.

More generally, once the controller106has directed the transport of the CTU100to a particular pickup location (origin) to pick up a particular cargo item, the controller106can provide access to a compartment of the multiple compartments108-1to108-5, based on the characteristics of the particular cargo item and the characteristics of the compartment.

Once all cargo items of received requests have been picked up, the controller106can direct the transport of the CTU100to respective destination locations, where the cargo items are to be dropped off. There can be just one destination location to which the cargo items are to be delivered, or there can be multiple destination locations. At each respective destination location, the controller106can cause unlocking of the respective compartment(s), and can send a message to a person that is picking up the cargo item(s), where the message includes an identifier of the compartment(s) containing the cargo item(s) to be picked up. The person at the destination location can then go to the identify compartment(s) and remove the cargo item(s) from the identified compartment(s). In other examples, instead of sending a message to the device of the pickup person, the CTU100can include a display to direct the pickup person to the identified compartment(s), activate a light indicator of the identified compartment(s), or provide an audio announcement of the identified compartment(s). In further examples, a secure token can be sent to a device of the person picking up cargo item(s) from the CTU100to allow the person to unlock the identified compartment(s). Secure tokens are discussed further below.

FIG. 2shows an example of the requester device112that can be used to request transport, by a CTU such as the CTU100, of cargo item(s) from an origin to a destination. In some examples, the requester device112can download an application202that can be executed in the requester device112and which is able to present a cargo delivery graphical user interface (GUI)204according to some implementations to allow a user to submit requests to transport cargo items using the CTU100. The cargo delivery GUI204can be displayed by a display device205of the requester device112. Alternatively, the application202can include a web browser that allows the user of the requester device112to browse to a website, to cause display of a web page that presents the cargo delivery GUI204.

The cargo delivery GUI204includes control items (e.g., control menus, control buttons, text fields, etc.) that can be selected by the user or in which the user can enter information to generate a request to transport a cargo item. This request is transmitted by a communication transceiver206of the requester device112over a network (e.g., the network108ofFIG. 1) to the CTU100.

The application202can be stored in a non-transitory machine-readable or computer-readable storage medium208, and can be executed by a processor (or multiple processors)210.

In further examples confirmation of delivery and security can be accomplished by providing the device of the person picking up a cargo item with a capability to scan barcodes, QR codes, or other uniquely identifying indicia (more generally, “cargo codes”). For example, the device can include a camera and a scan application that is able to capture and recognize cargo codes. The device can also be provided with a secure token.

When the person picking up the cargo item arrives at the CTU, the person uses the secure token to unlock the appropriate compartment on the CTU. The person also confirms delivery by capturing an image of a cargo code (e.g., barcode QR code, or other unique identifying indicia).

Similarly, when a person drops off a cargo item for transport at the CTU, the drop-off person can capture an image of the cargo code as part of placing the cargo item into the corresponding compartment.

Using the combination of the cargo code capture and the secure token, a chain of trust is created, since it can be confirmed that an authorized person with an appropriate secure token dropped off the cargo item, and that another authorized person with an appropriate secure token picked up the cargo item. Depending upon which of the foregoing tasks were not properly taken, recourse can be made to the corresponding entity when a requested cargo item fails to reach its intended recipient.

FIG. 3is a block diagram of an example arrangement that includes the controller106and a compartment108. The compartment108can be any of the compartments108-1to108-5ofFIG. 1. The compartment108has an access cover302that can be moved between an open position (to allow access from outside the compartment108to an inner chamber304of the compartment108) and a closed position (to secure the inner chamber304of the compartment108). The access cover302has a lock306. The lock306can be actuated to a locked position to lock the access cover302to the main housing of the compartment108, to prevent unauthorized access of cargo item(s) stored in the compartment108. The lock306can also be actuated to an unlocked position to allow the access cover302to be opened to access to the inner chamber304of the compartment108, such as to place cargo item(s) into the inner chamber304, or to remove cargo item(s) from the inner chamber304.

The controller106controls a lock actuator308, which is able to actuate the lock306between the locked position and the unlocked position. The compartment108can be locked and/or unlocked independently of another compartment.

In some examples, the lock actuator308can include solenoid elements that can be energized to move the lock306between the locked position and the unlocked position. In other examples, the lock actuator308can include other types of actuating elements to control the state of the lock306. The controller106can send a control signal to the lock actuator308to cause the lock actuator to actuate the lock306between the locked position or the unlocked state.

In some examples, the controller106can receive an authentication input310to lock or unlock the compartment108. The authentication input310can be based on one or more input information, including as examples, a location of the CTU100and information identifying an authorized person who is dropping off cargo item(s) at an origin or picking up cargo item(s) at a destination.

The location of the CTU100can be based on information from a location sensor. The location sensor can include a Global Positioning System (GPS) receiver that determines a location based on communication with GPS satellites. Alternatively, the location sensor can determine a location based on triangulation of signals received by a communication transceiver (e.g., the communication transceiver110inFIG. 1) from multiple wireless base stations or wireless access points that have known positions.

Information identifying an authorized person can be based on a secure token carried by the authorized person. The secure token can be in the form of authentication information stored by an electronic device (e.g., a smartphone, a radio frequency identification or RFID tag, a smart card, etc.). As examples, the authentication information can include a username and password, or a personal identification code, or some other type of information that is unique to the authorized person or otherwise indicates that the authorized person is permitted to access a compartment of the CTU100.

The secure token is provided to the person dropping off or picking up cargo item(s) so that the person can use the secure token (a digital key) to unlock a compartment (or compartments). Secure tokens can be shared through a trusted resource and can be part of the buying/selling process. For example, if a buyer buys something on an online retailer, the online retailer can provide the buyer with the secure token to obtain the purchased product(s) from a CTU that delivers the purchased product(s). As another example, a seller of product(s) who has sold the product(s) on an online website can be provided with a secure token to allow the seller to drop off the sold product(s) on a CTU.

When the user shows up at the CTU100to take drop off or pick up cargo item(s), the user can provide the authentication information to the controller106, such as by activating the electronic device to send the authentication information to the controller106, such as over a wireless link, e.g., a Bluetooth link, a Wi-Fi link, an infrared link, etc. Alternatively, the user can place the electronic device in proximity to a sensor pad of the controller106, such as to enable Near Field Communication (NFC) between the electronic device and the sensor pad, so that the authentication information stored in the electronic device can be communicated to the controller106.

In other examples, the user can type in the authentication information on an input device (e.g., a keypad or keyboard) available at the CTU100.

Once a valid authentication input310is received by the controller106, the controller106can send a signal to the lock actuator308to lock the compartment108or unlock the compartment108. A valid authentication input310is detected by the controller106in response to the controller106determining that the CTU100is at a specified location and/or determining that received authentication information matches specified authentication information.

FIG. 4is a flow diagram of a process according to some examples. The process includes transporting (at402), using a vehicle (a driverless vehicle or a vehicle driven by a human driver), a CTU between a pickup location (an origin) and a drop-off location (a destination). In addition, a controller (e.g., the controller106ofFIG. 1) can control (at404) selective access to multiple compartments in the CTU, where controlling the selective access includes selecting respective compartments of the multiple compartments in which to place cargo items, where the selecting is based on characteristics of the cargo items and characteristics of the compartments.

In some implementations, as shown inFIG. 5, the controller106can track (at502) the loading of the CTU100, such that the controller106is aware of which compartments are filled with cargo items and which other compartments are still available to carry cargo items. As cargo items are placed into compartments, sensors in the compartments can send indications to the controller106that the compartments have been filled with cargo items.

The controller106can publish (at504) the available space of the CTU to a service that allows for such available space to be communicated to potential requesters. The service can be implemented as software executed on one or more computers, such as server computers or computers of a cloud. In some examples, the service can be accessed using the application202(FIG. 2) executed in the requester device112. The cargo delivery GUI204presented by the requester device112(FIG. 2) can be used to provide an indication of the available space. For example, the available space can be indicated as a list of available compartments (along with the characteristics of such compartments), or the available space can be indicated as a percentage of space available.

The controller106can receive (at506) a request to transport cargo item(s), such as through the cargo delivery GUI204(FIG. 2) or through some other mechanism through which a request can be submitted. The controller106can decide (at508) whether to accept or reject the request, based on characteristics pertaining to the cargo item(s) of the request, and characteristics of available compartments in the CTU100. For example, if the request specifies that a cargo item of a certain size is to be transported, and the controller106determines that the available compartments are all too small to accommodate the cargo item, then the controller106can reject the request. More generally, the controller106can reject the request in response to determining that there are no available compartments with characteristics to accommodate the cargo item(s) of the request. On the other hand, the controller106can accept the request in response to determining that there is an available compartment (or available compartments) with characteristics that can accommodate the cargo item(s) of the request. Other factors that may be considered in accepting or rejecting a request can include user requirements for loading/unloading a cargo item. The user may, for example, request a low compartment for heavy items—if such a low compartment is not available, then the request can be rejected. Alternatively, machinery may be used for loading and unloading that may have requirements for the compartment size and/or location. In such cases, the user and/or machinery may make a submission with the request for preferred or mandatory requirements for the compartments, which may factor in to the decisions to accept or reject a request to transport cargo item(s).

As shown inFIG. 6, in accordance with some examples, the controller106is able to determine (at602) a route of the CTU100, based on the destinations of the cargo items that are being transported by the CTU100. The determining of the route by the controller106can be based on one or more factors selected from among reducing a distance traveled by the CTU100, increasing an amount of loading of the CTU100, and reducing an amount of time to deliver cargo items. The route determined by the controller106based on the current cargo items stored in the CTU100can be referred to as a current planned route.

It is possible that after the controller106has determined the current planned route, the CTU100may receive another cargo item to be delivered to another destination. In response to detecting (at604) receipt of a new cargo item after a current planned route has been determined, the controller106can determine (at606) a new route that deviates from the current planned route.

The CTU100then delivers (at608) the cargo items according to the determined route (either the route determined at602or the route determined at606).

The controller106can provide intermittent or continual status updates regarding the cargo items during transport by the CTU100. Thus, using the application202of the requester device112, the requester is able to see (using information presented in the cargo item GUI204(FIG. 2) a current status of the transport of the requested cargo items(s) for the requester, such as a current location of the CTU100or an estimated time of arrival of the requested cargo item(s).

The foregoing refers to examples where the controller106associated with a CTU100can determine whether or not to accept a request for transport of cargo item(s). In other examples, as shown inFIG. 7, an arrangement can include a fleet700of CTUs. A cargo processing service702executed in a system704(including one or more computers) can be used to select a CTU from among the fleet of CTUs to satisfy a request706to transport cargo item(s).

The cargo processing service702, which can be implemented with software, can receive the request706, such as from a requester device (e.g.,112inFIG. 1). The cargo processing service702is also able to communicate with the controllers (e.g.,106) of the CTUs in the fleet700, to determine the load status and available compartments of the CTUs, as well as characteristics of the available CTUs.

The selection of a CTU from multiple CTUs to satisfy a transport request can be based on or more factors, such as a load status of a CTU (e.g., what percentage of the available compartments are filled), characteristics of the available compartments, distance of a CTU to the pickup location, the destinations of other cargo items carried by a CTU, and so forth. For example, a given CTU can be selected from among the multiple CTUs of the fleet700in response to determining that the given CTU has sufficient capacity to accommodate the number of cargo items in the request, and that the available compartments have characteristics that can accommodate the cargo items to be transported. Also, the cargo processing service702can select a CTU that is closer to a pickup location, or a CTU carrying cargo items that are closer to the destination of the requested cargo items.

FIG. 8is a block diagram of a system800, which can be the controller106ofFIG. 1or the system704ofFIG. 7. The system800includes a processor (or multiple processors)802, and a non-transitory machine-readable or computer-readable storage medium804that stores machine-readable instructions806(such as instructions executed by the controller106or the cargo processing service702). The machine-readable instructions806are executable by the processor(s)802to perform various tasks as discussed in the present disclosure.