CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of U.S. Provisional Application No. 63/070,414, filed August 26, 2020 and titled “Dynamic Planning of Last Mile Delivery” by Milos Urbanija.

SUMMARY

[0002] A provider box includes a housing, a storage compartment within the housing, a door enabling access to the storage compartment, a lock disabling access to the storage compartment via the door when engaged, and firmware coupled to the lock enabling its disengagement. The firmware is enabled to switch operation between multiple modes, each mode apportioning risk between transaction parties differently and each mode including a different set of requirements to be fulfilled to disengage the lock based on the apportionment. The transaction parties include the provider and at least two of a user, a merchant, a logistics service provider, an insurance service provider, and a payment service provider.

[0003] A method includes providing a box including a lock disabling access to a storage compartment in the box via a door when engaged. The method further includes apportioning risk between transaction parties, the transaction parties including the box provider and at least two of a user, a merchant, a logistics service provider, an insurance service provider, and a payment service provider. The method further includes requiring a set of requirements to be fulfilled to disengage the lock based on the apportionment. The method further includes reapportioning the risk between transaction parties. The method further includes requiring a different set of requirements to be fulfilled to disengage the lock based on the reapportionment.

[0004] A system includes a network of provider boxes, each provider box including a lock disabling access to a storage compartment in the box via a door when engaged. The system further includes firmware communicably coupled to the network. The firmware apportions risk between transaction parties for each transaction for each box. The firmware requires different sets of requirements to be fulfilled to disengage each lock based on the apportionment. The transaction parties include a provider of the network and at least two of: a user, a merchant, a logistics service provider, an insurance service provider, and a payment service provider.

BRIEF DESCRIPTION OF THE DRAWINGS

[0005] Apparatuses, systems, and methods for dynamic planning of last mile delivery are disclosed herein. In the drawings:

[0006] Figure 1 depicts a provider box for dynamic planning of last mile delivery in accordance with at least one embodiment;

[0007] Figure 2 is a flow diagram illustrating a method for dynamic planning of last mile delivery in accordance with at least one embodiment; and

[0008] Figure 3 is a block diagram illustrating a system for dynamic planning of last mile delivery in accordance with at least one embodiment.

[0009] It should be understood, however, that the specific embodiments given in the drawings and detailed description thereto do not limit the disclosure. On the contrary, they provide the foundation for one of ordinary skill to discern the alternative forms, equivalents, and modifications that are encompassed together with one or more of the given embodiments in the scope of the appended claims.

NOTATION AND NOMENCLATURE

[0010] Certain terms are used throughout the following description and claims to refer to particular system components and configurations. As one of ordinary skill will appreciate, companies may refer to a component by different names. This document does not intend to distinguish between components that differ in name but not function. In the following discussion and in the claims, the terms “including” and “comprising” are used in an open-ended fashion, and thus should be interpreted to mean “including, but not limited to . . . ”.

DETAILED DESCRIPTION

[0011] The following disclosure enables, inter alia, dynamic planning of the suitability of product sale and last mile delivery considering apportionment of risk. In product delivery logistics, the “last mile” of delivery to the customer is the most inefficient step of the process. It is the most expensive, most time-consuming, and riskiest step, however it is also the most crucial step to perform well for customer satisfaction. Some factors affecting last mile delivery include the following.

[0012] Infrastructure quality: poor transport infrastructure, inefficient routes, inefficient transport technology, and the like prolong travel time, increase costs, and cause delays.

[0013] Goods diversity: specific properties of individual products (e.g. toxicity, fragility, perishability, flammability, and the like) call for special handling and protections, which increase costs and cause delays.

[0014] Customer details: non-uniform addresses, remote locations, poorly accessible locations, unavailability of customers to receive packages, returns, and the like also increase costs and cause delays.

[0015] Shipment aggregation: unpredictable frequency, isolated locations, and customer dispersion often make it difficult to achieve a shipment aggregation that is financially sustainable or achieves economies of scale.

[0016] Accordingly, the last mile is the most costly and complex part of delivery. Because the shopping industry is entering a phase of hyper-competition, where even individuals demand to deliver and receive products to and from around the world, any reduction in complexity represents a significant competitive advantage. The embodiments disclosed herein reduce such complexity in the following ways.

[0017] Geographical optimization of distribution centers, which provides better coverage of customers while simultaneously controlling costs due to increased efficiency in shipment aggregation, delivery times, return times, and fuel consumption.

[0018] Real-time delivery tracking, which keeps customers informed of the delivery status thus making them more patient, less prone to filing complaints, and increasing their satisfaction. Messages about order dispatching, transit and delivery also ensure that the customer is available at the time and place of delivery if necessary. [0019] Implementation of suitable drop-off points in accessible locations such as shopping malls, post offices, apartment complexes, individual addresses, and the like, which increases security and simultaneously provides flexibility in customer pick-up.

