Computer-implemented method and computer-implemented system for automated communication with fulfillment centers

Abstract

A computerized system for delivery scheduling. The system may include a processor and a non-transitory storage medium including instructions. The instructions, when executed by the at least one processor, cause the at least one processor to perform steps. The steps may include: receiving an electronic request for ordering goods (from a remote system); determining information associated with the remote system and a fulfillment center associated with the information and the goods; generating an electronic message; and forwarding the electronic message and instructions (to the fulfillment center) to generate a graphical user interface displaying the request for goods and delivery wave estimates.

Description

[Technical Field]

[0001] This disclosure generally relates to computerized systems and methods for computerized delivery scheduling. Specifically, embodiments of this disclosure relate to innovative and unconventional systems for classifying deliveries, adjusting delivery groups, and transmitting instructions to client devices via a graphical user interface (GUI) for adaptive delivery scheduling. [Previous Technology]

[0002] The practice of online ordering involves an intricate network of electronic systems. Especially today, with customers demanding next-day delivery, automatic returns, and minimal shipping costs, the practice of online ordering requires the use of a complex network of electronic systems supporting order preparation and delivery. Multiple electronic systems within the network need to communicate with each other in real time to determine the process, including, for example, shipping routes and / or distribution centers.

[0003] Standard electronic systems for managing and allocating operations are unable to handle the increasing volume of goods and specialized demands. Standard systems are not well-suited to the new requirements of handling expanded item hierarchies, processing smaller orders, and higher order frequencies. For example, current electronic systems typically operate by batching orders that are en route to a location. A retailer's electronic system can collect orders over a period of time, group them, and then provide batching instructions to the shipping electronic system. However, these batching operations may not achieve the accelerated delivery times required for some orders.

[0004] Furthermore, because online order fulfillment typically involves multiple parties, current electronic systems networks may have multiple components requiring frequent and real-time communication. Online retailers' electronic systems frequently communicate in real-time with multiple distribution and fulfillment systems and may employ several hubs or zones to enable rapid order fulfillment. However, this complexity of electronic systems networks makes them difficult to scale and hinders adjustments needed to meet new customer demands. For example, current electronic systems are not well-suited for handling large volumes of orders with different customer privileges because they cannot effectively allocate delivery channels based on premium users, urgent delivery, or lowest-cost delivery. Moreover, current systems are rigid and not easily adaptable to dynamic changes in demand or customer requirements. Standard electronic systems are rigid and built into operations that are difficult to adjust throughout the delivery process. These electronic systems may not be well-suited to adapting to new delivery chains, including, for example, temporary or on-demand workers and contractors. Therefore, these electronic systems cannot effectively handle delivery requests or adjust delivery processes to meet customer needs.

[0005] Furthermore, current electronic systems used for managing delivery have outdated communication platforms that cannot provide the dynamic instructions required by adaptive systems. Current electronic systems rely on outdated technologies, forcing users to use multiple platforms throughout the distribution chain.

[0006] Therefore, there is a need for improved methods and systems for adaptive delivery scheduling systems. The disclosed system and method for generating graphical user interfaces for adaptive delivery scheduling solves one or more of the above-mentioned problems and / or other problems in the prior art. [Summary of the Invention]

[0007] One aspect of this disclosure relates to a computerized system for delivery scheduling. The system may include: at least one processor; and at least one non-transitory storage medium, including instructions that, when executed by the at least one processor, cause the at least one processor to perform steps. The steps may include receiving (from a remote system) an electronic request for ordering goods and determining information associated with the remote system, the information determining a fulfillment center (FC) associated with the information and the goods. The steps may also include (based on the information associated with the remote system) generating an electronic message including the determined fulfillment center, the goods, the time of day, and a delivery wave estimate. The steps may also include (to the fulfillment center) forwarding the electronic message and instructions to generate a graphical user interface displaying the goods and the delivery wave estimate.

[0008] Another aspect of this disclosure relates to a non-transitory computer-readable medium for storing instructions that, when executed by a processor, perform operations for delivery scheduling. These operations may include receiving an electronic request for ordering goods (from a remote system) and determining information associated with the remote system, the information determining a fulfillment center associated with the information and the goods. The operations may also include generating an electronic message (based on the information associated with the remote system) including the determined fulfillment center, the goods, the time of day, and a delivery wave estimate. The operations may also include forwarding the electronic message and instructions (to the fulfillment center) to generate a graphical user interface displaying the goods and the delivery wave estimate.

[0009] Another aspect of this disclosure relates to a computer-implemented method for delivery scheduling. The method may include: (from a remote system) receiving an electronic request to order a first shipment and a second shipment; determining information associated with the remote system; determining a first fulfillment center associated with the information and the first shipment, and a second fulfillment center associated with the second shipment and the information. The operation may also include: generating a first delivery wave for the first shipment and a second delivery wave for the second shipment; (based on the information associated with the remote system) generating an electronic message including the first and second fulfillment centers, the first and second shipments, the time of day, and estimates of the first and second delivery waves. Furthermore, the operation may include: determining that the second delivery wave estimate differs from the first delivery wave; modifying at least one of the first or second delivery wave estimate to match the other delivery wave estimate. The operation may also include: forwarding the electronic message and instructions to the fulfillment center to generate a graphical user interface that displays a list in which the first cargo and the second cargo are color-coded using corresponding delivery wave estimates; and sending instructions to the fulfillment center to print shipping labels listing the first delivery wave estimate or the second delivery wave estimate.

[0010] Other systems, methods and computer-readable media are also discussed in this document.

Implementation Method

[0012] The following detailed description refers to the accompanying drawings. The same reference numerals are used as far as possible in the drawings and the following description to refer to the same or similar parts. Although several exemplary embodiments are set forth herein, various modifications, adjustments, and other implementations are possible. For example, the components and steps shown in the figures may be replaced, added, or modified, and the exemplary methods set forth herein may be modified by replacing, reordering, removing, or adding steps of the disclosed methods. Therefore, the following detailed description is not limited to the disclosed embodiments and examples. Rather, the proper scope of the invention is defined by the claims of the appended patent application.

[0013] Embodiments of this disclosure relate to systems and methods configured to generate graphical user interfaces for adaptive delivery scheduling. The disclosed systems and methods achieve automated and optimized order processing by, for example, identifying fulfillment centers in optimal locations to meet order requirements. The disclosed systems and methods also provide users of the system with graphical user interfaces and interactive tools to effectively manage couriers and prioritize tasks. For example, the disclosed systems and methods improve the technical field of automated delivery sorting by providing supply chain managers with greater visibility into forecasted orders to assess demand. In this embodiment, the disclosed systems and methods may employ machine learning techniques to identify trends and forecast fulfillment centers for dispatching.

[0014] Furthermore, the disclosed system and method improve scheduling systems by automatically adjusting delivery processes. The disclosed delivery system can operate using different delivery processes or paradigms. For example, the system can operate using a "waves process," a "shift process," or a combination thereof. A waves process schedules deliveries in waves at different times. For example, waves delivery may include a first package wave several times a day around a specific area (e.g., a route including sub-routes). In contrast, a shift process schedules deliveries to different areas, initially delivering to a portion (typically 50%) of a specific area, followed by deliveries to the remainder. The disclosed system and method can be configured to reconfigure routes and worker schedules based on optimization parameters for the delivery process. For example, the disclosed system and method can analyze previous orders and efficiency at fulfillment centers or camps to determine the forecasted demand for each camp or fulfillment center. The disclosed system then uses a machine learning forecasting model to evaluate which delivery process has the most efficient results and updates all components of the system accordingly. For example, if the system determines that delivering a set of orders using a two-shift process is more efficient, the disclosed system and method can update fulfillment centers, shipping authorizations, and workers to operate under a two-shift process. In this embodiment, forecast analysis for configuring the delivery process utilizes specific computerized methods to identify optimized delivery schedules, thereby improving the system used for delivery scheduling.

[0015] Furthermore, the disclosed system and method improve the flexibility of the delivery process by enabling dynamic changes to the delivery process. For example, if the system identifies throughout a shift that there are more available temporary workers than expected, the system can rerun the predictive model as needed to update the delivery process and reconfigure the system. The disclosed system also provides a graphical user interface for providing feedback, modifying groups, or changing the delivery process.

[0016] The disclosed system and method can also improve the field of automated delivery scheduling by transforming order information into a sequence of delivery instructions. For example, the disclosed system and method can automatically process order requests until a print label with delivery information is generated. The label may include information such as the required delivery time, destination, and priority information.

[0017] Furthermore, the disclosed system and method solve the technical problem of poor information display in mobile devices because the disclosed system can generate a user interface that effectively manages screen space. In particular, for portable devices used by couriers with limited screen space, the disclosed system and method can generate a dynamic GUI that specifically displays elements relevant to the courier while removing irrelevant elements. For example, the disclosed method may include dynamically modifying the GUI based on adaptive delivery patterns to display courier notifications, changes, delivery groups, or required priorities. The disclosed system and method also include GUI configurations that facilitate the establishment of delivery routes, the creation of groups, or the updating of the system.

[0018] Reference will now be made in detail to the disclosed embodiments, examples of which are illustrated in the accompanying drawings.

[0019] Figure 1A shows a schematic block diagram of system 100, illustrating an exemplary embodiment of a system including a computerized system for enabling communication in shipping, transportation, and logistics operations. As shown in Figure 1A, system 100 may include various systems, each of which may be interconnected via one or more networks. The systems may also be interconnected via direct connections (e.g., using cables). The illustrated systems include a Shipment Authorization Technology (SAT) system 101, an external front-end system 103, an internal front-end system 105, a transportation system 107, mobile devices 107A, 107B, and 107C, a seller's entry point 109, a shipment and order tracking (SOT) system 111, a fulfillment optimization (FO) system 113, a fulfillment messaging gateway (FMG) 115, a supply chain management (SCM) system 117, a workforce management system (WMS) 119, mobile devices 119A, 119B, and 119C (illustrated as being located within a fulfillment center (FC) 200), third-party fulfillment (3PL) systems 121A, 121B, and 121C, a fulfillment center authorization system (FC Auth) 123, and a labor management system (LMS) 125.

