WO2022046839A1 - Planification dynamique de distribution du dernier kilomètre - Google Patents

Planification dynamique de distribution du dernier kilomètre Download PDF

Info

Publication number
WO2022046839A1
WO2022046839A1 PCT/US2021/047449 US2021047449W WO2022046839A1 WO 2022046839 A1 WO2022046839 A1 WO 2022046839A1 US 2021047449 W US2021047449 W US 2021047449W WO 2022046839 A1 WO2022046839 A1 WO 2022046839A1
Authority
WO
WIPO (PCT)
Prior art keywords
provider
risk
box
user
transaction
Prior art date
Application number
PCT/US2021/047449
Other languages
English (en)
Inventor
Milos Urbanija
Zan URBANIJA
Amor HAQUE
Dalibor Igrec
Gregor Breznik
Original Assignee
Direct4Me, Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Direct4Me, Inc. filed Critical Direct4Me, Inc.
Publication of WO2022046839A1 publication Critical patent/WO2022046839A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/08—Logistics, e.g. warehousing, loading or distribution; Inventory or stock management
    • G06Q10/083—Shipping
    • G06Q10/0836—Recipient pick-ups
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
    • G06Q10/063—Operations research, analysis or management
    • G06Q10/0635—Risk analysis of enterprise or organisation activities