[0020] Implementation and integration of autonomous vehicles, which decreases human error, increases safety, and lowers costs.

[0021] Temperature control, which keeps cold products cold, hot products hot, perishable items fresh, and flammable items safe.

[0022] Apportionment of various types of risk, which facilitates transactions by including parties that would otherwise refuse to participate.

[0023] Accordingly, Figure 1 illustrates an embodiment of dynamic planning for last mile delivery in accordance with at least one embodiment. Specifically, four provider boxes 100 are shown. A provider box includes a housing 102, a storage compartment 104 within the housing 102, a door 106 enabling access to the storage compartment 104, a lock 108 disabling access to the storage compartment 104 via the door 106 when engaged, and firmware 110 coupled to the lock 104 enabling its disengagement. The firmware 110 is enabled to switch operation between multiple modes, each mode apportioning risk between transaction parties differently and each mode including a different set of requirements to be fulfilled to disengage or engage the lock 108 based on the apportionment. Firmware may be software coupled to specific or specifically- purposed hardware or software permanently contained in specific or specifically-purposed hardware in various embodiments. In at least one embodiment, the provider programs the multiple modes into the firmware 110 and signals the firmware 110 to switch modes. The transaction parties include the provider and at least two of: a user, a merchant, a logistics service provider, an insurance service provider, a payment service provider, and the like.

[0024] A provider may design, manufacture, distribute, install, and/or maintain provider boxes 100. A user may be a customer of a merchant, purchase products, make payments, and/or access provider boxes 100 to take delivery of products by removing products from the storage compartment 104. A merchant may sell products to users, host shopping areas physically and online, accept payments, and/or deliver or have delivered products to provider boxes 100 by storing products in the storage compartment 104. A logistics service provider may accept products from merchants for delivery to users by accessing provider boxes 100. An insurance provider may insure products stored in provider boxes 100 for the benefit of any transaction party. A payment service provider may accept and disburse payments to any party of the transaction for products stored in provider boxes 100.

[0025] The transaction parties each bear risks. Payment risk of the merchant may include the merchant not being paid for a product and the like. Misdelivery risk of the logistics service provider or merchant may include a product being delivered to the wrong user, the product being damaged during delivery or storage, the product missing the target delivery time, the product not being delivered, and the like. Product or item-spoilage risk of the merchant or logistics service provider may include the product being spoiled during delivery or storage and the like. Identity risk of any transaction party may include the risk of revealing private information to another transaction party such as name, address, payment or banking information, contact information, affiliation or association information, biographical information, passwords and authentication information, biometric information, and the like. Vendor risk of any transaction party may include that party selecting a high cost, low reputation, or unreliable vendor and the like. For example, the merchant may choose a high cost logistics service provider for delivering a product, a user may choose a low reputation insurance service provider for insuring a product, or a merchant may choose an unreliable payment provider to accept payments. These are just some examples of vendor risk that could apply to any transaction party in relation to any other transaction party. Other examples of vendor risk, and other risks in general, are within the scope of this disclosure.

[0026] Use of provider boxes 100 to gate access to delivery, storage, and receipt of products allows for the reapportionment of some or all of one or more risks among one or more of the transaction parties. These different scenarios may be enforced by firmware 110 operating in different modes with each mode apportioning risk between transaction parties differently and each mode including a different set of requirements to be fulfilled to disengage or engage the lock 108 based on the apportionment. For example, the risk may include payment risk of the merchant and each mode may be associated with a different level of creditworthiness of the user. A threshold level of creditworthiness may be set by the provider. In a first mode, the user has high credit and the firmware 110 may require only user authorization to disengage the lock 108 to allow the user access to products in the storage compartment 104. As such, all payment risk of the merchant remains with the merchant. In a second mode, the user has medium credit and the firmware 110 may require user and payment service provider authorization to allow the user access to products in the storage compartment 104. As such, some payment risk of the merchant has been apportioned to the payment service provider. In a third mode, the user has low credit, and the firmware 110 may require user and merchant authorization to allow the user access to products in the storage compartment 104. As such, all payment risk of the merchant has been apportioned to the user because the merchant may refuse to provide authorization until the payment has cleared, thus retaining control over the product despite the product already having completed the last mile of delivery. In a fourth mode, the user has very low credit, and the merchant refuses to transact with the user. All payment risk of the merchant may be apportioned to the provider. As such, the firmware 110 may require user and provider or only user authorization to allow the user access to products in the storage compartment 104. In this way, a very low credit user is enabled to perform transactions with the merchant because the merchant is satisfied it will receive payment from the provider in the event of non-payment by the user. Additionally, if the provider sets the threshold to accommodate its appetite for risk, it can mitigate non-payment if only user authorization is required. Finally, the provider is in a unique position to mitigate non-payment if both provider and user authorization is required by restricting access to the provider box 100. Specifically, in such a scenario the firmware 110 may not require authorization of the payment service provider or merchant to disengage the lock 108 for the user.