[0020] In some embodiments, the SAT system 101 may be implemented as a computer system that monitors order status and delivery status. For example, the SAT system 101 may determine whether an order has exceeded its promised delivery date (PDD) and may take appropriate actions, including initiating a new order, reshipping items from an undelivered order, canceling an undelivered order, and initiating contact with the ordering customer. The SAT system 101 may also monitor other data, including outputs (e.g., the number of packages shipped during a specific time period) and inputs (e.g., the number of empty cartons received for shipment). The SAT system 101 may also act as a gateway between different devices in the system 100, enabling communication between devices such as the external front-end system 103 and the FO system 113 (e.g., using store-and-forward or other technologies).

[0021] In some embodiments, the external front-end system 103 may be implemented as a computer system that enables external users to interact with one or more systems in system 100. For example, in embodiments where system 100 can present the system so that users can place orders for items, the external front-end system 103 may be implemented as a web server that receives search requests, presents item pages, and requests payment information. For example, the external front-end system 103 may be implemented as one or more computers running software such as Apache Hypertext Transfer Protocol (HTTP) servers, Microsoft Internet Information Services (IIS), NGINX, etc. In other embodiments, the external front-end system 103 may run custom web server software designed to receive and process requests from external devices (e.g., mobile device 102A or computer 102B), retrieve information from databases and other data storage based on these requests, and provide a response to the received requests based on the retrieved information.

[0022] In some embodiments, the external front-end system 103 may include one or more of a web caching system, a database, a search system, or a payment system. In one embodiment, the external front-end system 103 may include one or more of these systems, while in another embodiment, the external front-end system 103 may include an interface (e.g., server-to-server, database-to-database, or other network connection) connected to one or more of these systems.

[0023] A set of illustrative steps shown in Figures 1B, 1C, 1D, and 1E will help illustrate some operations of the external front-end system 103. The external front-end system 103 may receive information from systems or devices within system 100 for presentation and / or display. For example, the external front-end system 103 may host or provide one or more web pages, including a Search Results Page (SRP) (e.g., Figure 1B), a Single Display Page (SDP) (e.g., Figure 1C), a shopping cart page (e.g., Figure 1D), or an order page (e.g., Figure 1E). A user device (e.g., using mobile device 102A or computer 102B) may navigate to the external front-end system 103 and request a search by entering information in a search box. The external front-end system 103 may request information from one or more systems within system 100. For example, the external front-end system 103 may request information from system 113 to satisfy a search request. External front-end system 103 may also request and receive (from FO system 113) the promised delivery date, or "PDD," for each item included in the search results. In some embodiments, PDD may represent an estimate of when the package containing the goods will arrive at the user's desired location, or the date on which the goods are promised delivery to the user's desired location if ordered within a specific time period (e.g., before the end of the day (11:59 PM)). (PDD is further discussed below with reference to FO system 113.)

[0024] The external front-end system 103 may prepare an SRP based on the information (e.g., Figure 1B). The SRP may include information that satisfies the search request. For example, this may include images of goods that satisfy the search request. The SRP may also include the corresponding price for each item, or information related to enhanced delivery options, PDD, weight, size, offers, discounts, etc., for each item. The external front-end system 103 may send the SRP to the user device that issued the request (e.g., via a network).

[0025] The user device can then select goods from the SRP by clicking or tapping the user interface (or using another input device). The user device can make a request for information about the selected goods and send it to the external front-end system 103. In response, the external front-end system 103 can request information related to the selected goods. For example, the information may also include additional information besides the information presented for the goods on the corresponding SRP. This additional information may include, for example, shelf life, country of origin, weight, dimensions, number of items in the package, handling instructions, or other information about the goods. The information may also include recommendations for similar goods (e.g., based on massive data and / or machine learning analysis of customers who have purchased this goods and at least one other goods), answers to frequently asked questions, customer reviews, manufacturer information, images, etc.

[0026] The external front-end system 103 can prepare a Single Display Page (SDP) (e.g., Figure 1C) based on the received goods information. The SDP may also include other interactive elements such as a "Buy Now" button, an "Add to Cart" button, quantity bars, item images, etc. The SDP may further include a list of sellers offering the goods. The list may be sorted based on the price offered by each seller, so that the seller offering the lowest price is listed at the top. The list may also be sorted based on seller ranking, so that the highest-ranked seller is listed at the top. Seller ranking may be based on various factors, including, for example, the seller's past tracking record of fulfilling the promised PDD. The external front-end system 103 can deliver the SDP to the requesting user device (e.g., via the network).

[0027] The user device that issued the request can receive an SDP listing product information. After receiving the SDP, the user device can then interact with it. For example, the user of the user device that issued the request can click the "Add to Cart" button on the SDP or otherwise interact with the "Add to Cart" button on the SDP. This will add the product to the shopping cart associated with the user. The user device can then transmit this request to add the product to the shopping cart to the external front-end system 103.

[0028] The external front-end system 103 may generate a shopping cart page (e.g., FIG. 1D). In some embodiments, the shopping cart page lists items that have been added to a virtual "shopping cart" by the user. The user device may request the shopping cart page by clicking an icon on an SRP, SDP, or other page, or by otherwise interacting with an icon on an SRP, SDP, or other page. In some embodiments, the shopping cart page may list all items that have been added to the shopping cart by the user, as well as information about the items in the shopping cart, such as the quantity of each item, the unit price of each item, the price of each item based on the associated quantity, information about PDD, delivery method, shipping cost, user interface elements for modifying items in the shopping cart (e.g., deleting or modifying the quantity), options for ordering other items or setting up regular delivery of items, options for setting up interest payments, user interface elements for continuing to purchase, etc. The user on the user device may click a user interface element (e.g., a button read as "Buy Now") or otherwise interact with a user interface element (e.g., a button read as "Buy Now") to initiate a purchase of items in the shopping cart. In doing so, the user device can transmit this purchase request to the external front-end system 103.

[0029] The external front-end system 103 may generate an order page (e.g., FIG. 1E) in response to receiving a request to initiate a purchase. In some embodiments, the order page relists the items from the shopping cart and requests input of payment and shipping information. For example, the order page may include portions of user interface elements requesting information about the purchaser of the items in the shopping cart (e.g., name, address, email address, phone number), information about the recipient (e.g., name, address, phone number, delivery information), shipping information (e.g., delivery and / or collection speed / method), payment information (e.g., credit card, bank transfer, cheque, stored credit), and requesting a cash receipt (e.g., for tax purposes). The external front-end system 103 may send the order page to the user device.

[0030] The user device can enter information on the order page and click on the user interface element that sends the information to the external front-end system 103, or otherwise interact with the user interface element that sends the information to the external front-end system 103. The external front-end system 103 can send information from the user interface element to different systems in system 100, so that new orders can be created and processed with the items in the shopping cart.

[0031] In some embodiments, the external front-end system 103 may be further configured to enable the seller to transmit and receive information related to the order.

[0032] In some embodiments, the internal front-end system 105 may be implemented as a computer system that enables internal users (e.g., employees of an organization that owns, operates, or leases system 100) to interact with one or more systems in system 100. For example, in an embodiment where SAT system 101 can present the system so that users can place orders for items, the internal front-end system 105 may be implemented as a web server that enables internal users to view diagnostic and statistical information about orders, modify item information, or check statistics related to orders. For example, the internal front-end system 105 may be implemented as one or more computers running software such as Apache HTTP Server, Microsoft Internet Information Services (IIS), NGINX, etc. In other embodiments, the internal front-end system 105 may run custom web server software designed to receive and process requests from systems or devices (and other devices not shown) illustrated in system 100, retrieve information from databases and other data storage based on such requests, and provide responses to the received requests based on the retrieved information.

[0033] In some embodiments, the internal front-end system 105 may include one or more of a website caching system, a database, a search system, a payment system, an analytics system, an order monitoring system, etc. In one embodiment, the internal front-end system 105 may include one or more of these systems, while in another embodiment, the internal front-end system 105 may include an interface (e.g., server-to-server, database-to-database, or other network connection) connected to one or more of these systems.

[0034] In some embodiments, the transport system 107 may be implemented as a computer system enabling communication between systems or devices in system 100 and mobile devices 107A to 107C. In some embodiments, the transport system 107 may receive information from one or more mobile devices 107A to 107C (e.g., mobile phones, smartphones, personal digital assistants (PDAs), etc.). For example, in some embodiments, mobile devices 107A to 107C may include devices operated by delivery workers. Delivery workers (who may be permanent, temporary, or shift workers) may use mobile devices 107A to 107C to deliver packages containing goods ordered by users. For example, for delivering packages, delivery workers may receive notifications on their mobile devices instructing which package to deliver and where to deliver it. Upon arrival at the delivery location, the delivery worker can use a mobile device to locate the package (e.g., in the back of a truck or in a crate), scan or otherwise capture information associated with identifiers on the package (e.g., barcodes, images, text strings, radio frequency identification (RFID) tags, etc.) and deliver the package (e.g., by leaving the package at the front door, leaving it with a security guard, handing it over to the recipient, etc.). In some embodiments, the delivery worker can use the mobile device to capture a photograph of the package and / or obtain a signature using the mobile device. The mobile device can send information to the transportation system 107, including information about the delivery, such as time, date, Global Positioning System (GPS) location, photograph, identifiers associated with the delivery worker, identifiers associated with the mobile device, etc. The transportation system 107 can store this information in a database (not shown) for access by other systems in system 100. In some embodiments, the transportation system 107 can use this information to prepare tracking data and send the tracking data to other systems indicating the location of a specific package.

[0035] In some embodiments, some users may use one type of mobile device (e.g., permanent workers may use a dedicated PDA with custom hardware such as a barcode scanner, stylus, and other devices), while other users may use other types of mobile devices (e.g., temporary workers or shift workers may use readily available mobile phones and / or smartphones).

[0036] In some embodiments, the transportation system 107 may associate a user with each device. For example, the transportation system 107 may store associations between users (represented by, for example, user identifiers, employee identifiers, or telephone numbers) and mobile devices (represented by, for example, International Mobile Equipment Identity (IMEI), International Mobile Subscription Identifier (IMSI), telephone number, Universal Unique Identifier (UUID), or Globally Unique Identifier (GUID)). The transportation system 107 may use such associations, in conjunction with data received during delivery, to analyze data stored in a database to determine, among other things, the worker's location, worker efficiency, or worker speed.