Definitions

  • 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.
  • 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.
  • 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.
  • Figure 1 depicts a provider box for dynamic planning of last mile delivery in accordance with at least one embodiment
  • Figure 2 is a flow diagram illustrating a method for dynamic planning of last mile delivery in accordance with at least one embodiment
  • Figure 3 is a block diagram illustrating a system for dynamic planning of last mile delivery in accordance with at least one embodiment.
  • the following disclosure enables, inter alia, dynamic planning of the suitability of product sale and last mile delivery considering apportionment of risk.
  • 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.
  • Infrastructure quality poor transport infrastructure, inefficient routes, inefficient transport technology, and the like prolong travel time, increase costs, and cause delays.
  • Temperature control which keeps cold products cold, hot products hot, perishable items fresh, and flammable items safe.
  • Figure 1 illustrates an embodiment of dynamic planning for last mile delivery in accordance with at least one embodiment.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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
  • a merchant may choose an unreliable payment provider to accept payments.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the user has very low credit, and the merchant refuses to transact with the user.
  • 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.
  • the payment risk apportionment may work in reverse for a provider with a low appetite for risk.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the logistics service provider may be apportioned all misdelivery risk by the firmware 110.
  • 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.
  • the risk may include vendor risk of the user, and each mode may be associated with a different logistics service provider.
  • 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.
  • 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.
  • 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.
  • 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.
  • the risk may include identity risk of the user, and all identity risk may be apportioned to the provider.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • risk is apportioned between transaction parties.
  • 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.
  • a set of requirements is required to be fulfilled to disengage the lock based on the apportionment.
  • the provider box firmware may operate in multiple modes representing various sets of requirements.
  • 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.
  • 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.
  • any transaction party may reapportion any type of risk during any applicable stage of the transaction.
  • a different set of requirements is required to be fulfilled to disengage the lock based on the reapportionment.
  • 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.
  • 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).
  • 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.
  • 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.
  • 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.
  • the firmware 350 apportions risk between transaction parties for each transaction for each box.
  • 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.
  • misdelivery risk of the logistics service provider may be apportioned to the provider.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the standard enables classic binary connection to a specially adapted communication protocol.
  • 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.
  • 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.
  • 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.
  • weather information from different weather providers 346 that allow access through their web services.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the fraud detection module 358 enables the provider to operate differently depending on the status of the user and the status of the merchant.
  • 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.
  • 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.
  • the logistics management module 359 enables complete manipulation and administration of logistics service provider information.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the system administration module 364 enables complete manipulation and administration of the system 300.
  • the electronic store module 365 enables settings and preferences of various electronic stores to be stored on the firmware 350.
  • 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.
  • the database module 366 enables storage and efficient retrieval of data stored on the firmware 350.
  • the electronic store user interface module 367 enables an interface for provider on the electronic stores of merchants.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the box may collect data at a specified time period, e.g., each time the box is opened, or continuously.
  • 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.
  • active box units may be a data source for passive or non-communicative box units.
  • 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.
  • apparatuses, systems, and methods for dynamic planning of last mile delivery are provided according to one or more of the following examples.
  • 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.
  • 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.
  • 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.
  • 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.

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Human Resources & Organizations (AREA)
  • Economics (AREA)
  • Strategic Management (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Quality & Reliability (AREA)
  • Operations Research (AREA)
  • Marketing (AREA)
  • Development Economics (AREA)
  • Tourism & Hospitality (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Educational Administration (AREA)
  • Game Theory and Decision Science (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

Dans la présente invention, une boîte de fournisseur (100) comprend un boîtier (102), un compartiment de stockage (104) à l'intérieur du boîtier, une porte (106) permettant l'accès au compartiment de stockage, un verrou (108) désactivant l'accès au compartiment de stockage par l'intermédiaire de la porte lorsqu'il est mis en prise, et un micrologiciel (110) couplé au verrou permettant sa désolidarisation. Le micrologiciel est activé pour commuter le fonctionnement entre de multiples modes, chaque mode répartissant le risque entre les parties de transaction de façon différente et chaque mode comprenant un ensemble différent d'exigences à remplir pour libérer le verrou sur la base de la répartition. Les parties de transaction comprennent le fournisseur et au moins deux des éléments suivants : un utilisateur, un commerçant, un fournisseur de services logistiques, un fournisseur de services d'assurance et un fournisseur de services de paiement.
PCT/US2021/047449 2020-08-26 2021-08-25 Planification dynamique de distribution du dernier kilomètre WO2022046839A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US202063070414P 2020-08-26 2020-08-26
US63/070,414 2020-08-26

Publications (1)

Publication Number Publication Date
WO2022046839A1 true WO2022046839A1 (fr) 2022-03-03

Family

ID=80354037

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2021/047449 WO2022046839A1 (fr) 2020-08-26 2021-08-25 Planification dynamique de distribution du dernier kilomètre

Country Status (1)

Country Link
WO (1) WO2022046839A1 (fr)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20010050615A1 (en) * 1999-09-16 2001-12-13 David Kucharczyk Locking mechanism for use with non-permanent access code
US20020120475A1 (en) * 2000-09-28 2002-08-29 Nihon Dot. Com, Co., Ltd. System and method for arranging shipment and insurance for an item
US20040010706A1 (en) * 2000-08-28 2004-01-15 Stevens John K High security wireless key for asynchronous delivery drop boxes
US20130166060A1 (en) * 2011-12-05 2013-06-27 United States Postal Service System and method of coordinating electronic parcel locker availability
US20150120602A1 (en) * 2012-05-18 2015-04-30 Demand Solutions Consulting Pty Ltd System and method for object delivery and pickup

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20010050615A1 (en) * 1999-09-16 2001-12-13 David Kucharczyk Locking mechanism for use with non-permanent access code
US20040010706A1 (en) * 2000-08-28 2004-01-15 Stevens John K High security wireless key for asynchronous delivery drop boxes
US20020120475A1 (en) * 2000-09-28 2002-08-29 Nihon Dot. Com, Co., Ltd. System and method for arranging shipment and insurance for an item
US20130166060A1 (en) * 2011-12-05 2013-06-27 United States Postal Service System and method of coordinating electronic parcel locker availability
US20150120602A1 (en) * 2012-05-18 2015-04-30 Demand Solutions Consulting Pty Ltd System and method for object delivery and pickup

Similar Documents

Publication Publication Date Title
US8768838B1 (en) Financial transactions using a rule-module nexus and a user account registry
US8639629B1 (en) System and method for accessing an online user account registry via a thin-client unique user code
US20190228461A1 (en) Omnichannel Commerce Platform with Integrated Mobile Shopping Platform, Online Shopping Platform, Commerce Data and Blockchain Layer
US7360691B2 (en) Secure device and mobile terminal which carry out data exchange between card applications
US20160140565A1 (en) Refreshing a behavioral profile stored on a mobile device
US7882028B1 (en) Systems and methods for credit card fee calculation
US20220383325A1 (en) System and Method for Web-Based Payments
US20180053189A1 (en) Systems and methods for enhanced authorization response
US20030037009A1 (en) Monitoring and managing delivery of shipped items
CN103765861A (zh) 移动设备的支付选择和授权
US20110039585A1 (en) Systems and methods for processing purchase transactions between mobile phones
CN102216943A (zh) 用于在延迟结算金融账户之间实施实时金融交易的系统和方法
US11501268B2 (en) Real-time transaction and receipt processing systems
US20230134095A1 (en) Systems, devices and methods for tracking authenticated clean energy with blockchains
CN113067879A (zh) 基于多业务服务方的业务服务方法和装置及金融系统
US20240062290A1 (en) Computer-controlled marketplace network for digital transactions
US20090112759A1 (en) Accumulated transactions
KR20210109783A (ko) 부품 공급 관리 시스템
US20220230155A1 (en) Artificial intelligence (ai) architecture with smart, automated triggers of incoming and outgoing actions and usage
KR102575927B1 (ko) 블록체인 및 머신러닝을 이용한 프랜차이즈 유통 및 관리 시스템
US20220230236A1 (en) Artificial intelligence (ai) architecture with smart, automated triggers of incoming and outgoing actions and usage
US20230325817A1 (en) Application and mobile point of sale system enabling real time conversion and interoperability between cryptocurrency and fiat for point of sale transactions
US20230186260A1 (en) Artificial intelligence (ai) architecture with smart, automated triggers of incoming and outgoing actions and usage
WO2022046839A1 (fr) Planification dynamique de distribution du dernier kilomètre
KR20150001579A (ko) 물류 중개 시스템 및 방법

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 21862617

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 21862617

Country of ref document: EP

Kind code of ref document: A1

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 112(1) EPC (EPO FORM 1205 DATED 14.09.2023)