[0027] The payment risk apportionment may work in reverse for a provider with a low appetite for risk. For example a very low credit user, for which the provider does not desire to assume payment risk, may require merchant authorization. A medium credit user, for which the provider is apportioned some payment risk may require payment service provider authorization depending upon transaction value, currently available credit potential, the user’s credit score, and similar criteria. A high credit user, for which the provider is apportioned all payment risk, may merely require user authorization.

[0028] The payment risk apportioned to the provider may be reapportioned to the insurance services provider in privity with the provider if the product or transaction is worth an amount above a threshold, again set by the provider. Similarly, multiple types of risks, in whole or in part, may be reapportioned by transaction parties at each and every stage of the transaction and delivery. This reapportionment may occur automatically in the case of preexisting consent, agreements, and relationships between the transaction parties. Based on the reapportionment, the requirements to disengage or engage the lock 108 to access the storage compartment 104 may change. At scale, and with automatic apportionment and reapportionment, the demand for delivery and receipt of products by individuals to and from anywhere in the world may be met cheaply, efficiently, and with high satisfaction. The following includes some examples of risk, apportionment of risk, and reapportionment of risk in various embodiments, but other examples are within the scope of this disclosure.

[0029] The risk may include misdelivery risk of the logistics service provider, and each mode may be associated with a different level of weather interference with delivery at the provider box 100. The weather interference may be measured by sensors at the provider box 100 or by a weather service as described with respect to Figure 3. In a low-interference mode, the logistics service provider may be apportioned all misdelivery risk by the firmware 110. In a high- interference mode, all misdelivery risk of the logistics service provider may be apportioned to the merchant, and the merchant may select the threshold above which interference is considered high. Some of the misdelivery risk apportioned to the merchant may be reapportioned to the user via a notification, prior to confirmation of the transaction by the user, that the transaction is unsuitable for delivery. Accordingly, if the user agrees, neither the merchant nor the logistics service provider will be responsible for misdelivery, and only user authorization will be required for the user to disengage the lock 108.

[0030] The risk may include vendor risk of the user, and each mode may be associated with a different logistics service provider. For example, each logistics service provider may place a bid for delivery based on measurements made by sensors of the products size, weight, value, and the like. Next, all vendor risk of the user for a transaction may be apportioned to the provider, and the firmware may require authorization of the logistics service provider with the lowest bid for the transaction to disengage the lock such that delivery to the box 100 may be completed only by that logistics service provider. In this way, the efficiency of automatic bids coupled to automatic restriction of the provider box 100 to the logistics service provider with the lowest bid may pass cost savings to merchants and users.

[0031] The risk may include item-spoilage risk of the logistics service provider. All itemspoilage risk may be apportioned to the provider, and the firmware 110 may require operational temperature control systems within the provider box 100 to disengage the lock 108 for the logistics service provider. As such, the provider has mitigated the item-spoilage risk it has been apportioned, which facilitates the transaction for each transaction party.

[0032] The risk may include identity risk of the user, and all identity risk may be apportioned to the provider. As such, the firmware 110 may not require any identification information of the user to be delivered to the merchant to disengage the lock 108 for the user. Similarly, other private information for each transaction party may be protected. Parties may protect their identity, the identity of counterparties, the identity of the products, sensitive payment information, confidential pricing information, confidential insurance information, and the like. Because authentication occurs at the provider box 100, and such authentication may be verified by the provider, anonymous transactions may be enabled.

[0033] In addition to weather interference, the provider box 100 may include sensors that measure the transaction item, providing much-needed data to the transaction parties to determine their willingness to bear risk. For example, the height, width, length, temperature, weight, and similar characteristics of the products may be measured at the provider box 100. Accordingly, with this information verified or verifiable, the insurance provider may be willing to participate in transactions, the provider may be willing to bear risk to facilitate transactions, other parties gain confidence in potentially anonymous transactions, and the like.