[0037] In some embodiments, seller entry 109 may be implemented as a computer system that enables a seller or other external entity to communicate electronically with one or more systems in system 100. For example, a seller may use a computer system (not shown) to upload or provide product information, order information, contact information, etc., for goods that the seller wishes to sell through system 100 using seller entry 109.

[0038] In some embodiments, the shipping and order tracking system 111 may be implemented as a computer system that receives, stores, and transmits information about the location of packages containing goods ordered by customers (e.g., users of devices 102A to 102B). In some embodiments, the shipping and order tracking system 111 may request or store information from a website server (not shown) operated by a shipping company that delivers packages containing goods ordered by customers.

[0039] In some embodiments, the shipping and order tracking system 111 may request and store information from the systems depicted in system 100. For example, the shipping and order tracking system 111 may request information from transportation system 107. As discussed above, transportation system 107 may receive information from one or more mobile devices 107A to 107C (e.g., mobile phones, smartphones, PDAs, etc.) associated with one or more users (e.g., delivery workers) or vehicles (e.g., delivery trucks). In some embodiments, the shipping and order tracking system 111 may also request information from workforce management system (WMS) 119 to determine the location of individual goods within a fulfillment center (e.g., fulfillment center 200). The shipping and order tracking system 111 may request data from one or more of the transportation system 107 or WMS 119, process it, and present it to devices (e.g., user devices 102A and 102B) upon request.

[0040] In some embodiments, the Practice Optimization (FO) system 113 may be implemented as a computer system that stores information about customer orders from other systems (e.g., external front-end system 103 and / or shipping and order tracking system 111). The FO system 113 may also store information describing where specific items are accommodated or stored. For example, some items may be stored in only one fulfillment center, while others may be stored in multiple fulfillment centers. In still other embodiments, some fulfillment centers may be designed to store only a specific set of items (e.g., fresh produce or frozen product). The FO system 113 stores this information along with associated information (e.g., quantity, size, receipt date, expiration date, etc.).

[0041] The FO system 113 may also calculate a corresponding Promised Delivery Date (PDD) for each type of goods. In some embodiments, the PDD may be based on one or more factors. For example, the FO system 113 may calculate the PDD for goods based on: past demand for the goods (e.g., how many times the goods have been ordered over a period of time), expected demand for the goods (e.g., how many customers are expected to order the goods in the upcoming period of time), past network demand indicating how many goods have been ordered over a period of time, expected network demand indicating how many goods are expected to be ordered in the upcoming period of time, one or more counts of goods stored in each fulfillment center 200, which fulfillment center stores each type of goods, expected orders or current orders for the goods, etc.

[0042] In some embodiments, the FO system 113 may periodically (e.g., hourly) determine the PDD for each type of goods and store it in a database for retrieval or transmission to other systems (e.g., external front-end system 103, SAT system 101, shipping and order tracking system 111). In other embodiments, the FO system 113 may receive electronic requests from one or more systems (e.g., external front-end system 103, SAT system 101, shipping and order tracking system 111) and calculate the PDD on demand.

[0043] In some embodiments, the practice message gateway (FMG) 115 may be implemented as a computer system that receives requests or responses in one format or protocol from one or more systems in system 100 (e.g., FO system 113), converts them into another format or protocol, and forwards them in the converted format or protocol to other systems such as WMS 119 or third-party practice systems 121A, 121B or 121C, and vice versa.

[0044] In some embodiments, the supply chain management (SCM) system 117 may be implemented as a computer system performing forecasting functions. For example, the SCM system 117 may forecast the demand level for a particular good based on, for example, past demand for goods, expected demand for goods, past demand across the entire network, expected demand across the entire network, the count of goods stored in each fulfillment center 200, expected orders or current orders for each type of good, etc. In response to such forecasted levels and the quantity of each type of good in all fulfillment centers, the SCM system 117 may generate one or more purchase orders to procure and store sufficient quantities to meet the forecasted demand for a particular good.

[0045] In some embodiments, the Workforce Management System (WMS) 119 may be implemented as a computer system for monitoring workflows. For example, the WMS 119 may receive event data from individual devices (e.g., devices 107A to 107C or 119A to 119C) that indicate discrete events. For example, the WMS 119 may receive event data indicating that one of these devices should be used to scan a package. As discussed below with reference to fulfillment center 200 and FIG2, during the process, package identifiers (e.g., barcode or RFID tag data) may be scanned or read at specific stages by machines (e.g., automated barcode scanners or handheld barcode scanners, RFID readers, high-speed cameras, devices such as tablet 119A, mobile device / PDA 119B, computer 119C, etc., or similar devices). WMS 119 can store each event of scanning or reading the indication of the package identifier, along with the package identifier, time, date, location, user identifier, or other information, in a corresponding database (not shown), and can provide this information to other systems (e.g., shipping and order tracking system 111).

[0046] In some embodiments, WMS 119 may store information that associates one or more devices (e.g., devices 107A to 107C or 119A to 119C) with one or more users associated with system 100. For example, in some cases, the association between a user (e.g., a part-time or full-time employee) and a mobile device may be that the user owns the mobile device (e.g., the mobile device is a smartphone). In other cases, the association between a user and a mobile device may be that the user temporarily holds the mobile device (e.g., the user registers to lend out the mobile device at the beginning of the day, will use the mobile device during the day, and will return the mobile device at the end of the day).

[0047] In some embodiments, WMS 119 may maintain a work log for each user associated with system 100. For example, WMS 119 may store information associated with each employee, including any assigned processes (e.g., unloading trucks, picking items in self-pickup areas, rebin wall work, packing items), user identifier, location (e.g., floor or area in fulfillment center 200), number of units the employee moves through in the system (e.g., number of items picked, number of items packed), identifier associated with devices (e.g., devices 119A to 119C), etc. In some embodiments, WMS 119 may receive check-in and check-out information from a timing system, such as a timing system operating on devices 119A to 119C.

[0048] In some embodiments, third-party practice (3PL) systems 121A to 121C represent computer systems associated with a third-party provider of logistics and goods. For example, while some goods are stored in fulfillment center 200 (as discussed below with reference to FIG2), others may be stored off-site, produced on demand, or otherwise not stored in fulfillment center 200. 3PL systems 121A to 121C may be configured to receive orders from FO system 113 (e.g., via FMG 115) and may provide goods and / or services (e.g., delivery or installation) directly to customers. In some embodiments, one or more of 3PL systems 121A to 121C may be part of system 100, while in other embodiments, one or more of 3PL systems 121A to 121C may be outside of system 100 (e.g., owned or operated by a third-party provider).

[0049] In some embodiments, the Fulfillment Center Authorization System (FC Auth) 123 may be implemented as a computer system with various functionalities. For example, in some embodiments, FC Auth 123 may act as a single-sign-on (SSO) service for one or more other systems within System 100. For example, FC Auth 123 may enable a user to log in via the internal front-end system 105, determine that the user has similar privileges to access resources at the shipping and order tracking system 111, and enable the user to access those privileges without requiring a second login process. In other embodiments, FC Auth 123 may enable a user (e.g., an employee) to associate themselves with a specific task. For example, some employees may not have electronic devices (e.g., devices 119A to 119C) but may instead move between tasks and zones within Fulfillment Center 200 during the day. FC Auth 123 may be configured to enable these employees to indicate what tasks they are performing and which zones they are in at different times of the day.

[0050] In some embodiments, the Labor Relations Management System (LMS) 125 may be implemented as a computer system that stores attendance and overtime information of employees (including full-time and part-time employees). For example, the LMS 125 may receive information from FC Auth 123, WMS 119, devices 119A to 119C, transportation system 107 and / or devices 107A to 107C.

[0051] The specific configuration illustrated in Figure 1A is merely an example. For instance, although Figure 1A illustrates FC Auth system 123 connected to FO system 113, not all embodiments require this specific configuration. In fact, in some embodiments, the systems in system 100 may be interconnected via one or more public or private networks, including: the Internet, an Intranet, a Wide-Area Network (WAN), a Metropolitan-Area Network (MAN), a wireless network conforming to the Institute of Electrical and Electronic Engineers (IEEE) 802.11a / b / g / n standards, leased lines, etc. In some embodiments, one or more of the systems in system 100 may be implemented as one or more virtual servers implemented in a data center, server farm, etc.

[0052] Figure 2 illustrates a fulfillment center 200. A fulfillment center 200 is an example of a physical location where items ordered and shipped to a customer are stored. A fulfillment center (FC) 200 may be divided into multiple zones, each of which is illustrated in Figure 2. In some embodiments, these "zones" may be considered as virtual divisions between different stages of the processes of receiving items, storing items, retrieving items, and shipping items. Therefore, although "zones" are illustrated in Figure 2, other divisions of zones may exist, and in some embodiments, the zones in Figure 2 may be omitted, copied, or modified.

[0053] The receiving area 203 represents the area in which a seller of FC 200 who wishes to sell goods from system 100 of Figure 1A receives items. For example, the seller may use truck 201 to deliver items 202A and 202B. Item 202A may represent a single item that is large enough to occupy its own shipping pallet, while item 202B may represent a group of items stacked together on the same pallet to save space.

[0054] Workers will receive items in the receiving area 203 and may optionally check for damage and correctness of the items using a computer system (not shown). For example, workers may use the computer system to compare the quantities of items 202A and 202B with the ordered quantities. If the quantities do not match, the worker may reject one or more of items 202A or 202B. If the quantities match, the worker may move these items (using, for example, a trolley, handcart, forklift, or manually) to a buffer zone 205. Buffer zone 205 may serve as a temporary storage area for items not currently needed in the picking area (e.g., due to a sufficient quantity of these items in the picking area to meet anticipated demand). In some embodiments, forklift 206 is operated to move items around in buffer zone 205 and between receiving area 203 and unloading area 207. If item 202A or 202B is needed in the picking area (e.g., due to anticipated demand), the forklift can move item 202A or 202B to the unloading area 207.

