Abstract: A system includes an orchestration engine and a smart container. The system can dynamically update a transport process for transporting the smart container to a destination based on status data to use a combination of multiple carriers. The smart container can report status notifications while the transport process is ongoing. Examples of carriers include national/global carriers, regional/local carriers, gig workers, corporate/contracted carriers, or short-range delivery services such as unmanned autonomous robots, land vehicles, or aerial vehicles (e.g., drones). As such, the system can take advantage of a diverse ecosystem of carriers and adapt the transport process in real-time to optimize for a target parameter such as a time remaining to the destination, a distance remaining to the destination, or a cost to complete the transport process.

Abstract: A portable device augments a shipping container with security and communications capabilities. The device includes multiple sensors, communications circuitry, and other electronic circuitry and/or mechanical components. The device can determine, based on output of the multiple sensors, an anomalous event experienced by the shipping container relative to an expected activity and communicate an indication of the anomalous event over a wireless network to a remote computer. The device also performs an action in response to the anomalous event or based on a command received from the remote computer.

Abstract: A system includes an orchestration engine and a smart container. The system can dynamically update a transport process for transporting the smart container to a destination based on status data to use a combination of multiple carriers. The smart container can report status notifications while the transport process is ongoing. Examples of carriers include national/global carriers, regional/local carriers, gig workers, corporate/contracted carriers, or short-range delivery services such as unmanned autonomous robots, land vehicles, or aerial vehicles (e.g., drones). As such, the system can take advantage of a diverse ecosystem of carriers and adapt the transport process in real-time to optimize for a target parameter such as a time remaining to the destination, a distance remaining to the destination, or a cost to complete the transport process.

Abstract: This disclosure describes techniques that enable an Internet of Things (IoT) pairing Controller to determine whether a pairing condition between a first IoT device and a second IoT device is a “sensed” pairing condition or a “not sensed” pairing condition. For example, the IoT pairing controller may receive, from a client device, a pairing request associated with a first IoT device and a second IoT device. The IoT pairing controller may generate pairing data for delivery to at least the first IoT device, and in doing so, determine the pairing condition. A notification may be generated for delivery to the client device indicating the pairing condition.

Abstract: Techniques are described herein for managing digital content subscription. The techniques include transmitting a request to access premium content from a playback device logged into a user account for a streaming service. The user device receives an optical code generated by the playback device. The user device is associated with a subscriber account for telecommunication services, which include the streaming service. The techniques also include deciphering the optical code to access a payment portal and logging into the payment portal using credentials associated with the subscriber account, wherein the subscriber account is associated with the user account. Payment is submitted for the premium content using billing information associated with the subscriber account via the payment portal and the premium content may be accessed via the user account.

Abstract: This disclosure describes techniques that enable an Internet of Things (IoT) pairing Controller to determine whether a pairing condition between a first IoT device and a second IoT device is a “sensed” pairing condition or a “not sensed” pairing condition. For example, the IoT pairing controller may receive, from a client device, a pairing request associated with a first IoT device and a second IoT device. The IoT pairing controller may generate pairing data for delivery to at least the first IoT device, and in doing so, determine the pairing condition. A notification may be generated for delivery to the client device indicating the pairing condition.

Abstract: An Internet of Things (IoT) pairing controller is described that enables an end-user to customize the implementation of IoT devices. The IoT pairing controller may receive a pairing request to pair a combination of active-active IoT devices or active-passive IoT devices. The IoT pairing controller may facilitate a selection of a pairing signal type that is used to pair the IoT devices, such as light, sound, heat, Bluetooth, and Wi-Fi. An end-user may select multiple pairing signal types, of which the IoT pairing controller may toggle between based on ambient environmental conditions, or as a failsafe confirmation of a “not sensed” pairing condition between IoT devices. The IoT pairing controller may associate client-defined statements with paired (i.e. sensed”) and unpaired (i.e. “not sensed”) pairing conditions of a pair of IoT devices.

Abstract: An Internet of Things (IoT) pairing controller is described that enables an end-user to customize the implementation of IoT devices. The IoT pairing controller may receive a pairing request to pair a combination of active-active IoT devices or active-passive IoT devices. The IoT pairing controller may facilitate a selection of a pairing signal type that is used to pair the IoT devices, such as light, sound, heat, Bluetooth, and Wi-Fi. An end-user may select multiple pairing signal types, of which the IoT pairing controller may toggle between based on ambient environmental conditions, or as a failsafe confirmation of a “not sensed” pairing condition between IoT devices. The IoT pairing controller may associate client-defined statements with paired (i.e. sensed”) and unpaired (i.e. “not sensed”) pairing conditions of a pair of IoT devices.

Abstract: Systems and methods are shown for providing access to proximate accessory devices for a mobile client. The mobile client directly physically scans a physical device identifier of a proximate accessory device to obtain a device identifier value. In one approach, a message is transmitted to an accessory access service that includes the scanned device identifier value and a task to be performed by the proximate accessory device and the service sends the task to the proximate accessory device. In another approach, a message that includes the scanned device identifier value is sent to an accessory access service, which obtains a network address corresponding to the scanned device identifier value and returns the network address to the mobile client, and the mobile client sends a task to the proximate accessory identifier value.