[0034] A method 200 of dynamic planning of last mile delivery in at least one embodiment is shown in Figure 2. The method 200 may include any step or process described herein. At 202, a box including a lock disabling access to a storage compartment in the box via a door when engaged is provided. A discussion of how authorizations engage and disengage the lock will be helpful. After purchase, a merchant may schedule a delivery with the logistics service provider, a member of which carries a mobile device including an application provided by provider. The same or similar application is on a mobile device of the user. The applications are communicably coupled to the provider, which can provide encrypted authorization tokens to the mobile devices. The encrypted authorization tokens may include authorizations of any transaction party including the provider, payment information, identity information, and the like. As such, the mobile devices of the logistics service provider and/or user may contain the authorizations of any transaction party such as the merchant, provider, insurance provider, payment services provider, and the like. Accordingly, a signal to engage or disengage the lock of a provider box from any mobile device may include such tokens, even if the owner of the mobile device is not the same transaction party as the transaction party associated with the authorization signal, and different tokens may be required by the firmware operating in different modes. Such signals may be sent from the mobile devices to the firmware of the provider box via near field communications, Bluetooth, or sound modulated connection in various embodiments. Additionally, the devices may receive return signals generated by the firmware of the provider box containing tokens as well as confirmations of the lock engaging or disengaging. Such confirmations may be forwarded to the various transaction parties through the applications and provider. In other embodiments, provider firmware directly communicates with provider box firmware to engage and disengage the lock based on authorizations from the mobile devices. The provider box firmware may also return error codes representing the incorrect box, an already occupied box, and the like. Accordingly, the logistics service provider may use a mobile device to disengage the lock, deliver the product to storage compartment of the provider box, and reengage the lock. Confirmations of delivery may be sent to the transaction parties. The user may use a mobile device to disengage the lock, retrieve the product from the storage compartment, and reengage the lock. Confirmations of receipt may be send to the transactions parties.

[0035] Continuing with Figure 2, at 204 risk is apportioned between transaction parties. As discussed above, the risk may be of various types, and the transaction parties may include the box provider and at least two of: a user, a merchant, a logistics service provider, an insurance service provider, a payment service provider and the like. At 206, a set of requirements is required to be fulfilled to disengage the lock based on the apportionment. As discussed above, the provider box firmware may operate in multiple modes representing various sets of requirements.

[0036] At 208, the risk is reapportioned between transaction parties. In addition to the reapportionment discussed above, reapportioning the risk may include suggesting an alternative item for the transaction for display by the merchant to the user, and the suggestion may be based on the size of the provider box. For example, the merchant may suggest a smaller alternative product to the user because provider boxes at which the user can retrieve products cannot house the originally selected product. In another embodiment, reapportioning the risk may include suggesting an alternative item for the transaction for display by the merchant to the user based on weather at the provider box. For example, in the case of rain the merchant may suggest a waterproof alternative product to the user because the originally selected product will spoil in the rain. In this way, the merchant has mitigated its misdelivery risk by reapportioning it to the user. Similarly, any transaction party may reapportion any type of risk during any applicable stage of the transaction.

[0037] At 210, a different set of requirements is required to be fulfilled to disengage the lock based on the reapportionment. As discussed above, the provider box firmware may operate in multiple modes representing various sets of requirements, and as such the firmware may begin operating in a different mode for the reapportionment. For example, an authorization from the user that the rain has ceased may be required to disengage the lock based on the misdelivery risk reapportionment discussed above.

[0038] Figure 3 illustrates a system 300 including six segments 1, 2, 3, 4, 5, 6 that make up a platform of firmware, hardware, and software for dynamic planning of last mile delivery. Modules or engines may include computer-readable mediums such as internal data storage and memory having software along with one or more processor cores that execute the software and perform any appropriate steps described in this disclosure. The software configures the system 300 to interact with system users via one or more input/output devices (such as a keyboard and display through which any final or intermediate value, diagram, information, signal, notification, or alert described in this disclosure may be displayed). Among other things, system 300 processes data received from modules and generates a representative display. The segments and components of each segment of the system 300 may be arranged differently, omitted, combined, or separated in various embodiments.

[0039] The system 300 includes a network of provider boxes 351. As described above, each provider box includes a lock disabling access to a storage compartment in the box via a door when engaged. The system 300 further includes firmware 350 communicably coupled to the network 351. In contrast to Figure 1, the firmware 350 does not reside on the provider box, but on servers provided by provider. Here, the firmware 350 apportions risk between transaction parties for each transaction for each box. As described above, the transaction parties include a provider of the network and at least two of: a user, a merchant, a logistics service provider, an insurance service provider, a payment service provider, and the like. The firmware 350 requires different sets of requirements to be fulfilled to disengage each lock based on the apportionment. [0040] For example, misdelivery risk of the logistics service provider may be apportioned to the provider. As such, the firmware 350 may assign the transaction to a provider box in the network 351 with the highest probability of delivery success and require authorization of the logistics service provider to disengage the lock of the assigned provider box. Factors affecting the probability of delivery success to a provider box may include weather at the provider box, previous delivery success by the logistics service provider to the provider box, transport infrastructure, route efficiency, goods diversity, user details, use of autonomous vehicles, and/or geographic isolation. As discussed above, the provider may set a threshold of creditworthiness of the user (such as credit score), or the merchant may set a weather-interference threshold (such as temperature or chance of rain) to reapportion misdelivery risk. In this way, the many factors that affect the probability of last mile delivery may be represented by a threshold to apportion or reapportion some or all of the many types of risks to any of the transaction parties. The network of provider boxes 351 may include active boxes and passive boxes, and data from the active boxes may influence the apportionment for transactions for passive boxes.