[0055] Unloading area 207 may be an area of ​​FC 200 where items are stored before being moved to picking area 209. A worker assigned a picking task ("picker") may approach items 202A and 202B in the picking area, scan the barcodes of the picking area using a mobile device (e.g., device 119B), and scan the barcodes associated with items 202A and 202B. The picker may then take the items to picking area 209 (e.g., by placing the items on a cart or transporting the items).

[0056] Picking area 209 may be an area of ​​FC 200 where items 208 are stored on storage unit 210. In some embodiments, storage unit 210 may include one or more of physical shelving, bookshelves, boxes, shipping containers, refrigerators, freezers, cold storage, etc. In some embodiments, picking area 209 may be organized into multiple floors. In some embodiments, workers or machines may move items to picking area 209 by various means, including forklifts, elevators, conveyors, trolleys, handcarts, automated robots or devices, or manual methods. For example, a picker may place items 202A and 202B on a handcart or trolley in unloading area 207 and walk to picking area 209.

[0057] The picker may receive an instruction to place (or "stow") an item in a specific location (e.g., a specific space on storage unit 210) within the picking area 209. For example, the picker may use a mobile device (e.g., device 119B) to scan item 202A. The device may, for example, use a system indicating aisles, shelves, and locations to instruct the picker where item 202A should be stored. Then, before storing item 202A in this location, the device may prompt the picker to scan the barcode at this location. The device may send (e.g., via a wireless network) data to a computer system (e.g., WMS 119 in Figure 1A) to indicate that item 202A has been stored at the location by the user using device 119B.

[0058] Once a user places an order, the picker can receive instructions on device 119B to retrieve one or more items 208 from storage unit 210. The picker can retrieve item 208, scan the barcode on item 208, and place it on transport mechanism 214. Although transport mechanism 214 is represented as a slider, in some embodiments, transport mechanism may be implemented as one or more of a conveyor belt, elevator, pallet truck, forklift, handcart, trolley, etc. Item 208 can then reach packaging area 211.

[0059] Packaging area 211 is an area for receiving items from the self-picking area 209 of FC 200 and packing the items into boxes or bags for final shipment to the customer. In packaging area 211, workers assigned to receive items ("rebin workers") will receive items 208 from self-picking area 209 and determine which order item 208 corresponds to. For example, the rebin worker can use a device such as computer 119C to scan the barcode on item 208. Computer 119C can visually indicate which order item 208 is associated with. For example, this may include spaces or "cells" on wall 216 corresponding to orders. Once an order is completed (e.g., since the cell contains all the items in the order), the rebin worker can indicate to the packer (or "packer") that the order is complete. The packer can retrieve the items from the cell and place them into boxes or bags for shipment. Next, the packer may send the boxes or bags to hub zone 213, for example by forklift, pallet truck, trolley, handcart, conveyor belt, manual or other means.

[0060] Central area 213 may be the area where the self-packaging area 211 of FC 200 receives all boxes or bags ("packages"). Workers and / or machines in central area 213 may pick up packages 218 and determine which part of the delivery area each package is intended to go to, and route the package to the appropriate camp area 215. For example, if the delivery area has two smaller sub-areas, the package will go to one of the two camp areas 215. In some embodiments, workers or machines may scan the package (e.g., using one of devices 119A to 119C) to determine its final destination. Routing the package to camp area 215 may include, for example, determining a part of the geographic area that is the destination of the package (e.g., based on a postal code), and determining the camp area 215 associated with said part of said geographic area.

[0061] In some embodiments, camp area 215 may include one or more buildings, one or more physical spaces, or one or more areas, wherein packages are received from central area 213 for sorting into routes and / or subroutines. In some embodiments, camp area 215 is physically separate from FC 200, while in other embodiments, camp area 215 may form part of FC 200.

[0062] Workers and / or machines in camp area 215 may determine which route and / or sub-route a package 220 should be associated with, for example, based on a comparison of the destination with existing routes and / or sub-routes, a calculation of the workload for each route and / or sub-route, the time of day, the shipping method, the cost of shipping package 220, the PDD associated with the items in package 220, etc. In some embodiments, workers or machines may scan the package (e.g., using one of devices 119A to 119C) to determine its final destination. Once package 220 is assigned to a specific route and / or sub-route, workers and / or machines may move the package 220 to be shipped. In exemplary Figure 2, camp area 215 includes truck 222, vehicle 226, and delivery workers 224A and 224B. In some embodiments, truck 222 may be driven by delivery worker 224A, who is a full-time employee delivering packages for FC 200, and truck 222 is owned, leased, or operated by the same company that owns, leases, or operates FC 200. In some embodiments, vehicle 226 may be driven by delivery worker 224B, who is a "flexible" or occasional worker who makes deliveries on demand (e.g., seasonally). Vehicle 226 may be owned, leased, or operated by delivery worker 224B.

[0063] FIG3 is a block diagram of an exemplary system 300 conforming to the disclosed embodiments. In system 300, a scheduling system (e.g., 320) can process data streams in real time to, for example, allocate deliveries, generate delivery routes, and communicate with workers. System 300 may include one or more scheduling systems 320, online resources 340, client devices 350, third-party systems 360, client systems 390, and databases 380. In some embodiments, as shown in FIG3, components of system 300 may be connected to network 370. However, in other embodiments, components of system 300 may be directly connected to each other without requiring network 370. For example, database 380 may be directly coupled to scheduling system 320.

[0064] In some embodiments, the scheduling system 320 may be implemented using one or more of the components of system 100 (FIG. 1A). For example, the scheduling system 320 may include front-end system 105, FO system 113, SCM system 117, and WMS 119 (FIG. 1A). In other embodiments, the scheduling system 320 may be implemented using one or more independent servers configured to perform operations for delivering schedules.

[0065] Online resource 340 may include one or more servers or one or more storage services provided by an entity (e.g., a provider of website hosting, network connectivity, cloud, or backup services). In some embodiments, online resource 340 may be associated with a hosting service or server that stores web pages used for authentication services, Domain Name System (DNS), or login pages. In other embodiments, online resource 340 may be associated with a cloud computing service. In still other embodiments, online resource 340 may be associated with a messaging service (e.g., Apple Push Notification Service, Azure Mobile Services, or Google Messaging). In such embodiments, online resource 340 may handle the delivery of messages and notifications related to the functionality of the disclosed embodiments, such as handling digital rights management.

[0066] Client device 350 may include one or more computing devices configured to perform one or more operations consistent with the disclosed embodiments. For example, client device 350 may include a desktop computer, laptop computer, server, mobile device (e.g., tablet computer, smartphone, etc.), set-top box, gaming device, wearable computing device, or other type of computing device. In some embodiments, client device 350 may be part of system 100 (FIG. 1A). However, in other embodiments, client device 350 may be independent of system 100. Client device 350 may include one or more processors configured to execute software instructions stored in memory (e.g., memory included in client device 350) to perform operations that implement the functions described below. Client device 350 may be configured for wired and / or wireless communication and may include software that, when executed by a processor, performs communication related to the Internet (e.g., Transmission Control Protocol (TCP) / Internet Protocol (IP)) and content display processes. For example, client device 350 may execute browser software that generates and displays an interface including content on a display device included in or connected to client device 350. Client device 350 may execute an application that enables client device 350 to communicate with components via network 370 and displays content in the interface via a display device included in client device 350.

[0067] In some embodiments, as further disclosed in conjunction with FIG4, the client device 350 may run an application specifically configured to interact with the scheduling system 320. Furthermore, the client device 350 may store one or more accounts. For example, the client device 350 may store information about worker accounts, including worker identification, password, location, and / or delivery preferences.

[0068] The disclosed embodiments are not limited to any particular configuration of the client device 350. For example, the client device 350 may be a mobile device that stores and executes mobile applications to perform operations providing functions supplied by the scheduling system 320 and / or online resources 340. In some embodiments, the client device 350 may be configured to execute software instructions related to location services (e.g., Global Positioning System (GPS) location). For example, the client device 350 may be configured to determine a geographic location and provide location data and timestamp data corresponding to the location data. The client device 350 is further illustrated with reference to FIG4.

[0069] Database 380 may include one or more computing devices configured with suitable software to perform operations that provide data to scheduling system 320 for calculating delivery routes or for transacting with client device 350. Database 380 may include, for example, an Oracle™ database, a Sybase™ database, or other relational or non-relational databases, such as Hadoop™ sequence files, HBase™, or Cassandra™. Database 380 may include computing components (e.g., a database management system, a database server, etc.) configured to receive and process requests for data stored in the database's memory and to provide data from the database.

[0070] Although database 380 is shown separately, in some embodiments, database 380 may be included in scheduling system 320 or online resource 340, or otherwise associated with scheduling system 320 or online resource 340.

[0071] Database 380 may be configured to collect and / or maintain data associated with user accounts and user preferences. For example, database 380 may store information about user profiles of users of scheduling system 120. Database 380 may collect data from various sources, including, for example, online resources 340. In addition, database 380 may include information about user delivery preferences. For example, database 380 may include information about whether a user subscribes to Dawn Delivery. Database 380 is further illustrated below with reference to Figure 5.

[0072] Third-party system 360 may include one or more servers or one or more storage services provided by entities associated with scheduling system 320 (e.g., service providers or fulfillment centers). Third-party system 360 may be connected to system 300 via network 370, but in other embodiments, third-party system 360 may include direct connections to some elements of system 300. Furthermore, third-party system 360 may be configured to provide and / or request information from scheduling system 320 or other elements of system 300. In some embodiments, although third-party system 360 may also be coupled to network 370, third-party system 360 may not be a client of scheduling system 320. Instead, third-party system 360 may include a system containing information about users or clients of scheduling system 320. For example, third-party system 360 may include servers of delivery contractors such as FedEx®, which scheduling system 320 may use when additional resources are required to meet a target schedule.

[0073] The client system 390 may include one or more servers or one or more storage services that communicate with the scheduling system 320 via the network 370. In some embodiments, the client system 390 may send an order request to the scheduling system 320, which may process the order request in real time using the disclosed system and method. For example, the client system 390 may transmit a data stream containing an order request, which may include parameters such as promised delivery, item information, and delivery address. In this embodiment, the order transmitted from the client system 390 may further include user information, location, transaction volume, IP address, and / or currency. Furthermore, the client system 390 may operate on a Windows® operating system, a macOS® operating system, or a Linux® operating system.

[0074] Network 370 may be any type of network configured to provide communication between components of system 300. For example, network 370 may be any type of network (including infrastructure) that provides communication, exchanges information, and / or facilitates information exchange, such as the Internet, Local Area Network, Near Field Communication (NFC), optical code scanner, or other suitable connections capable of sending and receiving information between components of system 300. In other embodiments, one or more components of system 300 may communicate directly via a dedicated communication link. In still other embodiments, network 370 may include multiple networks, organizing, for example, one or more networks.

[0075] It should be understood that, for ease of explanation, the configuration and boundaries of the functional building blocks of system 300 have been defined herein. Alternative boundaries can be defined as long as the specified functions and their relationships are properly implemented. Alternatives (including equivalents, extensions, variations, deviations, etc. described herein) will be readily apparent. Such alternatives fall within the scope of the disclosed embodiments.

[0076] Referring now to FIG4, a block diagram 400 is shown of an exemplary client device 350 (FIG. 3) conforming to the disclosed embodiments. In some embodiments, the client device 350 may include transportation system mobility devices 107A, 107B and 107C, or management system devices 119A to 119C (FIG. 1A).

[0077] In one embodiment, the client device 350 may include one or more processors 402, one or more input / output (I / O) devices 404, and one or more memory units 410. In some embodiments, the client device 350 may be in the form of a mobile computing device (e.g., a smartphone or tablet), a general-purpose computer, or any combination of these components. Alternatively, based on the storage, execution, and / or implementation of software instructions that perform one or more operations conforming to the disclosed embodiments, the client device 350 (or a system including the client device 350) may be configured as a specific device, an embedded system, a special-purpose circuit, etc. According to some embodiments, the client device 350 may include a web browser or similar computing device that accesses a website conforming to the disclosed embodiments.

[0078] Processor 402 may include one or more known processing devices, such as mobile device microprocessors manufactured by Intel™, NVIDIA™, or various processors from other manufacturers. The disclosed embodiments are not limited to any particular type of processor configured in client device 350.

[0079] Memory 410 may include one or more storage devices configured to store instructions used by processor 402 to perform functions related to the disclosed embodiments. For example, memory 410 may be configured with one or more software instructions, such as program 412 that can be executed by processor 402. The disclosed embodiments are not limited to a single program or computer configured to perform a specific task. For example, memory 410 may include a single program 412 that performs the functions of client device 350, or program 412 may include multiple programs. Memory 410 may also store client 414 and data 416, which may be used to allocate deliveries to client devices during the operation of scheduling system 320.

[0080] In some embodiments, memory 410 may store instructions for accessing the scheduling system 320. For example, memory 410 may include an application that communicates with the scheduling system 320 via TCP / IP. Furthermore, other software components may be configured to request information from the scheduling system 320 or determine the location of the client device 350. For example, when executed by processor 402, these software instructions may process information to display the status of transactions.

[0081] I / O device 404 may include one or more devices configured to enable client device 350 to receive and / or transmit data, and to enable client device 350 to communicate with other machines and devices (e.g., other components of system 300). For example, I / O device 404 may include a screen for confirming package delivery or providing information to a user. I / O device 404 may also include components for NFC communication. I / O device 404 may also include one or more digital and / or analog devices, such as touch-sensitive areas, buttons, or microphones, that enable a user to interact with client device 350. I / O device 404 may also include one or more accelerometers to detect the orientation and inertia of client device 350. I / O device 404 may also include other components known in the art for interacting with scheduling system 320.

[0082] In some embodiments, the client device 350 may also include a camera 420 for capturing images and for verifying delivery completion. Alternatively, the client device 350 may include a fingerprint sensor 430, which enables the user to unlock the client device 350 and / or perform authentication. Both the camera 420 and the fingerprint sensor 430 may be operated by the processor 402 and use encryption security to prevent the user from accessing fingerprint or camera information externally.

[0083] As will be apparent to those skilled in the art, the components of the client device 350 can be implemented in hardware, software, or a combination of both.

[0084] Referring now to FIG5, a block diagram of an exemplary database 380 (FIG. 3) conforming to the disclosed embodiments is shown. In some embodiments, database 380 may be included in the elements of system 100. For example, database 380 may be part of FO system 113 or WMS 119 (FIG. 1A).

[0085] Database 380 may include communication device 502, one or more database processors 504, and database memory 510 including one or more database programs 512 and data 514. Database 380 may include a non-relational SQL (NoSQL) database, such as HBase, MongoDB™, or Cassandra™. Alternatively, database 380 may include a relational database, such as Oracle, MySQL, and Microsoft SQL Server.

[0086] In some embodiments, database 380 may take the form of a server, a general-purpose computer, a mainframe computer, or any combination of these components. In some embodiments, database 380 is included within other elements of system 300 (e.g., scheduling system 320). Other embodiments consistent with the disclosed embodiments are also possible.

[0087] In some embodiments, database 380 may include both a non-relational database and an embedded database. For example, database 380 may include a non-relational database such as HBase and an embedded database such as RocksDB (e.g., a key-value store database).

[0088] The communication device 502 may be configured to communicate with one or more components of the system 300 or system 100 (e.g., online resource 340, scheduling system 320, or SCM system 117). Specifically, the communication device 502 may be configured to provide the scheduling system 320 with order information, user preferences and privileges, and / or historical trends for developing forecasting models.

[0089] The components of the database 380 may be implemented in hardware, software, or a combination of both. For example, although one or more components of the database 380 may be implemented as a computer processing instruction module, all or part of the functionality of the database 380 may be implemented in dedicated electronic hardware.

[0090] Database memory 510 may include program 512, which may include instructions to support processing orders from client system 390 and interactions, such as between client device 350 and scheduling system 320. Further program 512 may include instructions to store information in real time as scheduling system 320 processes information.

[0091] Data 514 may also be data associated with the website, such as online resources 340 or user accounts from client devices 350. Data 514 may include, for example, information related to users and their credentials for obtaining content. Data 514 may also include content files and cumulative variables to evaluate historical trends in linking fulfillment centers with orders.

[0092] FIG6 is a flowchart of an exemplary cargo request processing procedure 600 conforming to the disclosed embodiments. In some embodiments, elements of system 300 may implement procedure 600. For example, scheduling system 320 may implement procedure 600 as disclosed in the following description. However, this is only an exemplary example of procedure 600, and in other embodiments, system 100 or a portion of system 100 may implement procedure 600. For example, shipping authorization technology system 101, FO system 113, and FC Auth 123 (FIG. 1A) may implement one or more steps in procedure 600.

[0093] In step 602, the scheduling system 320 may receive an electronic request. The electronic request may be received from a remote location. For example, the electronic request may be received from a remote client system 390 (FIG. 3). In addition, the electronic request may include goods information (e.g., item identifier (ID) and price) and delivery information (e.g., promised delivery date and / or specific instructions).

[0094] In step 604, the scheduling system 320 can determine information about the remote system that sent the request. For example, when the client system 390 sends a request to the scheduling system 320, the scheduling system can identify the client system 390's information based on order information. For example, in step 604, the scheduling system 320 can identify postal code, customer information, preferences, district, address, and / or privileges based on order information. Furthermore, in step 604, the scheduling system 320 can identify user name, postal code, physical location, or user preferences.

[0095] In step 606, the scheduling system 320 may determine one or more fulfillment centers that can complete and schedule orders. Fulfillment centers may be determined based on proximity to a postal code (e.g., identified in step 604), availability of goods, and / or predictability for a target delivery date. In step 606, the scheduling system 320 may also determine a zone associated with the electronic request, which can be used to identify target fulfillment centers. For example, the scheduling system 320 may identify fulfillment centers within a radius of the postal code associated with the request received in step 602.

[0096] In some embodiments, as further illustrated in conjunction with FIG. 9, determining the fulfillment center in step 606 may include using a forecasting model or tool based on historical trends or previous orders. For example, to determine the fulfillment center, the scheduling system 320 may perform the operation of storing multiple previous electronic requests and associated fulfillment centers in database 380 (FIG. 3), and dividing the previous electronic requests into a training dataset and a validation dataset, with the training dataset having more requests than the validation dataset. The scheduling system 320 may also perform the following operations: generating a forecasting model that associates request information with fulfillment centers based on the training dataset; validating the forecasting model using the validation dataset; and determining the fulfillment center by applying the forecasting model to the electronic requests.

[0097] In step 608, the scheduling system 320 determines the delivery process of the goods. For example, as previously described, the scheduling system 320 may operate using a two-wave process or a two-shift process. In step 608, the scheduling system 320 may analyze the forecast data of the fulfillment centers identified in step 606 to determine which delivery process best suits the requirements of the order received in step 602. Furthermore, in step 608, the scheduling system 320 may classify the order according to the delivery process. For example, if the scheduling system 320 determines that the optimal delivery process is two-wave, then in step 608, the scheduling system 320 may also determine that the order should be classified in the first wave, as further illustrated in conjunction with Figure 7. Alternatively, if the scheduling system determines that the optimal delivery is two-shift, then in step 608, the scheduling system 320 may determine that the order should be delivered in the first or second shift. Furthermore, in some embodiments, determining a delivery wave or delivery shift can be based on the order's cutoff time delivery. For example, a cutoff time of 12:00 would require delivery to be dispatched in wave 1 (defined between 0:00 and 18:00).

[0098] In some embodiments, determining the wave / shift delivery process includes modifying the estimated delivery process based on the day and time period for delivering goods to camp area 215 (FIG. 2). For example, the delivery wave estimate may be determined in step 608 based on the promised time and date of the package. Furthermore, the delivery wave estimate may be updated as the FC 200 changes or is updated. For example, for one type of FC 200, the delivery wave estimate may be wave 1, but for a second type of FC 200, the delivery wave estimate may be shift 2.