[0041] The first segment 1 includes a sensors network 302, which may include different types of sensors that convert changes in the physical environment into information signals. The sensors measure, process, and send the captured information to the firmware 350 through the communication data center 310 in the second segment 2. The captured information can be of different types: temperature, humidity, air pressure, wind speed and direction, solar radiation, etc. This provides a constant source of updated information from individual locations and from different sources such as heat pumps, furnaces, weather stations, provider boxes, boxes of other providers, and the like. As such, continuous measurement of certain physical quantities is enabled, and apportionment or reapportionment of various risks may be performed based on the measurements.

[0042] The second segment 2 includes a communication data center 310, which may be a universal web interface that uses a standard mode of communication. The standard prescribes the necessary components for successful connection of different types of sensor systems: record format (e.g. XML, JSON, etc.), form, input parameters, and types of individual data. The communication data center 310 enables a permanent connection and a request-response mode of data transfer. For micro-sensors, which due to their minimalist architecture do not allow for standardized interfaces, the standard enables classic binary connection to a specially adapted communication protocol.

[0043] The third segment 3 includes a temporary database 330 populated with data processed by filtering, sorting, and formatting modules 320. The temporary database 330 is used for direct storage of data from sensor systems and their conversion into standard data types of the provider platform and firmware 350. In this segment 3, verification of data authenticity, data filtering, sorting scaling, and the like takes place.

[0044] The fourth segment 4 includes modules for machine learning 342, artificial intelligence 344, which together form a module 340 enabling interpolation, pattern recognition, micro prediction, and the like. In this segment 4, the data obtained from physical source sensor systems 348, 302 is combined with weather information from different weather providers 346 that allow access through their web services. Using the combined information, data interpolation, weather forecasting at micro-locations, pattern recognition, detection of individual field sensor failure, and the like are performed with artificial intelligence and machine learning procedures, algorithms, and software. Accordingly, apportionment or reapportionment of various risks may be performed based on the results.

[0045] The fifth segment 5 includes firmware 350, which may be software coupled to specific or specifically-purposed hardware or software permanently contained in specific or specifically-purposed hardware in various embodiments. The firmware 350 includes multiple modules such as a customer credit store module 356, a clearing and settlement module 357, a fraud detection module 358, a logistics management module 359, a merchant management module 360, a mobile application management module 361, a box management module 362, a user management module 363, a system administration module 364, an electronic store module 365, a database module 366, and an electronic store user interface module 367.

[0046] The customer credit store module 356 enables capturing large amounts of different data both from the firmware 350 and external sources through dedicated data interfaces. The module may be installed internally as an integral part of the firmware 350, or it may be connected as an external application connected to the firmware 350 through a data interface. Based on an analysis of users’ behavioral patterns via artificial intelligence and other weighted personalized scoring models, which combine provider data with thousands of pieces of external data such as location information, web search results, behavioral tracking, technical details of devices used by users, data for mobile applications, and the like, a relatively precise prediction of users’ payment behavior is possible. A high-quality prediction assists in making informed and profitable credit decisions in real time, which can be automatically or manually administered. Accordingly, apportionment or reapportionment of various risks may be performed based on the results.

[0047] The clearing and settlement module 357 may provide the necessary provider infrastructure for electronic payments with different payment methods including credit/debit cards and bank payments such as direct debit or bank transfers. A third party payment service provider enables provider to act as a super merchant and a payment service provider at the same time towards the user, accepting a wide range of payments through one channel, because the payment service provider systems work with recipient banks (payment processors) to manage the whole transaction process. The role of payment service provider is to ensure card-on-file service (the process of collecting and securely storing payment card credentials in accordance with regulations) and digital tokenization of cards, which are essential for card-not-present environments that facilitate payment methods such as one-click orders and recurring orders. Accordingly, apportionment or reapportionment of various risks may be performed based on this information.