[0099] In step 610, the scheduling system 320 can determine whether the goods in the order have been assigned to different waves or shifts. For example, if the order includes two types of goods, and the first type of goods is assigned to wave 1 (defined as delivery from 0:00 to 18:00), while the second type of goods is assigned to wave 2 (defined as delivery from 18:00 to 24:00), then in step 610, the scheduling system 320 can determine that the two types of goods have been assigned to different waves. Alternatively, the two types of goods may have been assigned to different shifts. For example, goods 1 may have been assigned to shift 1 (defined as the western region (covering 50% of FC 200 area)), while goods 2 may have been assigned to shift 2 (defined as the eastern region (covering the remaining 50% of FC 200 area)). In this case, the scheduling system 320 can also determine that the goods have different shifts. Alternatively, or additionally, the two types of goods may have been assigned to different delivery processes. For example, the first shipment may have been assigned to wave delivery (i.e., by time segment), but the second shipment may have been assigned to shift delivery (i.e., by area segment). In this case, the scheduling system 320 can also determine whether the shipments are assigned to different waves or shifts.

[0100] If, in step 610, the scheduling system 320 determines that there are goods with different delivery waves or shifts (step 610: Yes), then process 600 may continue to step 612, in which the scheduling system 320 may modify the delivery waves or shifts to match efficiency conditions. When the scheduling system 320 determines that there is a conflict in the waves or shifts to be assigned to the goods, the scheduling system 320 may apply deconflicting rules to modify the goods assignment. Deconflicting rules may include last-mile changes, such as changes in location, time, route, and / or priority. In addition, deconflicting rules may include modifying order commitments (updating at delivery time while using timeslots), modifying the location of camp area 215 or FC 200 (reassigning valid delivery schedules), or modifying the agreed timeslot in direct customer-courier communications. Finally, deconflicting rules may include splitting shipments when, for example, the deconflicting rules cannot achieve the committed delivery date in a single shipment.

[0101] However, if the scheduling system 320 determines that the goods do not have different delivery waves or schedules (step 610: No), process 600 may skip step 612 and proceed directly to step 614. In step 614, the scheduling system 320 may generate an electronic message with delivery information, or generate an electronic message with information on multiple deliveries (if required). The electronic message may include information on the identified fulfillment center, the goods to be shipped, the time of day, and estimated delivery waves or schedules. The electronic message may be configured to be directed to one or more elements of system 100 and / or client device 350 as a TCP / IP message. In other embodiments, the electronic message of step 614 may be configured for printing labels at the camp or fulfillment center. For example, the electronic message may already include printing information because seamless integration between systems reduces the burden on managers to manually enter order information when generating shipping labels. The electronic message of step 614 may be configured to allow automatic printing of shipping labels. For example, the electronic message in step 614 can be configured directly in the Line Printer Daemon (LPD) protocol / Line Printer Remote (LPR) protocol (or LPD, LPR) of the networked printer. Alternatively, the electronic message in step 614 can be configured in the Internet Printing Protocol (IPP) or the Common UNIX Printing System (CUPS). Thus, the electronic message can be configured to print a shipping label, as further discussed in conjunction with Figure 11.

[0102] In step 616, the scheduling system 320 may forward or send the electronic message from step 614 to the identified fulfillment center or camp for completing the order. In some embodiments, the electronic message may be transmitted via a network to an administrator server, which then relays the information to the corresponding manager or worker. Alternatively, the electronic message may be transmitted directly to the manager or device. For example, the electronic information may be transmitted directly to a printer to automatically print package labels.

[0103] In step 618, the scheduling system 320 may generate one or more graphical user interfaces (GUIs) for displaying goods and / or their associated waves. The GUI may be configured to be displayed on an administrator's screen. For example, the GUI may be configured to be displayed on the screen of the LMS 125 (FIG. 1A). Alternatively, the GUI may be configured to be displayed on the screen of a client device 350 that can be operated by delivery workers to receive notifications and / or task assignments. Exemplary GUIs generated in step 618 are further illustrated in conjunction with FIG. 10 and FIGS. 12A through 12H.

[0104] In step 620, the scheduling system 320 may generate and send instructions to the fulfillment center to print shipping labels. For example, in an embodiment where the electronic message is addressed to a TCP / IP message rather than directly to a printer, the scheduling system 320 may generate print instructions for printing shipping labels. Instructions for printing shipping labels may include color-coded labels for different waves or shifts. Furthermore, the instructions may include priority notifications, such as "dawn delivery" or "premium delivery."

[0105] FIG7 is a flowchart of an exemplary delivery sorting process 700 conforming to the disclosed embodiments. In some embodiments, elements of system 300 may implement process 700. For example, scheduling system 320 may implement process 700, as described below. However, in other embodiments, system 100 or a portion of system 100 may implement process 700. For example, shipping authorization technology system 101, FO system 113, and FC Auth 123 (FIG. 1A) may implement one or more steps of process 700.

[0106] In step 702, the scheduling system 320 may receive an order or a request. For example, the scheduling system 320 may receive an order from a client system 390 or a request from a third-party system 360. In some embodiments, the order may have similar characteristics to the order received in step 602, including customer information, goods information, and delivery commitment.

[0107] In step 704, the scheduling system 320 may determine the delivery location, associated delivery commitment, and order time based on the received order or request. For example, in step 704, the scheduling system 320 may determine the postal code, customer information, and customer preferences based on the received order information.

[0108] In step 706, the scheduling system 320 may determine whether there is a delivery commitment associated with the order. For example, some orders may include a "dawn delivery" delivery commitment. In contrast, other orders or requests may not be associated with any commitment. In step 706, the scheduling system 320 may decode information in the order or request to determine whether a delivery commitment exists. If the scheduling system 320 determines that a delivery commitment exists (step 706: yes), the scheduling system 320 may proceed to step 708.

[0109] In step 708, the scheduling system 320 may determine whether there is a commitment for "dawn delivery" or whether the commitment is for an alternative delivery time. If the commitment is for dawn delivery (step 708: Yes), the scheduling system 320 may proceed to step 710 and expedite the delivery of the order. Expediting delivery may include generating a GUI for the administrator to notify that dawn delivery is imminent. Further expediting dawn delivery orders may include generating a notification GUI and specific printing instructions for the client device 350. If the commitment is not for dawn delivery (step 708: No), the scheduling system 320 may proceed to step 712 and assign a wave or shift that matches the commitment. For example, if the commitment is for delivery at 20:00, the scheduling system 320 may assign the order to wave 2 (defined as 18:00 to 24:00).

[0110] If, in step 706, the scheduling system 320 determines that there is no delivery commitment associated with the order (step 706: No), the scheduling system 320 may proceed to step 714 and determine the estimated arrival time of the order from the fulfillment center to the camp. For example, after identifying the fulfillment center, the scheduling system 320 may estimate the arrival time at the delivery camp based on historical trends, distance, and / or delivery rotation.

[0111] In step 716, the scheduling system 320 determines whether the order can arrive at the delivery camp before the first wave or shift. If the scheduling system 320 determines that the order may arrive before the first wave or shift (step 716: Yes), the scheduling system 320 may continue to step 718 and assign the order to the first wave or shift. However, if the scheduling system 320 determines that the order may not arrive before the first wave or shift (step 716: No), the scheduling system 320 may assign the order to the second wave or shift in step 720.

[0112] As shown in Figure 7, the different steps of process 700 converge in step 722, in which scheduling system 320 generates a GUI for indicating orders, delivery waves, shift waves, and / or addresses. That is, regardless of the specific wave / shift or priority assigned to an order, process 700 can generate a GUI based on order classification for administrators and / or workers.

[0113] In step 724, the scheduling system 320 may generate instructions for printing shipping labels that include delivery wave / shift numbers. As further discussed in conjunction with Figure 11, the shipping labels may include indications of the delivery process, such as delivery wave or shift numbers.

[0114] In step 726, the scheduling system 320 may generate instructions for displaying delivery grouping options in the client device 350. For example, as further discussed in conjunction with FIG12G, the scheduling system 320 may generate instructions for grouping in a notification in the client device 350 based on the dispatch of orders during process 700.

[0115] FIG8 is a flowchart of an exemplary delivery optimization process conforming to the disclosed embodiments. In some embodiments, elements of system 300 may implement process 800. For example, scheduling system 320 may implement process 800 as described below. Alternatively, process 800 may be implemented by system 100 or a portion of system 100. For example, shipping authorization technology system 101, FO system 113, and FC Auth 123 (FIG. 1A) may implement one or more steps in process 800.

[0116] In step 802, the scheduling system 320 may receive an electronic request containing cargo, location, and delivery commitment information. The electronic request may be similar to the request received in step 602 (Figure 6).

[0117] In step 804, the scheduling system 320 can be applied as a pre-defined delivery process for wave scheduling. Wave scheduling can better cover the area and facilitate logistics to meet the guaranteed date. Therefore, in step 804, the scheduling system 320 can be pre-defined as a wave scheduling process to initially guarantee the fulfillment of delivery commitments.

[0118] In step 806, the scheduling system 320 may predict the demand for multiple camps and / or fulfillment centers based on a forecasting model. As further disclosed in conjunction with Figure 9, the scheduling system 320 may use prior data to predict demand in order to train and validate the forecasting model. For example, the scheduling system 320 may generate a forecasting model based on a random forest to estimate the demand in each fulfillment center based on historical data of its performance.

[0119] In step 808, the scheduling system 320 may identify an optimized delivery process based on forecasts, commitments, location, and cargo information. In step 808, the scheduling system 320 may calculate delivery routes based on preset delivery processes. For example, the scheduling system 320 may generate nodes for customer locations, calculate the travel time between each pair of customers and camp area 215 (or FC 200), and assign selected locations to the nearest available address. In some embodiments, Manhattan distance may be used to calculate the distance between each pair of destinations. Next, the scheduling system 320 may calculate and constrain delivery routes based on worker hours, driver ability, and traffic. Then, each of the factors in the route is optimized according to distance, number of workers, and required number of camp visits.