[0048] The fraud detection module 358 enables the provider to operate differently depending on the status of the user and the status of the merchant. For example, the provider may behave as a normal proxy, which in the case of payment of user X to merchant Y is a direct intermediary that authorizes payment only after a positive payment service provider authorization. As another example, the provider may perform payment authorization on its own, if the user fulfills the criteria of the credit score mechanism, by which provider assumes the payment risk of the merchant. The advantage enabled is the speed of the transaction, as settlement between the provider and the payment instrument issuer takes place later. To lower the risk for the provider, higher value transactions may be insured with insurance services providers. Aside from the possibility of payment insurance, other services related to direct or indirect insurance are possible such as delivery insurance, goods or services insurance, and the like. The relation between the provider and an individual insurance services provider may be regulated by a contract, which may be saved in a digital form on the firmware 350. Accordingly, apportionment or reapportionment of various risks may be performed based on this information. [0049] The logistics management module 359 enables complete manipulation and administration of logistics service provider information.

[0050] The merchant management module 360 may include a set of software tools and databases intended for operations involving merchants. A merchant may be any registered legal entity that wishes to offer the provider service to its users and meets the minimum technical criteria for integration into the system 300, e.g., fulfills all legal regulations and owns an online shop, physical shop, or a shop in the form of a mobile application. The firmware 350 may include several adapted standardized data interfaces (Web Service, API) through which merchants may connect their shop to the provider. Integration of the provider service into the merchant’s application may be performed beginning with a contract between the provider and the merchant, and completed with a technical integration of the provider interface into the merchant’s shop. The contract may comprehensively regulate the relationship between the merchant and the provider. Specifically, inter alia, the contract may define the services provided to the merchant by provider, the commissions, the frequency of settlements, the reporting frequency and method, the technical integration method, the preferred logistics service provider, risk apportionment and reapportionment settings, configurations, and preferences, and other relational details. The contract may be saved in a digital form on the firmware 350. Its main attributes (merchant details, services information, and the like) may be used for setting up the merchant's account. The provider service is visible in the merchant’s online or mobile shop similarly to other payment schemes (credit cards, debit cards, and the like) and behaves similarly for the user, with the main difference being that it offers other services to the user during payment such as product delivery, product insurance, product return, and the like. The provider may have a payment guarantee obligation to the merchant, and the settlement frequency, method, and commission may be defined in the contract. Accordingly, apportionment or reapportionment of various risks may be performed based on this information.

[0051] The mobile application management module 361 enables the user to monitor the logistical process through the provider user mobile application or through the provider user portal, and once he or she is notified of arrival, his or her task is to physically take over the package. The user may initiate the take-over operation through his or her provider user mobile application, with which he or she first identifies the box through near field communications protocol or by reading the identification barcode or QR code on the box. The user may launch a request to open the selected box. The provider mobile application may send the request to the firmware 350, which verifies the user and the request and prepares a command string if the risk requirements are fulfilled. The command string for opening the box may be sent from the user’s mobile device or application to the box’s lock in various embodiments. If the opening command is successfully transmitted, the lock may return this as information to the mobile application, which forwards it to the firmware 350, and the box opens. If the transmission is unsuccessful, the user may have a limited time interval available in which he or she may perform a certain number of repeated attempts to open the box. In case of systemic errors, such as incorrect box, occupied box, etc., the lock may return the relevant error code, which the user mobile application may show to the user and forward to the firmware 350. The mobile application management module 361 ensures the functionalities of, and controls access to, mobile applications used on mobile devices such as smart phones and tablets. Access control on the level of applications allows administrators to manage and protect application data. The mobile application management module 361 enables control over providing, updating, and removing mobile applications, monitoring application performance and usage, and remote deletion of data from managed applications. Other functions of the mobile application management module 361 are: updating applications, controlling application reliability and operation, verifying user identity, reporting application crashes, managing application versions, managing application configurations, system push notification services, analysis of application usage, managing incidents, and the like. Accordingly, apportionment or reapportionment of various risks may be performed based on this information.

[0052] The box management module 362 enables complete manipulation and administration of the provider boxes. The system 300 may be integrated with logistics service providers, which performs tasks such as collecting, packaging, storing and distributing products. Logistics service providers may also enable shipment tracking and direct or indirect notifications to senders and recipients. The relationship between provider and a logistics service provider may be regulated by a contract, which defines all the obligations and other important attributes of the operation of both sides. The merchant may also be in privity with the logistics service provider. The logistics service provider data, intended for up-to-date delivery tracking, may be aggregated on the firmware 350 or provider may act as a proxy to logistics service provider’s data center depending on the contractual relationship. Accordingly, apportionment or reapportionment of various risks may be performed based on this information. [0053] The user management module 363 manipulates user information. A user may be any natural or legal person registered by the firmware 350 that wishes to use the system 300 and fulfills the minimum criteria for use and registration into the provider system. For example, the user fulfills all legal requirements, possesses a mobile device, or owns a provider box. The user may download a provider application to his or her mobile device. After installation, “know-your- customer” and anti-money laundering requirements may be fulfilled, and the user may input his or her credit or debit card information. The user’ s card information may be sent to the chosen payment service provider, which enables tokenization of the payment card. Simultaneously, a user account may be created to link all of the user’s transactions. The account may be divided into sub-accounts devoted to different types of transactions, e.g. financial, logistical, informational, validational, and the like. Part of the user registration process may also be association with a mobile or stationary provider box, which may be private or public. At registration, a user’s credit score may be initialized. The rating information may be obtained from institutions that collect such data (banks, insurance companies, and other service providers). If this information is not available, the credit score may be generated automatically based on the user’s transactions data. Based on the assigned initial credit score and registered bank card, credit/debit limits may be set in the user account. The setting operation can be automatic, based on the criteria and algorithms, or manual with the assistance of an administrator. Accordingly, apportionment or reapportionment of various risks may be performed based on this information.