[0120] In some embodiments, the scheduling system 320 may use combinatorial optimization to identify the optimal delivery process. The scheduling system 320 may calculate cost-effective delivery routes by utilizing heuristics for each vehicle route. For example, the scheduling system 320 may use the Clark-Wright Savings algorithm or a similar method to identify the optimal delivery process. In this embodiment, the optimal delivery process may be identified based on the minimum travel time. Alternatively or additionally, the scheduling system 320 may use customer-to-spatial clustering and algorithms to enhance delivery efficiency. In this embodiment, clusters may be calculated for each delivery day in a manner that ensures the cluster does not exceed the maximum number of customers per route.

[0121] Once the optimized delivery process is identified, the scheduling system 320 can proceed to step 810 and determine whether the identified delivery process is the same as the preset delivery process. For example, if the optimization indication in step 808 indicates that the optimized delivery process is wave delivery, the scheduling system 320 will determine that the optimized delivery process matches the preset delivery process (step 810: Yes). However, if the optimization indication in step 808 indicates that the optimized delivery process is shift delivery, the scheduling system 320 will determine that the optimized delivery process does not match the preset delivery process (step 810: No).

[0122] If the scheduling system 320 determines that the delivery process is mismatched (step 810: No), the scheduling system 320 may continue to step 812 and change the delivery process to optimized delivery. For example, in step 812, the scheduling system 320 may switch the delivery process of a group of orders from wave delivery to shift delivery based on the predictions and optimizations in steps 806 and 808.

[0123] In step 814, the scheduling system 320 may update the components of system 100 and / or system 300 according to the optimized delivery process. For example, the scheduling system 320 may update the FO system 113, the shipping authorization technology system 101, the SCM system 117, the WMS 119, and the LMS 125 (Figure 1A).

[0124] In step 816, the scheduling system 320 may generate a scheduling notification GUI for management or workers. For example, updates to the delivery process may also include sending notifications to client devices 350 and / or updating the GUI on the management screen, as further discussed in conjunction with Figure 9. Furthermore, changes in the optimized delivery process may be reflected in the print instructions.

[0125] For process 800, scheduling system 320 improves the technical field of automated delivery scheduling by creating an adaptive system that can select between different delivery processes based on optimization variables. While current systems require system administrators to manually select between different delivery processes (e.g., between wave delivery or shift delivery), process 800 allows the system to be dynamically adjusted using demand forecasting based on optimization conditions. In fact, the forecasting and optimization described in steps 806 to 808 enable frequent and concurrent selection of delivery processes. Therefore, process 800 illustrates a specific computerized approach for operating a parcel delivery system with improved technical advantages.

[0126] FIG9 is an exemplary flowchart illustrating a forecast model training process 900 according to the disclosed embodiment. In some embodiments, elements of system 300 may implement process 900. For example, scheduling system 320 may implement process 900, as described below. However, this is merely an exemplary example of process 900, and in other embodiments, system 100 or a portion of system 100 may implement process 900. For example, shipping authorization technology system 101, FO system 113, and FC Auth 123 (FIG. 1A) may implement one or more steps in process 900.

[0127] In step 902, the scheduling system 320 may receive a request for a forecast model of demand in the fulfillment center. In some embodiments, the request may specify a target FC 200 or camp area 215 (FIG. 2). The request may include information about the client device 350 or previous order information. Furthermore, the request may originate from the client device 350.

[0128] In step 904, the scheduling system 320 may generate a modeling dataset. The scheduling system 320 may use information from the database 380, online resources 340, and / or client devices 350 to generate the modeling dataset. For example, the scheduling system 320 may retrieve historical trends of orders and their corresponding fulfillment centers from the database 380. Previous order data may also include performance metrics, such as distance between deliveries, unfulfilled commitment dates, and package priority.

[0129] In step 906, the scheduling system 320 may create a subset of modeling data by partitioning the modeling dataset generated in step 904. For example, the scheduling system 320 may partition the modeling dataset into a training dataset subset and a validation dataset subset. In some embodiments, the training and validation datasets may be randomly created by arbitrarily selecting elements from the modeling dataset of each subset. However, in other embodiments, the scheduling system 320 may utilize predetermined rules to partition the data. In some embodiments, elements in the modeling dataset subset may be unique for each subset to create independent training and validation subsets. Alternatively, the modeling dataset subsets may share elements and overlap. In other embodiments, the scheduling system 320 may use partitioning rules to partition the modeling dataset. The modeling dataset partitioning rules may indicate the number of partitions and / or the ratio between different groups. For example, the modeling dataset may be partitioned into test and validation datasets using an 80 / 20 partitioning method.

[0130] Based on the segmentation of the modeling dataset, the scheduling system 320 may select a classifier in step 907. The scheduling system 320 may also process the modeling dataset from step 906 to determine the coefficients (step 908) and hyperparameters (step 910) of the forecast model. The forecast model may be specifically designed for FC 200 requirements and may be parametric, nonparametric, or semiparametric. For example, in some embodiments, the scheduling system 320 may create multiple decision trees as forecast models to identify the probability of fraud. In other embodiments, the scheduling system 320 may generate neural networks, Group Method of Data Handling (GMDH) algorithms, Naive Bayes classifiers, and / or Multivariate Adaptive Regression Splines. Alternatively or additionally, the scheduling system 320 may generate models based on linear regression, random forests, and / or logistic regression. For example, scheduling system 320 can develop a random forest model to predict demand in both FC 200 and camp 215. With parameters such as day of the week, time, order type, and destination address, the model generated in steps 906 to 910 can create tools for predicting demand in fulfillment centers or camps and the ability to meet delivery targets.

[0131] In step 914, the scheduling system 320 may evaluate whether the model is complete or whether the model has met the stopping criterion. For example, when the scheduling system 320 generates a decision tree, in step 914, the scheduling system 320 may evaluate whether the ending node meets the stopping criterion. In some embodiments, the stopping criterion may be inherent to the model or defined by hyperparameters.

[0132] If the stopping criterion is not met, the scheduling system 320 may proceed to step 916 and select new variables or parameters to determine a new classifier. For example, for variables of delivery date and time, the scheduling system 320 may include variables of delivery preferences or customer privileges. Alternatively, when the stopping criterion is met, the scheduling system 320 may proceed to step 918, where the scheduling system 320 may use a portion of the training dataset to calculate the accuracy of the model.

[0133] In step 920, the scheduling system 320 may evaluate whether the accuracy of the model is higher than an accuracy threshold. In some embodiments, the accuracy threshold of the model may be automatically adjusted based on an optimization target set for the forecast model. If the accuracy of the model is not higher than the threshold (step 920: No), the model may be discarded in step 926. If the calculated accuracy is higher than the threshold (step 920: Yes), the scheduling system 320 may assign weighting coefficients to the model in step 922 and include the model in a model group in step 924. The weighting coefficients may be correlated with the calculated accuracy. For example, the weighting coefficients may be proportional to the accuracy.

[0134] The process can be repeated more than 900 times to generate multiple models. In some embodiments, the scheduling system 320 can repeat the process until a minimum number of models are generated.

[0135] FIG10 is a front view of an exemplary graphical user interface (GUI) 1000 in an administrator device conforming to the disclosed embodiment. The GUI 1000 may be displayed on a device of the management system 119 (e.g., devices 119A to 119C) and may be updated as an order is received. The GUI 1000 may also be displayed on other devices of the system 100 (e.g., devices in the internal front-end system 105 (FIG. 1A)).

[0136] The GUI 1000 includes multiple columns 1002(a) to 1002(n). Each of the columns 1002 can identify a package to be delivered. For example, each of the columns 1002 can be associated with an order received, for example, in step 602 (Figure 6).

[0137] As shown in Figure 10, the GUI 1000 may include multiple rows that detail different information fields for each of the columns 1002. The GUI 1000 may include a tracking number row 1004, a shipper name row 1006, a customer ID row 1008, a date row 1010, and a delivery process row 1012. In some embodiments, the delivery process row 1012 may specify which wave or shift the order has been assigned to, such as process 900 (Figure 9). The delivery process row 1012 may also indicate whether the order is scheduled for dawn delivery.

[0138] In addition, the GUI 1000 may include action rows 1014, which allow system administrators to perform actions on orders in the corresponding column 1002. These actions may include printing shipping labels, deleting, modifying, and / or reassigning.

[0139] FIG11 is an exemplary shipping label 1100 conforming to the disclosed embodiment. The shipping label 1100 may be generated in step 620 (FIG. 6) or step 724 (FIG. 7).

[0140] The shipping label 1100 may include a delivery process note 1102. The delivery process note 1102 may specify wave or shift delivery, or dawn or overnight delivery. The shipping label 1100 may also include a barcode 1104, a destination address 1106, and a return address 1108. As previously discussed in conjunction with FIG6, in some embodiments, the shipping label 1100 may be automatically generated and printed based on classification or categorization.

[0141] FIG12A is a front view of a first exemplary graphical user interface (GUI) 1201 in a mobile device conforming to the disclosed embodiment. GUI 1201 shows a schematic diagram of the main menu 1202 of a delivery service application.

[0142] FIG12B is a front view of a second exemplary graphical user interface (GUI) 1203 in a mobile device conforming to the disclosed embodiment. GUI 1203 shows a series of deliveries 1204(a) to 1204(n). For each of the deliveries 1204, GUI 1203 displays a plurality of buttons for accepting, rejecting, and completing actions, etc.

[0143] FIG12C is a front view of a third exemplary graphical user interface (GUI) 1205 in a mobile device conforming to the disclosed embodiment. GUI 1205 shows a grouping options banner 1206. Based on the delivery process (i.e., wave delivery or shift delivery), banner 1206 gives the user the option to manually adjust the delivery in different groups. For example, when a user of client device 350 has a suggestion to adjust the delivery process, the user can update the system directly in their mobile phone. In some cases, workers may have more up-to-date information about delivery capabilities. Road accidents or other unforeseen circumstances may hinder deliveries with optimized schedules that are automatically implemented by, for example, scheduling system 320. GUI 1205 allows users to provide feedback and suggest different groups for delivery.

[0144] FIG12D is a front view of a fourth exemplary graphical user interface (GUI) 1207 in a mobile device conforming to the disclosed embodiment. To address the technical problem of displaying multiple items in the limited screen space of a mobile phone, GUI 1207 shows a filter 1208. Filter 1208 can be used to reduce the number of deliveries 1204 displayed in the mobile phone. Filter 1208 can operate by selecting orders based on the delivery process, delivery coverage, and / or delivery area.

[0145] FIG12E is a front view of a fifth exemplary graphical user interface (GUI) 1209 in a mobile device conforming to the disclosed embodiment. GUI 1209 shows a new delivery banner 1210 to add a new delivery that is being displayed on the screen. In addition, banner 1210 may allow the user to request additional deliveries or notify that a pending delivery may not be completed.

[0146] FIG12F is a front view of a sixth exemplary graphical user interface (GUI) 1211 in a mobile device conforming to the disclosed embodiments. GUI 1211 shows options for grouping deliveries 1212. As shown in FIG12F, GUI 1211 associates each of the deliveries 1212 with a group icon.

[0147] FIG12G is a front view of a seventh exemplary graphical user interface (GUI) 1213 in a mobile device conforming to the disclosed embodiment. After selecting deliveries to be grouped in GUI 1211, GUI 1213 may be displayed to allow workers to select a specific wave / shift or other delivery process for a group of selected deliveries 1212. As shown in FIG12G, GUI 1213 may include a selection menu 1214 in which the user can indicate which group the selected deliveries should be assigned to.

[0148] FIG12H is a front view of an eighth exemplary graphical user interface (GUI) 1215 in a mobile device conforming to the disclosed embodiment. GUI 1215 shows a new group creation menu 1216. Users can use GUI 1215 to add new modes or shifts to the delivery process.

[0149] Another aspect of this disclosure relates to a non-transitory computer-readable medium storing instructions that, when executed, cause one or more processors to perform the methods described above. The computer-readable medium may include volatile or non-volatile, magnetic, semiconductor, magnetic tape, optical, removable, non-removable, or other types of computer-readable media or computer-readable storage devices. For example, as disclosed herein, the computer-readable medium may be a storage unit or memory module on which computer instructions are stored. In some embodiments, the computer-readable medium may be a magnetic disk or flash drive on which computer instructions are stored.

[0150] It will be apparent to those skilled in the art that various modifications and variations can be made to the disclosed system and related methods. Other embodiments will be apparent to those skilled in the art, taking into account the description and practice of the disclosed system and related methods. The description and examples are intended to be considered exemplary only, and the true scope is indicated by the following claims and their equivalents.

[0151] Although this disclosure has been shown and described with reference to specific embodiments thereof, it should be understood that this disclosure can be practiced in other environments without modification. The foregoing description is presented for illustrative purposes. The foregoing description is not exhaustive and is not limited to the precise forms or embodiments disclosed. Various modifications and adjustments will become apparent to those skilled in the art from the description and practice of the disclosed embodiments. In addition, although the forms of the disclosed embodiments are described as being stored in memory, those skilled in the art should understand that such forms can also be stored on other types of computer-readable media, such as auxiliary storage devices (e.g., compact disk read-only memory, CD ROM) or other forms of random access memory (RAM) or read-only memory (ROM), universal serial bus (USB) media, digital versatile disc (DVD), Blu-ray, or other optical drive media.

[0152] Computer programs based on the written description and the disclosed methods are within the skill level of experienced developers. Various programs or program modules can be created using any techniques known to those skilled in the art, or can be designed in conjunction with existing software. For example, program sections or program modules can be designed using or with the aid of the .NET Framework, .NET Compact Framework (and related languages ​​such as Visual Basic, C, etc.), Java, C++, Objective-C, HTML, HTML / AJAX combinations, XML, or HTML including Java applets.

[0153] Furthermore, although exemplary embodiments have been described herein, those skilled in the art will contemplate any and all embodiments with equivalent elements, modifications, omissions, combinations (e.g., combinations of forms between various embodiments), adjustments, and / or alterations based on this disclosure. The limitations in the claims should be interpreted broadly based on the language used in the claims, and not limited to the examples set forth in this specification or during the application process. These examples should be considered non-exclusive. Moreover, the steps of the disclosed methods can be modified in any way, including by reordering the steps and / or inserting or deleting steps. Therefore, this specification and examples are intended to be illustrative only, and the true scope and spirit are indicated by the full scope of the following claims and their equivalents.

[0154] Therefore, the foregoing description is presented for illustrative purposes only. The description is not exhaustive and is not limited to the precise forms or embodiments disclosed. Modifications and adjustments will be readily apparent to those skilled in the art, taking into account the specification and practice of the disclosed embodiments.

[0155] The scope of the patent application shall be interpreted broadly based on the language used in the scope of the patent application and is not limited to the examples set forth in this specification, which shall be considered non-exclusive. Furthermore, the steps of the disclosed method may be modified in any way, including by reordering the steps and / or inserting or deleting steps. [Simplified Explanation of the Diagram]

[0011] FIG1A is a schematic block diagram illustrating an exemplary embodiment of a network conforming to the disclosed embodiments, the network including a computerized system for shipping, transportation, and logistics operations capable of communication. FIG1B illustrates a sample Search Result Page (SRP) conforming to the disclosed embodiments, which includes one or more search results satisfying a search request and interactive user interface elements. FIG1C illustrates a sample Single Display Page (SDP) conforming to the disclosed embodiments, which includes goods and information about the goods and interactive user interface elements. FIG1D illustrates a sample Cart page conforming to the disclosed embodiments, which includes items in a virtual shopping cart and interactive user interface elements. FIG1E illustrates a sample Order page conforming to the disclosed embodiments, which includes items from a virtual shopping cart and information about purchasing and shipping, and interactive user interface elements. FIG2 is an illustration of an exemplary fulfillment center configured to utilize the disclosed computerized system conforming to the disclosed embodiments. FIG3 is a schematic block diagram of an exemplary system conforming to the disclosed embodiments. Figure 4 is a block diagram of an exemplary client device conforming to the disclosed embodiments. Figure 5 is a block diagram of an exemplary database conforming to the disclosed embodiments. Figure 6 is a flowchart of an exemplary cargo request processing procedure conforming to the disclosed embodiments. Figure 7 is a flowchart of an exemplary delivery classification process conforming to the disclosed embodiments. Figure 8 is a flowchart of an exemplary delivery optimization process conforming to the disclosed embodiments. Figure 9 is an exemplary flowchart illustrating a forecast model training process conforming to the disclosed embodiments. Figure 10 is a front view of an exemplary graphical user interface in an administrator device conforming to the disclosed embodiments. Figure 11 is an exemplary shipping label conforming to the disclosed embodiments. Figure 12A is a front view of a first exemplary graphical user interface in a mobile device conforming to the disclosed embodiments. Figure 12B is a front view of a second exemplary graphical user interface in a mobile device conforming to the disclosed embodiments. Figure 12C is a front view of a third exemplary graphical user interface in a mobile device conforming to the disclosed embodiments. Figure 12D is a front view of a fourth exemplary graphical user interface in a mobile device conforming to the disclosed embodiments. Figure 12E is a front view of a fifth exemplary graphical user interface in a mobile device conforming to the disclosed embodiments. Figure 12F is a front view of a sixth exemplary graphical user interface in a mobile device conforming to the disclosed embodiments. Figure 12G is a front view of a seventh exemplary graphical user interface in a mobile device conforming to the disclosed embodiments. Figure 12H is a front view of an eighth exemplary graphical user interface in a mobile device conforming to the disclosed embodiments.

Claims

1. A computer-implemented method for automatically communicating with a fulfillment center, the method comprising: A forecasting model is generated based on a training dataset, which includes multiple historical orders associated with the requesting client and the assigned fulfillment center. The client device receives an order, the order including the client location and cargo information associated with a first cargo and a second cargo; the client location and cargo information are applied to the forecast model to determine the delivery process of the order, wherein the determined delivery process is selected from two delivery processes, wherein determining the delivery process includes: determining a first delivery process for the first cargo and a second delivery process for the second cargo; determining whether there is a delivery conflict between the first delivery process and the second delivery process; And based on the determination of the existence of the delivery conflict, apply conflict resolution rules to the first delivery process and the second delivery process, the conflict resolution rules including modifying the location, time or route of the first delivery process or the second delivery process; determine the fulfillment center for completing the order based on the determined delivery process and the estimated arrival time from the fulfillment center to the camp area; transmit an electronic message to the fulfillment center, the electronic message including: the determined fulfillment center, the first goods and the second goods, and the delivery process.

2. The computer implementation method as described in claim 1, wherein the two delivery processes include a shift delivery process and a wave delivery process.

3. The computer implementation method as described in claim 2, wherein: The scheduled delivery process arranges order delivery based on a specific area; and the wave delivery process arranges order delivery based on delivery time.

4. The computer implementation method as described in claim 2, wherein the electronic message further includes instructions for printing a label specifying one of the shift delivery process or the wave delivery process.

5. The computer implementation method as described in claim 1 further includes: It has been confirmed that temporary workers are available; The delivery process is updated by reapplying the forecast model to the client location, the cargo information, and the location of the temporary worker.

6. The computer implementation method as described in claim 1 further includes: A graphical user interface is generated, which includes an option banner specifying the delivery process and a modification icon for manually adjusting the delivery process; And the resulting graphical user interface is transferred to one or more of a plurality of mobile devices associated with the courier.

7. The computer implementation method as described in claim 1, wherein the conflict resolution rule further includes at least one of the following: modifying last-mile delivery, or modifying the agreed-upon time slot in direct customer-courier communication.

8. The computer implementation method as described in claim 1, wherein determining the delivery process includes: Determine whether the order includes a dawn delivery commitment; In response to determining that the order includes the dawn delivery commitment: dispatch the order to expedited delivery; and generate a label printing instruction that includes the dawn delivery specification instruction.

9. The computer implementation method as described in claim 8, wherein the label printing instruction is configured in a print resident protocol for a networked printer.

10. A computer-implemented system for automatic communication with a fulfillment center, the system comprising: At least one non-transitory computer-readable medium is configured to store instructions; And at least one processor configured to execute the instructions to implement the computer implementation method of any one of claims 1-9.

Images