[0054] The rights and obligations of a user may be regulated by a contract between the provider and the user. The contract may be automatically generated when the user registers, and may be stored on the firmware 350. Any change, such as addition of user rights, change of terms and conditions, or addition of new services may be reflected in the contract. Accordingly, apportionment or reapportionment of various risks may be performed based on this information.

[0055] The system administration module 364 enables complete manipulation and administration of the system 300.

[0056] The electronic store module 365 enables settings and preferences of various electronic stores to be stored on the firmware 350. For example, an online shop delivering food products may color codes items that are suitable or not suitable for delivery based on the weather conditions at the given location of the provider box. Items may be highlighted with green, yellow, and red markings meaning suitable, less suitable, and unsuitable for delivery, respectively. The sources of data used to inform the coding are based on a macro-location data (e.g. weather forecast of state weather centers), intermediate-location data (e.g. heat pumps in apartments showing the current temperature in a wider delivery area), and micro-location data (the box’s temperature and humidity sensors). Data based on user responses may also be used. Accordingly, apportionment or reapportionment of various risks may be performed based on this information.

[0057] The database module 366 enables storage and efficient retrieval of data stored on the firmware 350.

[0058] The electronic store user interface module 367 enables an interface for provider on the electronic stores of merchants.

[0059] By using modules in this way, the firmware 350 may provide a separate portal for each transaction party, such portals allowing their respective parties to influence the apportionment by passing threshold checks as described above. The use of separate portals enables enforcement of requirements that no user identification data be allowed to pass through the merchant portal and no merchant identification data be allowed to pass through the user portal. In at least one embodiment, the firmware 350 apportions all payment risk, misdelivery risk, and identity risk to the provider, and the user and merchant remain anonymous to the other.

[0060] The fifth segment 5 also includes networks to which the firmware 350 is communicably coupled such as a provider box network 351, a merchant network 352, an insurance services provider network 353, a payment services provider network 354, and a user network 355. Each of these networks may be provided by their respective transaction parties. Communication with these networks enables fast or automatic apportionment or reapportionment of risk because transaction parties may provide authorizations to the firmware 350 using these networks.

[0061] The sixth segment 6 includes a product selection smart agent module 370, which aggregates data and suggests potential solutions for the customer including proposals on purchases and delivery optimization. For example, based on collected data on nearby weather conditions and user association with a provider box, the agent only displays (or prominently features) items that are suitable for delivery into the box in the given weather conditions. As such, the user has an optimum last mile delivery experience. [0062] The sixth segment 6 also includes a logistics service provider network 372, which is communicably coupled to the firmware 350. At each provider box initialization, the user may input the micro-position of the box. For example, if the box is on a wall in a shaded part of a building, such data is useful for last mile optimization. Additionally, the box may collect data at a specified time period, e.g., each time the box is opened, or continuously. When the macro, intermediate, and micro data are combined, the provider system may use artificial intelligence, such as neural networks, to not only determine current conditions, but predict conditions and use those predictions to determine which products to show and further optimize last mile delivery. In this way, active box units may be a data source for passive or non-communicative box units. Additionally, mobile boxes may be repositioned as part of optimization at the authorization of any transaction party. Accordingly, apportionment or reapportionment of various risks may be performed based on this information.

[0063] In some aspects, apparatuses, systems, and methods for dynamic planning of last mile delivery are provided according to one or more of the following examples.

[0064] Example 1 : A provider box includes a housing, a storage compartment within the housing, a door enabling access to the storage compartment, a lock disabling access to the storage compartment via the door when engaged, and firmware coupled to the lock enabling its disengagement. The firmware is enabled to switch operation between multiple modes, each mode apportioning risk between transaction parties differently and each mode including a different set of requirements to be fulfilled to disengage the lock based on the apportionment. The transaction parties include the provider and at least two of: a user, a merchant, a logistics service provider, an insurance service provider, and a payment service provider.

[0065] Example 2: A method includes providing a box including a lock disabling access to a storage compartment in the box via a door when engaged. The method further includes apportioning risk between transaction parties, the transaction parties including the box provider and at least two of: a user, a merchant, a logistics service provider, an insurance service provider, and a payment service provider. The method further includes requiring a set of requirements to be fulfilled to disengage the lock based on the apportionment. The method further includes reapportioning the risk between transaction parties. The method further includes requiring a different set of requirements to be fulfilled to disengage the lock based on the reapportionment. [0066] Example 3 : A system includes a network of provider boxes, each provider box including a lock disabling access to a storage compartment in the box via a door when engaged. The system further includes firmware communicably coupled to the network. The firmware apportions risk between transaction parties for each transaction for each box. The firmware requires different sets of requirements to be fulfilled to disengage each lock based on the apportionment. The transaction parties include a provider of the network and at least two of: a user, a merchant, a logistics service provider, an insurance service provider, and a payment service provider.

[0067] The following features may be incorporated into the various embodiments described above, such features incorporated either individually in or conjunction with one or more of the other features. The risk may include payment risk of the merchant and each mode may be associated with a different level of creditworthiness of the user. All payment risk of the merchant may be apportioned to the provider for a transaction with a user with a level of creditworthiness above a threshold. The firmware may not require authorization of the payment service provider or merchant to disengage the lock for the user. The payment risk apportioned to the provider may be reapportioned to the insurance service provider in privity with the provider if the transaction is worth an amount above a threshold. The risk may include misdelivery risk of the logistics service provider and each mode may be associated with a different level of weather interference with delivery at the provider box. All misdelivery risk of the logistics service provider may be apportioned to the merchant for a transaction with a level of weather interference above a threshold. Some of the misdelivery risk apportioned to the merchant may be reapportioned to the user via a notification, prior to confirmation of the transaction by the user, that the transaction is unsuitable for delivery. The risk may include vendor risk of the user, and each mode may be associated with a different logistics service provider. All vendor risk of the user for a transaction may be apportioned to the provider, and the firmware may require authorization of the logistics service provider with the lowest delivery cost for the transaction to disengage the lock. The risk may include item-spoilage risk of the logistics service provider. All item-spoilage risk may be apportioned to the provider, and the firmware may require operational temperature control systems within the provider box to disengage the lock for the logistics service provider. The provider box may further include sensors that measure the transaction item, the apportionment based on the measurement. The risk may include identity risk of the user, and all identity risk may be apportioned to the provider. The firmware may not require any identification information of the user to be delivered to the merchant to disengage the lock for the user. Reapportioning the risk may include suggesting an alternative item for the transaction for display by the merchant to the user, and the suggestion may be based on the size of the provider box. Reapportioning the risk may include suggesting an alternative item for the transaction for display by the merchant to the user, and the suggestion may be based on weather at the provider box. The risk may include misdelivery risk of the logistics service provider, and all misdelivery risk for a transaction may be apportioned to the provider. The firmware may assign the transaction to a provider box with the highest probability of delivery success and require authorization of the logistics service provider to disengage the lock of the assigned provider box. Factors affecting the probability of delivery success to a provider box may include weather at the provider box, previous delivery success by the logistics service provider to the provider box, transport infrastructure, route efficiency, goods diversity, user details, use of autonomous vehicles, and geographic isolation. The firmware may provide a separate portal for each transaction party, such portals allowing their respective parties to influence the apportionment by passing threshold checks. No user identification data may be allowed to pass through the merchant portal and no merchant identification data may be allowed to pass through the user portal. The firmware may apportion all payment risk, misdelivery risk, and identity risk to the provider, and each of the user and merchant remain anonymous to the other. The network of provider boxes may include active boxes and passive boxes, and data from the active boxes may influence the apportionment for transactions for passive boxes.

[0068] The foregoing description of the specific embodiments will so fully reveal the general nature of the embodiments herein that others can, by applying current knowledge, readily modify and/or adapt for various applications such specific embodiments without departing from the generic concept, and, therefore, such adaptations and modifications should and are intended to be comprehended within the meaning and range of equivalents of the disclosed embodiments. It is to be understood that the phraseology or terminology employed herein is for the purpose of description and not of limitation. Therefore, while the embodiments in this disclosure have been described in terms of preferred embodiments, those skilled in the art will recognize that the embodiments herein can be practiced with modification within the spirit and scope of the embodiments as described herein. Numerous other modifications, equivalents, and alternatives, will become apparent once the above disclosure is fully appreciated. It is intended that the following claims be interpreted to embrace all such modifications, equivalents, and alternatives where applicable.