TWI792138B - Computer-implemented system and computer-implemented method for managing incoming requests and data package assignments, and computer-implemented system for generating tasks - Google Patents

Abstract

Computer-implemented systems and methods configured to generate a plurality of data packages based on a combination of data elements; add the plurality of data packages to a data package pool configured to store available data packages for assignment; receive an assignment request from a user device in communication with a management server; add the assignment request to a request pool configured to queue a plurality of assignment requests, wherein generating the plurality of data packages and receiving the assignment request occur asynchronously; retrieve a first group of one or more data packages from the data package pool; retrieve a second group of one or more assignment requests from the request pool; assign the one or more data packages of the first group to the one or more assignment requests of the second group; and transmit the one or more assignment requests to corresponding user devices with the assigned data packages.

Description

A computerized implementation system for managing incoming requests and package assignments and Computer implementation method, and computer implementation system for generating tasks

The present disclosure generally relates to computerized methods and systems for solving network traffic congestion caused by multiple user requests. In particular, embodiments of the present disclosure are directed to an inventive and unconventional system that pools multiple user requests instead of processing them linearly when the multiple requests exceed the system's capabilities.

As information technology develops and more activities take advantage of the automation, efficiency and accuracy enabled by computer systems, there is a developing need for computer systems capable of handling a greater number of incoming inquiries. For example, a game server for a popular online game may need to handle data requests from hundreds of thousands of users simultaneously. As another example, in a business operations setting, a labor management server may need to handle task requests from hundreds of users simultaneously. A server that cannot handle enough requests to meet incoming demand levels can become a bottleneck that slows down the entire operation.

When there is a sudden surge in demand, such as the founding day of a popular online game Or warehouse holiday season, this problem becomes even worse. A server may begin rejecting or delaying incoming requests after reaching its capacity, at which point users who have rejected requests must try again. The combined time spent by users retrying and waiting for the server to process requests can quickly add up to a major loss in productivity.

Furthermore, users often cannot be scaled when the server is available to handle more requests, and each user finishes retrying after an arbitrary period of interruption, which is ineffective in reducing the influx of requests to the server. Spamming requests (ie, retrying in rapid succession) further aggravates the situation because it expands the number of requests the server thinks it has to handle, causing more delays and rejections for everyone.

These problems caused by the overwhelming number of parallel requests cause network congestion resulting in reduced quality of service, loss of productivity, and potential server crashes.

A direct solution is to increase the number of servers to increase processing power. However, this solution would incur installation and operating costs for additional servers and introduce additional points of failure. Another pooling solution could implement queuing, where incoming requests can wait until the server's processing power is freed up. However, this is not sufficient as it does not change the speed at which the server processes individual requests. Users must still wait indefinitely until the server can process their request.

Therefore, there is a need for a solution that can efficiently manage incoming demands even when the demands overwhelm processing power.

One aspect of the disclosure is directed to a computer-implemented system for managing incoming requests and data package assignments. The system can include: memory storing instructions; and at least one processor configured to execute the instructions. Directives can include: Groups based on data elements combining to generate a plurality of data packets; adding the plurality of data packets to a data packet pool configured to store available data packets for a designation; receiving a designation request from a user device in communication with the management server ;Adds the specified request to a request pool configured to queue multiple specified requests where multiple packets are generated and receiving the specified request occurs asynchronously; the first to retrieve one or more packets from the packet pool group; retrieve a second group of one or more specified requests from the request pool; assign one or more packets of the first group to one or more specified requests of the second group; and assign one or more A specified request is transmitted to the corresponding user device together with the specified data package.

Yet another aspect of the present disclosure is directed to a computer-implemented method for managing incoming requests and packet assignments. The method may include: generating a plurality of data packets based on a combination of data elements; adding the plurality of data packets to a data packet pool configured to store available data packets for a specified; from the management server A communicating user device receives a specified request; adds the specified request to a request pool configured to queue a plurality of specified requests, wherein generating multiple data packets and receiving the specified request occurs asynchronously; retrieves a specified request from the packet pool A first group of one or more packets; retrieve a second group of one or more specified requests from the request pool; assign one or more packets of the first group to one or more of the second group specifying requests; and transmitting one or more specified requests together with the specified data package to the corresponding user device.

Still further, another aspect of the present disclosure is directed to a computer-implemented system that generates tasks in response to user requests. The system can include: memory storing instructions; and at least one processor configured to execute the instructions. The instructions may include: generating multiple batches of jobs based on accumulated customer orders, adding multiple batch indicators referencing the multiple batches of jobs to the first queue; receiving multiple batch requests from multiple user devices; Add multiple batch requests to second queue; retrieve batch index from first queue and retrieve a second group of batch requests from a second queue; associate individual batch indicators for the first group with individual batch requests for the second group; and associate one or more Individual batch requests associated with the batch references are transmitted to respective user devices configured to retrieve one or more batch jobs referenced by the one or more batch references.

Other systems, methods, and computer-readable media are also discussed herein.

100: system

101: Shipping Authorization Technology System

102A, 107A, 107B, 107C, 119A, 119B, 119C: mobile devices

102B: Computer

103:External front-end system

105:Internal front-end system

107: Transportation system

109:Seller Portal

111: Shipping and Order Tracking System

113, 311: Fulfillment optimization system

115: Fulfillment communication report gateway

117: Supply chain management system

119: Warehouse management system

121A, 121B, 121C: Third Party Fulfillment Systems

123: Fulfillment Center Authorization System

125: Labor management system

200: Fulfillment Center

201: truck

202A, 202B, 208: objects

203: Inbound area

205: buffer

206: forklift

207: unloading area

209: Picking area

210: storage unit

211: Packing area

213: Hub area

214: Transport Agency

215: Camp area

216: wall

218, 220: Parcel

222:Truck

224A, 224B: delivery workers

226: car

300: Networked environment

310: Data Generation System

320: client device

330:packet management server

331: front-end server

332:Backend server

333: request pool

334: Packet pool

400, 500: process

401, 402, 403, 404, 405, 406, 407, 408, 409, 410, 411, 412, 413: steps

501: Lemonade

502: tomato sauce

503: Shredded Cheese

504: desktop computer

505: Toy tablet

506: hot sauce

507: chilli sauce

508: toy car

509: toy truck

510A: Order A

510B: Order B

510C: Order C

510D: Order D

520A: Batch job A

520B: Batch job B

520C: Batch work C

521A: container group A

521B: container group B

521P: container group P

521X: container group X

521Y: container group Y

FIG. 1A is a schematic block diagram illustrating an exemplary embodiment of a network including a computerized system of communications for enabling shipping, transportation, and logistics operations, consistent with disclosed embodiments.

FIG. 1B depicts a sample Search Result Page (SRP) including one or more search results and interactive user interface elements that satisfy a search request, consistent with disclosed embodiments.

FIG. 1C depicts a sample Single Display Page (SDP) including a product and information about the product, as well as interactive user interface elements, consistent with disclosed embodiments.

Figure ID depicts a sample shopping cart page including items in a virtual shopping cart and interactive user interface elements consistent with disclosed embodiments.

FIG. 1E depicts a sample order page including items from a virtual shopping cart along with information about purchase and shipping and interactive user interface elements consistent with disclosed embodiments.

FIG. 2 is a diagram of a computerized system configured to utilize the disclosed computerized system consistent with the disclosed embodiments. A schematic illustration of an exemplary fulfillment center for the system.

3 is a schematic block diagram illustrating an exemplary embodiment of a networked environment including a computerized system for managing incoming requests and packet assignments, consistent with disclosed embodiments.

4 is a flow diagram of an exemplary computerized process for managing incoming requests and package assignments consistent with disclosed embodiments.

5 is an illustration of an exemplary order allocation process consistent with disclosed embodiments.

The following detailed description refers to the accompanying drawings. Wherever possible, the same reference numbers will be used in the drawings and the following description to refer to the same or like parts. While a number of illustrative examples are described herein, modifications, adaptations, and other implementations are possible. For example, substitutions, additions or modifications may be made to the components and steps shown in the drawings, and the description herein may be modified by substituting, reordering, removing or adding steps to the disclosed methods illustrative method. Accordingly, the following detailed description is not limited to the disclosed embodiments and examples. Rather, the true scope of the invention is defined by the appended patent claims.

Embodiments of the present disclosure are directed to systems and methods configured for pooling multiple user requests, even when the requests are greater than processing capacity. The disclosed embodiments may be practiced on any system that is at risk of being overwhelmed by a flood of incoming requests.

Referring to FIG. 1A , there is shown a schematic block diagram 100 of an exemplary embodiment of a system including a computerized system for enabling communications for shipping, transportation, and logistics operations. As shown in FIG. 1A , system 100 may include various systems, each of which may be connected to each other via one or more networks. The system can also be connected directly via (for example, using a cable) to each other. The depicted system includes a shipment authority technology (SAT) system 101, an external front-end system 103, an internal front-end system 105, a shipping system 107, a mobile device 107A, a mobile device 107B, and a mobile device 107C, a vendor portal 109, shipping and Order tracking (shipment and order tracking; SOT) system 111, fulfillment optimization (fulfillment optimization; FO) system 113, fulfillment messaging gateway (fulfillment messaging gateway; FMG) 115, supply chain management (supply chain management; SCM) System 117, warehouse management system 119, mobile device 119A, mobile device 119B, and mobile device 119C (depicted as located inside fulfillment center (FC) 200), 3rd party fulfillment system 121A, 3rd party fulfillment system 121B, and 3rd party fulfillment system 121C, fulfillment center authorization system (fulfillment center authorization; FC Auth) 123 and labor management system (labor management system; LMS) 125 .

In some embodiments, the SAT system 101 can be implemented as a computer system that monitors order status and delivery status. For example, the SAT system 101 can determine whether an order has passed its Promised Delivery Date (PDD), and can take appropriate actions, including initiating a new order, reshipping items in non-delivery orders, canceling non-delivery order, initiate contact with ordering customers, or the like. The SAT system 101 may also monitor other data, including outputs (such as the number of packages shipped during a particular time period) and inputs (such as the number of empty cartons received for shipping). SAT system 101 may also act as a gateway between different devices in system 100, enabling communication between devices such as external front-end system 103 and FO system 113 (eg, using store-and-forward or other techniques).

In some embodiments, the external front-end system 103 may be implemented such that the external A computer system that enables a user to interact with one or more of the systems in system 100 . For example, in embodiments where the system 100 enables the presentation of the system to allow users to 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 solicits payment information. For example, the external front-end system 103 can be implemented as a computer or computer running software, such as Apache HTTP server, Microsoft Internet Information Services (IIS), NGINX or the like. In other embodiments, the external front-end system 103 may operate and be designed to receive and process requests from external devices (e.g., mobile device 102A or computer 102B), obtain information from databases and other data repositories based on those requests, and Custom web server software that provides responses to received requests based on the captured information.

In some embodiments, the external front-end system 103 may include one or more of a web cache system, a database, a search system, or a payment system. In one aspect, external front-end system 103 may include one or more of these systems, while in another aspect, external front-end system 103 may include an interface to one or more of these systems (e.g. , server-to-server, database-to-database, or other network connections).

The exemplary set of steps illustrated by FIGS. 1B , 1C, 1D and 1E will help describe some operations of the external front-end system 103 . External front-end system 103 may receive information from systems or devices in 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) (eg, FIG. 1B ), a single detail page (SDP) (eg, FIG. 1C ), a shopping cart page ( eg, FIG. 1D ), or an order page (eg, FIG. 1E ). A user device (eg, using mobile device 102A or computer 102B) can navigate to external front-end system 103 and request a search by entering information into a search box. The external front-end system 103 can request information from one or more systems in the system 100 . For example, external front-end system 103 may request information from FO system 113 to satisfy a search request. External front-end system 103 may also request and receive (from FO system 113 ) a promised delivery date or "PDD" for each product included in the search results. In some embodiments, a PDD may indicate when a package containing a product will arrive at the user's desired location or promise to deliver the product if ordered within a specified time period (e.g., by end of day (11:59 pm)) An estimate of the date to the user's desired location. (PDD is discussed further below with respect to FO system 113.)

The external front-end system 103 can prepare the SRP based on the information (eg, FIG. 1B ). The SRP may contain information that satisfies the search request. For example, this could include images of products that meet the search requirements. The SRP may also contain individual prices for each product, or information related to each product's enhanced delivery options, PDD, weight, size, offers, discounts, or the like. The external front-end system 103 may send the SRP (eg, via a network) to the requesting user device.

The user device may then select a product represented on the SRP, such as by clicking or tapping a user interface or selecting a product from the SRP using another input device. The user device may formulate a request for information about the selected product and send it to the external front-end system 103 . In response, the external front-end system 103 may request information related to the selected product. For example, the information may include additional information beyond that presented for the products on the respective SRP. This may include, for example, shelf life, country of origin, weight, size, number of items in the package, disposal instructions, or other information about the product. Information may also include recommendations of similar products (based on, for example, extensive data and/or machine learning analysis of customers who purchased this product and at least one other product), answers to frequently asked questions, reviews from customers, manufacturer information, images or the like.

The external front-end system 103 can prepare an SDP (Single Detail Page) (eg, FIG. 1C ) based on the received product information. The SDP may also contain other interactive elements, such as a "Buy Now" button, an "Add to Cart" button, a quantity bar, an image of an item, or the like. The SDP may further contain a list of vendors offering the product. The list can be sorted based on the price offered by each seller, so that the seller offering the product at the lowest price can be listed at the top. The listing may also be sorted based on seller rank such that the highest ranked sellers may be listed at the top. Seller rankings may be developed based on a number of factors including, for example, the seller's past track record of meeting commitment PDD. The external front-end system 103 may deliver the SDP (eg, via a network) to the requesting user device.

Requests that the user's device can receive an SDP listing product information. After receiving the SDP, the user device can then interact with the SDP. For example, a user requesting a user device may click or otherwise interact with a "Put in Cart" button on the SDP. This adds the product to the cart associated with the user. The user device may transmit this request to add the product to the shopping cart to the external front-end system 103 .

The external front-end system 103 can generate a shopping cart page (eg, FIG. 1D ). In some embodiments, the shopping cart page lists products that the user has added to a virtual "shopping cart." A user device may request a shopping cart page by clicking on or otherwise interacting with an icon on an SRP, SDP, or other page. In some embodiments, the shopping cart page may list all products that the user has added to the shopping cart, as well as information about the products in the shopping cart (such as the quantity of each product, the price per item of each product, the The price of the product based on the associated quantity), information about the PDD, delivery method, shipping cost, user interface elements for modifying the product in the shopping cart (for example, to delete or modify the quantity), for ordering other products or setting the product of Options for recurring delivery, options for setting interest payments, user interface elements for advancing to purchases, or the like. A user at a user device may tap on or otherwise interact with a user interface element (e.g., a button that says "Buy Now") to initiate a purchase of products in a shopping cart Buy. After doing so, the user device may transmit this request to initiate a purchase to the external front-end system 103 .

External front-end system 103 may generate an order page (eg, FIG. 1E ) in response to receiving a request to initiate a purchase. In some embodiments, the order page relists items from the shopping cart and requires entry of payment and shipping information. For example, an order page may include a request for information about the buyer (e.g., name, address, email address, phone number), information about the recipient (e.g., name, address, phone number, delivery information), shipping information (e.g., speed/method of delivery and/or picking), payment information (e.g., credit card, bank transfer, check, stored credits), requests for cash receipt (e.g., for tax purposes ), or similar. The external front-end system 103 can send the order page to the user device.

The user device can enter information about the order page and click or otherwise interact with user interface elements that send the information to the external front-end system 103 . From here, the external front-end system 103 can send information to different systems in the system 100 to enable the creation and processing of new orders with the products in the shopping cart.

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

In some embodiments, internal front-end system 105 may be implemented to enable internal users (e.g., employees of the organization that owns, operates, or leases system 100) to A computer system that interacts with one or more of the systems in system 100 . For example, in embodiments where system 100 enables the presentation of the system to allow users to place orders for items, internal front-end system 105 may be implemented to enable internal users to view diagnostic and statistical information about orders, modify item information, or review Web server for order-related statistics. For example, the internal front-end system 105 may be implemented as a computer or computer-running software, such as Apache HTTP Server, Microsoft Internet Information Services (IIS), NGINX, or the like. In other embodiments, the internal front-end system 105 may operate and be designed to receive and process requests from the systems or devices depicted in the system 100 (and other devices not depicted), based on those requests from databases and other data stores The library obtains information, and based on the obtained information, provides a response to the custom web server software of the received request.

In some embodiments, the internal front-end system 105 may include one or more of a web caching system, a database, a search system, a payment system, an analysis system, an order monitoring system, or the like. In one aspect, the internal front-end system 105 may include one or more of these systems, while in another aspect the internal front-end system 105 may include an interface to one or more of these systems (e.g. , server-to-server, database-to-database, or other network connections).

In some embodiments, the transport system 107 can be implemented as a computer system that enables communication between the systems or devices in the system 100 and the mobile devices 107A to 107C. In some embodiments, the transportation system 107 can receive information from one or more mobile devices 107A to 107C (eg, mobile phones, smartphones, PDAs, or the like). For example, in some embodiments, nomadic device 107A-107C may comprise a device operated by a delivery worker. A delivery worker (which may be a permanent employee, a temporary employee, or a shift employee) may utilize the mobile device 107A to the mobile device 107C to effectuate the delivery of the package containing the products ordered by the user. For example, to deliver a package, a delivery worker may receive a notification on a mobile device indicating which package to deliver and where to deliver the package. After arriving at the delivery location, the delivery worker can locate the package (e.g., in the back of a truck or in the package's crate), use a mobile device to scan, or otherwise capture an identifier (e.g., a barcode) on the package. , image, text string, RFID tag, or the like), and deliver the package (e.g., by leaving it at the front door, leaving it with a guard, handing it over to the recipient, or the like) . In some embodiments, the delivery worker can use the mobile device to capture a photo of the package and/or can obtain a signature. The mobile device can send information to the transportation system 107, the information including information about the delivery including, for example, time, date, GPS location, photo, identifier associated with the delivery worker, identifier associated with the mobile device, or similar. Transportation system 107 may store this information in a database (not depicted) for access by other systems in system 100 . In some embodiments, shipping system 107 may use this information to prepare and send tracking data to other systems, indicating the location of a particular package.

In some embodiments, certain users may use one type of mobile device (for example, a permanent worker may use a dedicated PDA with custom hardware such as barcode scanners, stylus, and other devices), while others use workers may use other types of mobile devices (e.g. casual or shift workers may utilize off-the-shelf mobile phones and/or smartphones).

In some embodiments, the transport system 107 can associate a user with each device. For example, the transport system 107 may store users (represented by, for example, user identifiers, employee identifiers, or phone numbers) and mobile devices (represented by, for example, international Mobile Equipment Identity (International Mobile Equipment Identity; IMEI), International Mobile Subscription Identifier (IMSI), phone number, Universal Unique Identifier (UUID) or Globally Unique Identifier (Globally Unique Identifier) ; GUID) represents the association between). The transport system 107 may use this association in conjunction with data received at the time of delivery to analyze data stored in a database to determine, inter alia, the location of the worker, the efficiency of the worker, or the speed of the worker.

In some embodiments, vendor portal 109 may be implemented as a computer system that enables a vendor or other external entity to communicate electronically with one or more systems in system 100 . For example, a seller may utilize a computer system (not depicted) to upload or provide product information, order information, contact information, or the like for products that the seller wishes to sell through the system 100 using the seller portal 109 .

In some embodiments, shipping and order tracking system 111 may be implemented as a computer system that receives, stores, and forwards information regarding the location of packages containing products ordered by customers (e.g., by users using devices 102A through 102B) . In some embodiments, the shipping and order tracking system 111 may request or store information from a web server (not depicted) operated by the shipping company delivering the package containing the product ordered by the customer.

In some embodiments, shipping and order tracking system 111 may request and store information from the systems depicted in system 100 . For example, shipping and order tracking system 111 may request information from shipping system 107 . As discussed above, the transportation system 107 can be from one or more mobile devices 107A associated with one or more of users (e.g., delivery workers) or vehicles (e.g., delivery trucks) to a mobile device 107C (e.g., , mobile phone, smartphone, PDA or similar) Receive information. In some embodiments, shipping and order tracking system 111 may also request information from warehouse management system (WMS) 119 to determine the location of individual products within a fulfillment center (eg, fulfillment center 200 ). Shipping and order tracking system 111 may request data from one or more of shipping system 107 or WMS 119, process the data upon request, and present the data to devices (e.g., user device 102A and user device 102B).

In some embodiments, fulfillment optimization (FO) system 113 may be implemented as a computer system that stores information on customer orders from other systems (eg, external front-end system 103 and/or shipping and order tracking system 111 ). The FO system 113 may also store information describing where a particular object is kept or stored. For example, certain items may be stored in only one fulfillment center, while certain other items may be stored in multiple fulfillment centers. In still other embodiments, certain fulfillment centers may be designed to stock only certain sets of items (eg, fresh produce or frozen products). The FO system 113 stores this information as well as associated information (eg, quantity, size, date received, date of expiration, etc.).

The FO system 113 can also calculate a corresponding promised delivery date (PDD) for each product. In some embodiments, PDD may be based on one or more factors. For example, the FO system 113 may calculate the PDD for a product based on past demand for the product (e.g., how many times the product was ordered over a period of time), expected demand for the product (e.g., predicted how many customers will order the product during an upcoming period), network-wide past demand indicating how many products have been ordered over a period of time, network-wide expected demand indicating how many products are expected to be ordered during an upcoming period of time, One or more counts of products stored in each fulfillment center 200, which fulfillment center stores each product, the product's expected period or current order or similar.

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

In some embodiments, Fulfillment Message Gateway (FMG) 115 may be implemented to receive a request or response in one format or protocol from one or more systems in system 100, such as FO system 113, convert it to another a format or protocol and forwards it in the converted format or protocol to other systems such as WMS 119 or third party fulfillment system 121A, third party fulfillment system 121B or third party fulfillment system 121C and vice versa.

In some embodiments, supply chain management (SCM) system 117 may be implemented as a computer system that performs forecasting functions. For example, the SCM system 117 may predict the level of demand for a particular product based on, for example, past demand for the product, expected demand for the product, network-wide past demand, network-wide expected demand, stored in each Count products in a fulfillment center 200, expected or current orders for each product, or the like. In response to this forecast level and the volume of each product in all fulfillment centers, the SCM system 117 can generate one or more purchase orders to purchase and stock sufficient quantities to meet the forecasted demand for a particular product.

In some embodiments, warehouse management system (WMS) 119 may be implemented as a computer system that monitors workflow. For example, WMS 119 may receive indications from individual devices (eg, device 107A-device 107C or device 119A-device 119C) Event data for discrete events. For example, WMS 119 may receive event data indicative of the use of one of these devices to scan a package. As discussed below with respect to fulfillment center 200 and FIG. 2 , during the fulfillment process, certain stages may be accessed by machines (e.g., automated or hand-held barcode scanners, RFID readers, high-speed cameras, such as tablet computers 119A). , mobile device/PDA 119B, computer 119C, or the like) scans or reads the package identifier (eg, barcode or RFID tag data). WMS 119 may store each event indicative of a scan or read of a package identifier along with the package identifier, time, date, location, user identifier, or other information in a corresponding database (not depicted), and may store this Information is provided to other systems (eg, shipping and order tracking system 111).

In some embodiments, WMS 119 may store information that enables one or more devices (e.g., device 107A-device 107C or device 119A-device 119C) and one or more users (the one or more users and system 100 Associated) Associated information. For example, in some cases, a user (such as a part-time or full-time employee) may be associated with a mobile device because the user owns the mobile device (eg, the mobile device is a smartphone). In other cases, a user may be associated with a mobile device due to the user taking temporary custody of the mobile device (e.g., the user gets the mobile device at the beginning of the day, will use the mobile device during the day, and will return said mobile device at the end of the day).

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 specified process (e.g., unload from truck, pick item from pick area, rebin wall work, pack item), use operator identifier, location (e.g., floor or zone in fulfillment center 200), by employee via The number of units moved by the system (eg, number of items picked, number of items packed), identifiers associated with devices (eg, devices 119A-119C), or the like. In some embodiments, WMS 119 may receive log-in and log-out information from a timekeeping system, such as a timekeeping system operating on devices 119A-119C.

In some embodiments, 3rd party fulfillment (3PL) systems 121A-121C represent computer systems associated with third party providers of logistics and products. For example, while some products are stored in fulfillment center 200 (as discussed below with respect to FIG. 2 ), other products may be stored off-site, made on demand, or otherwise unavailable for storage in fulfillment center 200. . 3PL systems 121A-121C may be configured to receive orders from FO system 113 (eg, via FMG 115 ) and may provide products and/or services (eg, delivery or installation) directly to customers. In some embodiments, one or more of 3PL systems 121A through 121C may be part of system 100, while in other embodiments one or more of 3PL systems 121A through 121C may be part of system 100 External (for example, owned or operated by a third party provider).

In some embodiments, the fulfillment center Auth system (FC Auth) 123 may be implemented as a computer system with various functions. For example, in some embodiments, FC Auth 123 may serve as a single-sign-on (SSO) service for one or more other systems in 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 log in without requiring a second log-in process. access to those privileges. In other embodiments, FC Auth 123 may enable users (e.g., employees) to associate themselves with specific tasks Associated. For example, some employees may not have electronic devices (such as devices 119A-119C), and may actually move within fulfillment center 200 from task to task and from zone to zone during the course of a day. FC Auth 123 can be configured to enable their employees to indicate what tasks they are doing and what zone they are located at different times of the day.

In some embodiments, labor 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, LMS 125 may receive information from FC Auth 123, WMA 119, device 119A-119C, transportation system 107, and/or device 107A-107C.

The particular configuration depicted in Figure 1A is an example only. For example, although FIG. 1A depicts FC Auth system 123 connected to FO system 113 , not all embodiments require this particular configuration. In fact, in some embodiments, the systems in system 100 may be connected to each other via one or more public or private networks, including the Internet, intranets, wide-area networks (Wide-Area Networks) ; WAN), metropolitan-area network (Metropolitan-Area Network; MAN), wireless network conforming to IEEE 802.11a/b/g/n standards, leased lines or the like. In some embodiments, one or more of the systems in system 100 may be implemented as one or more virtual servers implemented at a data center, server farm, or the like.

FIG. 2 depicts a fulfillment center 200 . Fulfillment center 200 is an example of a physical location that stores items for shipment to customers when ordered. Fulfillment center (FC) 200 may be divided into multiple zones, each of which is depicted in FIG. 2 . In some embodiments, these "zones" can be thought of as virtual divisions between the different stages of the process of receiving, storing, retrieving, and shipping items. Therefore, although in Figure 2 "Region" is depicted, but other divisions are possible, and in some embodiments the regions in Figure 2 may be omitted, duplicated, or modified.

Inbound area 203 represents the area of FC 200 that receives items from sellers who wish to sell products using system 100 (FIG. 1A). For example, a seller may use truck 201 to deliver item 202A and item 202B. Item 202A may represent a single item large enough to occupy its own shipping pallet, while item 202B may represent a collection of items stacked together on the same pallet to save space.

Workers will receive items in the inbound area 203 and may use a computer system (not shown) to check the items for damage and correctness as appropriate. For example, a worker may use a computer system to compare the quantities of items 202A and 202B with the ordered quantities of the items. If the quantities do not match, the worker may reject one or more of item 202A or item 202B. If the quantities do match, a worker can move the items to the buffer zone 205 (using, for example, a dolly, dolly, forklift, or manually). The buffer zone 205 may be a temporary storage area for items that do not currently need to be in the picking area (eg, due to the presence of a sufficiently high number of items in the picking area to meet forecasted demand). In some embodiments, forklifts 206 operate to move items around buffer zone 205 and between inbound area 203 and drop area 207 . If item 202A or item 202B in the pick area is needed (eg, due to forecasted demand), a forklift may move item 202A or item 202B to unload area 207 .

The unloading area 207 may be an area of the FC 200 where items are stored prior to moving them to the picking area 209 . A worker ("picker") assigned to a picking task may approach item 202A and item 202B in the picking area, use a mobile device (e.g., device 119B) to scan the barcode of the picking area, and scan the barcode associated with item 202A. and the barcode associated with item 2021B. The picker can then (for example, by placing the item on the cart or carrying the item) to take the item to the picking area 209.

Picking area 209 may be an area of FC 200 where items 208 are stored on storage unit 210 . In some embodiments, storage units 210 may include one or more of physical shelves, bookshelves, boxes, totes, refrigerators, freezers, cold storage areas, or the like. In some embodiments, picking area 209 may be organized into multiple floors. In some embodiments, workers or machines can move items into the picking area 209 in multiple ways, including, for example, forklifts, elevators, conveyor belts, carts, dollies, dollies, automated robots or devices, or manually . For example, the picker can place the items 202A and 202B on a trolley or cart in the unloading area 207 and walk the items 202A and 202B to the picking area 209 .

Pickers may receive instructions to place (or “stack”) items at specific points in picking area 209 , such as specific spaces on storage units 210 . For example, a picker may use a mobile device (eg, device 119B) to scan item 202A. The device may indicate where the picker should stack the item 202A, for example using a system of indicating aisles, shelves, and locations. The device may then prompt the picker to scan the barcode at the location before stacking the item 202A at the location. The device may send data (eg, via a wireless network) to a computer system, such as WMS 119 in FIG. 1A , indicating that object 202A has been stowed at the location by a user using device 119B.

Once a user places an order, a picker may receive an instruction on device 119B to retrieve one or more items 208 from storage unit 210 . A picker may retrieve an item 208 , scan a barcode on the item 208 , and place the item 208 on the transport mechanism 214 . Although the transport mechanism 214 is shown as a slide, in some embodiments the transport mechanism may be implemented as a conveyor belt, elevator, cart, forklift, trolley, trolley, One or more of a cart or the like. Items 208 may then arrive at packing area 211 .

Packing area 211 may be an area of FC 200 that receives items from pick area 209 and packs the items into boxes or bags for eventual shipment to customers. In packing area 211, workers assigned to receive items ("merge workers") will receive items 208 from picking area 209 and determine which order the items correspond to. For example, a merge worker may use a device such as computer 119C to scan a barcode on item 208 . Computer 119C may visually indicate which order item 208 is associated with. This may include, for example, a space or "cell" on wall 216 that corresponds to an order. Once an order is complete (eg, because a cell contains all the items for said order), the merge worker can instruct a pack worker (or "packer") that the order is complete. A packer can retrieve items from a cell and place the items in a box or bag for shipping. The packer may then send the box or pack to hub zone 213, eg, via forklift, cart, dolly, dolly, conveyor belt, manually, or otherwise.

Transit area 213 may be the area of FC 200 that receives all boxes or packages (“packages”) from packing area 211 . Workers and/or machines in hub zone 213 can retrieve packages 218 and determine which part of the delivery zone each package is intended to go to, and deliver the packages to the appropriate camp zone 215 . For example, if a delivery area has two smaller sub-areas, the package will go to one of the two camp areas 215 . In some embodiments, a worker or machine may scan the package (eg, using one of devices 119A-119C) to determine its final destination. Routing the package to a camp area 215 may include, for example (eg, based on a zip code) determining a portion of a geographic area to which the package is going, and determining a camp area 215 associated with that portion of the geographic area.

In some embodiments, camp area 215 may include one or more buildings, one or more physical spaces, or one or more areas in which packages are received from hub area 213 for sorting into routes and/or sub-routes. In some embodiments, the camp area 215 is physically separate from the FC 200 , while in other embodiments the camp area 215 may form part of the FC 200 .

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 to existing routes and/or sub-routes, for each Calculation of workload for routes and/or sub-routes, time of day, shipping method, cost of shipping package 220, PDD associated with items in package 220, or the like. In some embodiments, a worker or machine may scan the package (eg, using one of devices 119A-119C) to determine its final destination. Once a package 220 is assigned to a particular route and/or sub-route, workers and/or machines may move the package 220 for delivery. In exemplary FIG. 2 , camp area 215 includes trucks 222 , cars 226 , and delivery workers 224A and 224B. In some embodiments, truck 222 may be driven by delivery worker 224A, where delivery worker 224A 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, car 226 may be driven by delivery worker 224B, where delivery worker 224B is a "flexible" worker or temporary worker who delivers on an as-needed basis (eg, seasonally). Car 226 may be owned, leased or operated by delivery worker 224B.

3 is a schematic block diagram illustrating an exemplary embodiment of a networked environment 300 including a computerized system for managing incoming requests and data package assignments, consistent with disclosed embodiments. Networked environment 300 may include various computerized systems, each of which may be connected to each other via one or more networks. In some embodiments, each of the elements depicted in FIG. 3 may represent a system group, a system network, individual systems, functional units or modules within a system, or any combination thereof. And in some embodiments, each of the elements may communicate with each other via one or more public or private network connections, including the Internet, an intranet, a wide area network Wide-Area Network (WAN), Metropolitan-Area Network (MAN), wireless network conforming to IEEE 802.11a/b/g/n standards, wired network, or the like. Individual systems may also be located within one geographic location or be geographically dispersed.

In some embodiments, the depicted system includes one or more data generation systems 310 , and one or more client devices 320 , and a data packet management server 330 . Although only three client devices are depicted in FIG. 3 , the number is exemplary only and any other number of client devices may be configured to interface with the packet management server 330 . Furthermore, the depicted system is exemplary only and the features described herein may be adapted by any system configured to accept incoming requests for certain groups of data, where groups of data may be generated without relative to Individual requirements for specific needs.

Furthermore, each of the systems depicted in FIG. 3 can take the form of a server, a general-purpose computer, a mainframe computer, a special-purpose computing device such as a graphical processing unit (GPU), a laptop, or any combination of such computing devices. combined form. In other embodiments, each system or subset of systems may be implemented as one or more functional units of a single system. Additionally or alternatively, each system or subset thereof may be an independent system, or part of a subsystem, which may be part of a larger system.

In some embodiments, the data production system 310 may be any computerized system or group of computerized systems configured to generate or store data elements that can be combined to form data packages designated for use as described below. The incoming in the process to beg. For example, data generation system 310 may be its own server, another computerized system, or another database.

As used herein, a data element may refer to a collection of data values, relationships among them, and/or functions or operations applicable to the data values. For example, a data element may take the form of an array, linked list, record, union, tagged union, graph, tree, or any other object type or collection of objects. Furthermore, a data package may refer to a collection of data elements and may take the form of any computer-readable data organization, management, and storage format that enables efficient access and modification. In some embodiments a data packet may contain a single type of data element, in other embodiments a data packet may contain more than one type of data element. In further embodiments, a data package may also include relationships among the data elements it contains and/or functions or operations applicable to the data elements.

Data elements generated by or stored in data generation system 310 may include, for example, individual tasks or assignments performed by workers. These individual tasks or assignments can be combined to form a package representing a batch of tasks or assignments that workers can perform in batches. In another example, a data element may include orders from customers, each of which includes one or more products. The data packages formed from these data elements may each contain one or more products from any combination of orders reassembled by the algorithm for fast and efficient picking.

In some embodiments, client device 320 may include any number of computing devices configured to generate specified requests—requests for data packets—in response to user input. More specifically, each client device can be configured to send data and/or metadata associated with specified requests and any specified packets to and from the packet management server 330 330 Receive data and/or metadata associated with the specified request and any specified data packages. Client device 320 may take the form of any internet-enabled computing device, such as a personal computer, mobile phone, smartphone, PDA, tablet computer, laptop computer, pocket computing device, smart television, and the like. In another embodiment, the client device 320 may include one or more displays for displaying a user interface (UI). The UI can be configured to allow a user to interact with the client device to generate specified requests and/or to display the contents of specified packets. Additionally or alternatively, the UI may be configured to display other data (such as error messages or notifications) corresponding to the received specified request.

In some embodiments, the data package management server 330 can be implemented as a computer system that receives specified requests from the client device 320 and receives data elements from the data generation system 310, and combines the specified requests with the specified data package Return to the respective client device 320 together. In some embodiments, the packet management server 330 may include a frontend server 331 , a backend server 332 , a request pool 333 and a packet pool 334 .

Packet management server 330 may take the form of a server, a general-purpose computer, a mainframe computer, a special-purpose computing device such as a graphics processing unit (GPU), a laptop, a smartphone, a mobile device, or any combination of these computing devices. form. Packet management server 330 may be a stand-alone system, or it may be part of a subsystem, which may be part of a larger system. In these embodiments, the components of the packet management server 330 (i.e., the front-end server 331, the back-end server 332, the request pool 333, and the packet pool 334) may be implemented based on storage in one or more memories The instructions in are from one or more functional units executed by one or more processors. Alternatively, any or all components of packet management server 330 may be implemented as one or more computer systems interconnected via a network, where each computer system may take the form of a server, communication In the form of computers, mainframe computers, special purpose computing devices such as graphics processing units (GPUs), laptops, smartphones, mobile devices, or any combination of these computing devices.

In some embodiments, the front-end server 331 can be implemented as a computer system or a functional unit that interfaces the client device 320 with the packet management server 330 . More specifically, front-end server 331 may be configured to receive designation requests from client devices 320, relay them to back-end server 332 for processing, and return received processed designations from back-end server 332. request, and based on the result of the processing, the processed specified request is transmitted back to the respective client device 320 along with additional data. In some embodiments, the front-end server 331 can be implemented as a computer or computer running software, such as Apache HTTP server, Microsoft Internet Information Services (IIS), NGINX or the like.

In some embodiments, the backend server 332 may be implemented as a computer system or functional unit that receives data elements from the data generation system 310 and receives specified requests from the frontend server 331, as follows with respect to FIG. 4 The described approach uses the request pool 333 and the packet pool 334 to process them, and returns the processed specific requests to the front-end server 332 for redistribution to respective client devices 320 . Processing specified requests and data elements in the manner disclosed herein may allow packet management server 330 to handle an overwhelming number of specified requests and/or data elements while minimizing the number of failed or rejected requests and overall reduced system failures risks of.

In some embodiments, request pool 333 and packet pool 334 may include one or more databases or memories configured to temporarily store specific requests, respectively, before packets are assigned to specific requests and data packs. Request Pool 333 and data package pool 334 may each be implemented as a cloud-based repository and/or an on-premises repository. In some embodiments, the request pool 333 and the packet pool 334 may include a combination of non-transitory storage media such as hard disk drives, solid state drives, RAM, ROM, or flash memory.

Request pool 333 and packet pool 334 may store specified requests and packets in a queue, sequence, stack, or any other data structure configured to retain data for a certain amount of time. In some embodiments, stacks, sequences, or queues including buffers may follow a First In First Out (FIFO) method, where the first data added to a respective pool is first output to the backend server 332 for for processing. In another embodiment, the request pool 333 and the packet pool 334 can also be configured to store the specified request and packet series indefinitely as a backup for data recovery or record keeping purposes.

FIG. 4 is a flowchart of an exemplary computerized process 400 for managing incoming requests and data package assignments, consistent with disclosed embodiments. Process 400 may be practiced on any server that is at risk of being overwhelmed by a large number of incoming requests. Such servers may include networked systems such as those described above in FIG. 3 . Process 400 is described below with reference to the networked system of FIG. 3 , but any other configuration of systems, subsystems, or modules may be used to perform process 400 .

In some embodiments, process 400 may begin at step 401 by a user interacting with a UI displayed on client device 320 . The user may, for example, specify certain parameters specifying requirements, such as the number or amount of packets, the location of the user or client device 320, the type of user, any authorizations or restrictions the user has, or to help determine the any other parameters of the appropriate package for the user). Alternatively, the user may simply press a UI element (eg, a button) to initiate process 400 .

At step 402, the client device 320 may base on the above step 401 Generate and transmit specified requests based on user input received at Such transmission may occur over any of the network protocols described above, such as wired, wireless or cellular networks. In some embodiments, the client device 320 may update the UI to display a waiting screen UI until receiving a specific request for processing from the packet management server 330 .

At step 403 , the front-end server 331 of the packet management server 330 may receive the designated request and relay the designated request to the back-end server 332 . In some embodiments, before relaying the specified request to the backend server 332, the front-end server 331 may pre-process the specified request to add a priority parameter indicating a second or consecutive attempt of the specified request from a particular client device. The priority parameter may prompt the backend server 332 to prioritize a given request before other given requests by, for example, adding it to the front of the queue in the request pool 333 .

In such embodiments, the front-end server 331 may recognize or identify successive attempts of certain specified requests based on data contained in the specified requests themselves or metadata accompanying the specified requests. More specifically, the specified requirements may include parameters indicating that the requirements are continuous requirements generated in response to previous failure requirements as described at step 413 below. Additionally or alternatively, front-end server 331 may be configured to keep a record of specified requests that correspond to identifying information of client device 320 (e.g., MAC address, IP address, usage of client device 320 identifier or the like) is received by the backend server 332, which can use the client device 320 to find out whether the metadata for a given request contains an identifier corresponding to the client device most recently added to the record Information.

At step 404 , the backend server 332 may receive the specified request from the frontend server 331 and add the specified request to the request pool 333 . Specified requirements can be added To the end of the queue in request pool 333, that is, later than any specified request previously received from front-end server 331 and still pending processing. In some embodiments, backend server 332 may be configured to recognize a priority parameter for a given request and add the corresponding given request to the front of the queue in request pool 333 so that it can be processed before other requests. In another embodiment, at step 408, under certain circumstances (such as when the backend server 332 retrieves pending specified requests as described below with respect to step 407 and no more specified requests remain in the request pool 333 Sometimes), the backend server 332 can directly add the received specified request to the specified request group of the specified available data package.

At step 405 , separate from steps 401 to 404 described above, the backend server 332 may generate a data packet by retrieving data elements from the data generation system 310 . Generating data packets may involve various algorithms depending on the application of the disclosed embodiments. For example, in some embodiments, the backend server 332 may be configured to perform the tasks associated with each data element by location, type of client device 320 that can display the data elements, or the like) group the data elements to generate a data package. In further embodiments, the backend server 332 may be configured to break down data elements into smaller components and generate data packets by grouping the components based on criteria such as those described above. Still further, the backend server 332 can be configured to add a priority parameter to any data packet based on the information of the accompanying data element to indicate that the corresponding data packet should be stored in the data packet pool 334 before another data packet Previously assigned to received designation requests.

At step 406 , the backend server 332 may add the data packets generated at step 405 above to the data packet pool 334 . Packets can be added to the pack pool 334 The end of the queue in , that is, packets later than any previously generated and still waiting to be assigned to a given request. In some embodiments, the backend server 332 can be configured to recognize the priority parameter of a packet and add the corresponding packet to the front of the queue in the packet pool 334 so that it can precede other packets deal with. In another embodiment, at step 408, under certain circumstances (such as when the backend server 332 retrieves a pending packet as described below with respect to step 407 and no more packets remain in the packet pool 334 In the middle), the backend server 332 can directly add the latest generated data package to the data package group assigned to the specified request.

In some embodiments, steps 401 to 404 and steps 405 to 406 may occur independently of each other and asynchronously, such that specific requests and data packages are accumulated in their respective pools whether adding new specific requirements or adding data packages. This asynchronous processing of data packets and specified requests may allow the backend server 332 to maintain a reservation of data packets when there is a higher supply of data elements from the data production system 310 than the demand for the specified request from the client device 320 , the package may be assigned to an incoming specified requirement on demand, or maintain a reservation for specified requirements, which may be used when generating a package when there is demand from specified requirements that is higher than the supply of the data element information pack. The data packet management server 330 may thus be equipped to accommodate given requirements and fluctuation levels of data elements.

At step 407, the backend server 332 can retrieve the pending specified requests and available packets stored in the request pool 333 or the packet pool 334, respectively. The backend server 332 can retrieve multiple specified requests and multiple data packets at one time for batch processing at step 408 below. In some embodiments, the number of data packages retrieved may be a multiple of the specified required number retrieved or vice versa. In other embodiments, the number of packets and specified requests may be equal to each other, or the backend server 332 All packages and specific requests held in respective pools can be retrieved. In some embodiments, retrieval specific requests and data packages may remove them from their respective pools. For record-keeping purposes, copies of removed Designated Requirements or Packages may be backed up to other non-transitory computer-readable media.

Retrieving and processing multiple specified requests at once may allow faster processing compared to conventional methods of processing one specified request at a time in a linear fashion, along with minimizing the time and resources required to access the respective pools and retrieve the corresponding data. This reduction may also improve the scalability of the packet management server 330, allowing the packet management server 330 to handle even larger numbers of specified requests and data elements.

At step 408, the backend server 332 may process the retrieved assignment request by attempting to assign the retrieved data packet to the assignment request. As used herein, assigning a packet to a specified request may refer to attaching the packet to the specified request, causing the packet to be transmitted to the client device 320 that generated the specified request, or associating the packet with the specified request (e.g., by Add the identifier of the individual package to the specified request). Assignment can occur using any number of different schemes suitable for assigning numbers of one data type to another data type. For example, the backend server 332 may assign a data packet to a specific request in a 1:1 correspondence, only by storing each data type in the corresponding pool sequentially. Alternatively, the backend server 332 may assign multiple packets to a given request or vice versa in an X:1 correspondence.

Still further, the backend server 332 may assign data packets to certain specific requirements based on specific requirements or parameters specified in the data packets. For example, the backend server 332 may assign data packets associated with a particular physical location to specific requests received from client devices 320 located at the particular physical location. Additionally or alternatively, the backend server 332 may assign packets of certain tasks to authorization to perform such tasks. tasks or specified requirements that are not restricted from performing such tasks. As another example, the backend server 332 may assign a packet with a priority parameter to a request that also has a priority parameter or to a request that indicates that the corresponding user is authorized to receive the prioritized packet.

Once the backend server 332 has completed processing all retrieved assignment requests by successfully assigning the retrieved data packets to the assignment request or attempting assignment, but failing for some or all assignment requests, with or without any assignment requests In the case of a specified data packet, the backend server 332 can relay the processed specified request back to the frontend server 331 . In some embodiments, all retrieved specific requests at step 407 above may be relayed to the front-end server 331 even if the back-end server 332 fails to designate at least one packet to the specific request. An assigned request relayed to the front-end server 331 without any packets may contain an error code or error message corresponding to the reason why the backend server 332 failed to assign any packets. Reasons may include, for example, a lack of any packets meeting the parameters specified by the specified requirements, insufficient number of packets available, temporary inability to specify a portion of the backend server 332, or the like. Error codes may include, for example, any sequence of alphanumeric characters with a look-up table storing the meaning of each error code.

Additionally or alternatively, the backend server may return any remaining packets to the packet pool 334 not assigned to any specified request. Returned packets may be added to the front of the queue in packet pool 334 in a manner similar to the addition of prioritized packets above. Reasons for not assigning an assignment may include, for example, a lack of any assignment that satisfies the parameters specified by the data package, insufficient number of assignments available, temporary inability to assign a portion of the backend server 332, or the like.

At step 409, the front-end server 331 may receive from the back-end server 332 Receives the specified request for processing and the specified packet or error code or message. At this point, the front-end server 331 may determine the processed specified request together with the specified data packet as successful, and transmit the specified request and the data packet back to the corresponding client device 320 that initiated each processed specified request.

Alternatively, at step 410, the front-end server 331 may determine that the processed specified request does not have any specified data packets or has an error code or message as unsuccessful, and the processed specified request and the accompanying An error code or message is transmitted back to the corresponding client device 320 that originated the specified request that was processed. In some embodiments where an error code or message from backend server 332 contains a detailed description of the cause for internal diagnostics and communications, frontend server 331 may replace the error code from backend server 331 with another error code appropriate for external communications. Error code or message of device 331. New error codes, for example, may include a smaller number of possible codes or reduce the level of detail contained therein.

At step 412 , client device 320 may receive the processed specified request corresponding to the specified request originally transmitted at step 402 . If the received specified request includes the specified data package, the client device 320 may determine that the specified request is successful and proceed to step 412 . In addition, if the specified request does not contain any data packet or contains an error code, the client device 320 may determine that the specified request has failed and proceed to step 413 .

At step 412, the client device 320 may modify the UI that has displayed the waiting screen UI since step 402 to display another UI in response to the content of the specified packet. For example, client device 320 may decompose the data package into its components and perform actions corresponding to the components, such as displaying the components, using the components to perform other tasks, or the like.

At step 413, the client device 320 may retransmit the specified request to the packet management server 330, so that the specified request goes through step 403 to step 411 again. The client device 320 may continue to display the waiting screen UI or update the UI to indicate that the client device 320 is retrying the specified request. In some embodiments, client device 320 may attempt the second attempt after some delay determined based on the error code.

For example, if the error code indicates that the packet management server 330 failed to specify any packets due to insufficient number of packets or no packets matching the parameters of the specified request, the client device 320 may take longer The specified request is retransmitted after a delay (eg, 10 seconds), so that the data generation system 310 can have sufficient time to generate new data elements that can match the parameters of the specified request. Alternatively, if the error code indicates that the failure was due to a temporary error on the packet management server 330, the client device 320 may immediately retransmit the specified request with little to no delay (eg, 0.02 seconds to 3.00 seconds). For another error code, client device 320 may transmit the specified request after a moderate amount of delay (eg, 3 seconds to 4 seconds). Although only three delay amounts are described herein, such configurations are merely exemplary and any other combination of delay lengths and types of error codes may be implemented.

Compared to conventional systems in which the user himself has to manually initiate successive attempts, which tend to create more overload on the server, the systems and methods described herein automate the successive attempts, the system and methods allow systematic management of successive attempts and achieve a shorter delay between successive attempts. In addition, the systematic management of successive attempts eliminates contention between different client devices 320 to obtain packets, further mitigating network traffic caused by repeated attempts from users trying to obtain packets and reducing losses due to network congestion. resulting failure rate. In addition to the improved efficiency achieved by registration requirements and asynchronous pooling of packets, the shorter delay between successive attempts reduces the average length of time it takes client device 320 to receive packets.

In some embodiments, the client device 320 may retransmit the initial request returned from the packet management server 330 as a continuous request. In other embodiments, client device 320 may generate a new specified request for retransmission with or without a parameter indicating successive attempts at the new specified request. Front-end server 331 may be configured to detect whether a given request is an initial attempt or a continuation attempt in the manner described above with respect to step 403 .

Although not depicted in FIG. 4 , client device 320 and packet management server 330 may also be configured to unassign requests or to unassign packets from assigned requests being processed. A user may be able to initiate such a cancel request by entering a command into the UI of the client device 320 . For example, the wait screen UI displayed on the client device 320 at step 402 may include a UI element (eg, a button) that generates a cancel request for a previously transmitted specified request. In another embodiment, the client device 320 may also display a similar UI element that does not designate a package previously assigned to a specific request.

Once a cancel request is generated by the client device 320 in response to user input, the client device 320 may transmit the request to the packet management server 330 via the front-end server 331 , and finally to the back-end server 332 . In some embodiments, a cancellation request may include information identifying an earlier assignment request that the user wishes to cancel or not assign.

The backend server 332 can first determine whether an earlier specified request is currently pending in the request pool 333 or has already specified any packets, by, for example, searching the specified request queue in the request pool 333, looking for records of past specified requests, or Determines whether the cancellation request contains a package. If the backend server 332 determines that the earlier specified request is still stored in the request pool 333, the backend server 332 can delete the request from the request pool 333. Specify requirements earlier. However, if the backend server 332 determines that an earlier assignment request has already assigned any packet, the backend server 332 may not assign the packet and add it back to the packet pool 334 . In either case, the backend server 332 may return a cancel request to the client device 320 along with parameters indicating success, regardless of the status of the earlier specified request. On the other hand, if the backend server 332 cannot find an earlier specified request, it may return a cancel request to the client device 320 along with an error code indicating a failure.

An exemplary application of the disclosed embodiments is described next as applied to an order fulfillment process at a warehouse.

FIG. 5 is a diagram of an exemplary batch generation process 500 that aggregates multiple orders into batch jobs as part of the order fulfillment process. In this example, Order A 510A, Order B 510B, Order C 510C, and Order 510D may correspond to data elements generated by the data generation system 310 . The package management server 330 can be used to receive orders and generate batch jobs (e.g., batch job A 520A to batch job C 520C), which are then assigned to pickers so that the pickers can self-pick The cargo area 209 retrieves the corresponding items. As used herein, a batch job may refer to the packages described above.

In some embodiments, backend server 332 may aggregate order 510A-order 510D for breakdown into individual items and grouping into job batch A 520A, job batch B 520B, and job batch C 520C. The number of orders and batch jobs and the items shown therein are exemplary only, and the backend server 332 can aggregate any number of orders with any combination of items and distribute them into any number of batches as desired at work.

In FIG. 5, Order A 510A may include IID orders B 510B for lemonade 501 and ketchup 502 for one and three may include IIDs corresponding to shredded cheese 504 having a quantity of one. Order C 510C may include item identifiers corresponding to desktop computer 504 , toy tablet 505 , hot sauce 506 , and hot sauce 507 having quantities of one, one, three, and two, respectively. Order D 510D may include item identifiers corresponding to toy cars 508 and trucks 509 having quantities of three and one, respectively.

The backend server 332 may combine all item identifiers and groups thereof into lot jobs A 520A through lot jobs C 520C based on, for example, their respective physical locations within their pick area 209 . Grouping object identifiers may be performed in a manner similar to step 405 described above. For example, lot job A 520A may contain an item identifier corresponding to a location identifier associated with an area in pick area 209 where grocery items are stored. Similarly, Lot Job B 520B and Lot Job C 520C may contain item identifiers corresponding to location identifiers associated with areas in pick area 209 that store electronics and toys, respectively. In some embodiments where Order A 510A through Order D 510D contain items in quantities (whether by volume, weight, or number) associated with a particular area that exceed a predetermined maximum batch size, the backend server 332 may distribute the items At least one batch is working. In some embodiments, each job batch may be associated with a particular type of shopping cart and the maximum job batch size may be determined based on the size of the available types of shopping carts.

In some embodiments, the backend server 332 may further divide the object identifiers assigned to a particular batch of jobs into one or more container groups. For example, an OID assigned to job lot A 520A may be further divided into container group A 521A and container group B 521B; and an OID assigned to job lot C 520C may be divided into container group X 521X and container group Y 521Y. Alternatively, the batch All object identifiers for a job, such as batch job B 520B, may be assigned to a single container group, such as container group P 521P. In this case, each container group P may correspond to a packet as described above.

In some embodiments, the decision on whether to split an item identifier for a job batch may be based on the number of factors associated with the item corresponding to the item identifier, such as its total weight, total volume, individual shape, and the like. The backend server 332 can compare the factors to the size and/or load capacity of each container and split the object identifier when a predetermined maximum container group size is reached. For example, container group A 521A and container group B 521B may each contain the OIDs of lemonade 501 and pepper 507 ; In further embodiments where a batch of jobs is associated with an excess of objects, the backend server 332 may form a new batch of jobs and associate the excess object identifier with the new batch of jobs. New batch jobs may similarly be split into one or more container groups as described above.

Once a batch job or container group (corresponding to a data packet) is generated, the backend server 332 can also generate a batch pointer for each batch job or container group, which acts as a pointer to the corresponding batch job or container group The computer-readable address of . Backend server 332 may add a number of batch pointers to batch jobs or groups of containers to the batch job pool corresponding to the The packet pool 334 described herein.

Next, the backend server 332 may receive a plurality of batch requests corresponding to the specified requirements described above from the client device 320 via the frontend server 331 in a manner similar to steps 402 to 404 described above. As used herein, client device 320 may correspond to device 119B for use by a picker. The backend server 332 can also add multiple batch requests to the pair in a manner similar to step 404 above A request pool corresponding to the request pool 333 described above.

Additionally, the backend server 332 may retrieve groups of batch metrics and batch requests from the respective pools in a manner similar to step 407 described above, and proceed in a manner similar to step 407 described above to Assign one or more batch metrics to each batch requirement.

Jumping to where a client device 320 has received a processed batch request, each client device 320 can be configured to retrieve one or more batch jobs corresponding to the batch index assigned to the respective batch request , or if not specified, retry after a delay. The picker can then proceed to perform each batch of jobs by using the client device 320 to display the items picked and retrieved from the picking area 209 .

Order fulfillment and lot generation processes implementing the systems and methods described herein can take advantage of the advantages described above. More specifically, known systems that cause individual pickers to repeatedly transmit lot requests in order to obtain a lot of work are prone to failure during busy seasons due to the overwhelming number of requests. Pickers have no choice but to be idle until the system generates and assigns a lot of work in response to a lot request, resulting in a significant impact on overall productivity and loss of man-hours. The order fulfillment and lot generation process described above automates the transmission of lot requirements and the generation of lot jobs, enabling the FO system 113 to address overwhelming demand from pickers and/or customer orders.

The order fulfillment and lot generation processes described above are exemplary only and are not intended to limit the scope or applicability of the disclosed embodiments. Other areas of the application may include, for example, resource allocation, warehouse management, labor management, network traffic management, or any other area that can independently receive data requests from users and generate data that meets the data requirements.

Although the disclosure has been illustrated and described with reference to particular embodiments thereof, it should be understood that the disclosure may be practiced in other environments without modification. The foregoing description has been presented for purposes of illustration. The foregoing description is not exhaustive and is not limited to the precise forms or embodiments disclosed. Modifications and adaptations will be apparent to those skilled in the art from consideration of the specification and practice of the disclosed embodiments. Additionally, although aspects of the disclosed embodiments are described as being stored in memory, those of ordinary skill in the art will appreciate that such aspects can also be stored on other types of computer-readable media, such as Secondary storage such as hard disk or CD ROM, or other forms of RAM or ROM, USB media, DVD, Blu-ray, or other optical drive media.

Computer programs based on the written description and disclosed methods are within the skill of an experienced developer. Various programs or program modules can be created using any of the techniques known to those of ordinary skill in the art or can be designed in conjunction with existing software. For example, a program section or a program module may or may not be implemented with the help of .Net Framework (.Net Framework), .Net Compact Framework (.Net Compact Framework) (and related languages such as Visual Basic, C etc.), Java (Java), C++, Objective-C (Objective-C), HTML, HTML/AJAX combination, XML or HTML containing Java applets.

Additionally, although illustrative embodiments have been described herein, those having ordinary skill in the art will recognize, based on this disclosure, that there are equivalent elements, modifications, omissions, combinations (eg, aspects of various embodiments) The scope of any and all embodiments to be combined, adapted and/or altered. The limitations in the claims should be interpreted broadly based on the language employed in the claims and not limited to the examples described in this specification or during the prosecution of this application. Instances should be considered non-exclusive of. In addition, the steps of the disclosed methods may include modification in any manner by reordering the steps and/or inserting or deleting steps. Accordingly, it is intended that the specification and examples be considered illustrative only, with a true scope and spirit being indicated by the following claims and the full range of equivalents thereof.

320: client device

330:packet management server

331: front-end server

332:Backend server

400: process

401, 402, 403, 404, 405, 406, 407, 408, 409, 410, 411, 412, 413: steps

Claims (20)

A computer-implemented system for managing incoming requests and specifying data packets, the system comprising: memory storing instructions; and at least one processor configured to execute the instructions to: generating a plurality of packages, wherein each package includes a plurality of products from the combination of the order selected to be an active pick from the fulfillment center; adding the plurality of packages to the package pool, the The data packet pool is configured to store available data packets for a designation; receiving a designation request from a user device of a fulfillment center picker in communication with the management server; responding to detecting the designation request is a response to a previous A second specified request generated by a faulty request, a priority parameter is added to the specified request; the specified request is added to a request pool configured to queue multiple specified requests, wherein the multiple profiles are generated packets and receiving the specified request occur asynchronously; a first group of one or more packets is retrieved from the packet pool; a second group of one or more specified requests is retrieved from the request pool, wherein specified requests having said priority parameter are retrieved prior to specified requests not having said priority parameter; when said one or more data packages are associated with a first physical location, said first group of The one or more data packets are assigned to the second group of designated requests, the first physical location and the user device sending the designated request matching the second physical location; and transmitting the one or more specified requests together with the specified data package to the corresponding user device. The computer-implemented system as claimed in claim 1, wherein the instruction further includes: receiving a plurality of designated requests from a plurality of user devices, wherein the number of the plurality of designated requests is greater than the processing capability of the computer-implemented system. The computer-implemented system of claim 1, wherein generating the plurality of data packages comprises: decomposing the data elements into one or more components; and grouping the one or more components based on predetermined criteria. The computer-implemented system of claim 1, wherein the number of packets in the first group is a multiple of the specified required number in the second group. The computer-implemented system of claim 1, wherein the request pool is configured to follow a first-in-first-out operation. The computer-implemented system of claim 1, wherein the instructions further include: transmitting an error code having a subset of the one or more specified requirements. The computer-implemented system of claim 6, wherein said subset of said one or more specified requirements does not specify a package. The computer-implemented system of claim 6, wherein the error code is configured to determine a delay after which the corresponding user device can resubmit The second specified requirement. The computer-implemented system of claim 1, wherein the instructions further include: recording how to assign the one or more packets of the first group to the one or more packets of the second group specified requirements. The computer-implemented system of claim 1, wherein the instructions further comprise: receiving additional specific requests from additional user devices in communication with the management server, wherein the user devices are located within the same physical area. A computer-implemented method of managing incoming requests and package assignments, the method comprising: generating a plurality of packages based on combinations of data elements, wherein each package includes a plurality of products from a combination of orders, the products selected to be an active pick from the fulfillment center; adding the plurality of packages to a package pool configured to store available packages for the specified; from the fulfillment in communication with the management server receiving a designated request at a user device of a center picker; in response to detecting that the designated request is a second designated request generated in response to a previous failed request, adding a priority parameter to the designated request; adding the designated request adding a request to a request pool configured to queue a plurality of specified requests, wherein generating the plurality of packets and receiving the specified requests occurs asynchronously; Retrieving a first group of one or more data packets from the data packet pool; retrieving a second group of one or more specified requests from the request pool, wherein the specified request with the priority parameter is not Assignment of the priority parameter requires previously being retrieved; when the one or more packets are associated with a first physical location, assigning the one or more packets of the first group to the A second group of the specified requests, the first physical location matching a second physical location of the user device sending the specified requests; and matching the one or more specified requests with the specified packet and transmitted to the corresponding user device together. The computer-implemented method as claimed in claim 11, further comprising: receiving a plurality of designated requests from a plurality of user devices, wherein the number of the plurality of designated requests is greater than the processing capability of the computer-implemented system. The computer-implemented method of claim 11, wherein generating the plurality of data packages comprises: decomposing the data elements into one or more components; and grouping the one or more components based on predetermined criteria. The computer-implemented method of claim 11, wherein the number of data packets in the first group is a multiple of the specified required number in the second group. The computer-implemented method of claim 11, further comprising: transmitting an error code having a subset of the one or more specified requirements. The computer-implemented method of claim 15, wherein the one or more The subset of specified requirements does not specify a package. The computer-implemented method of claim 15, wherein the error code is configured to determine a delay after which the corresponding user device can resubmit a second specified request. The computer-implemented method as claimed in claim 11, further comprising: recording how to assign the one or more data packets of the first group to the one or more assignment requirements of the second group. The computer-implemented method of claim 11, further comprising: receiving additional specific requests from additional user devices in communication with the management server, wherein the user devices are located within the same physical area. A computer-implemented system for generating tasks in response to user requests, the system comprising: a memory storing instructions; and at least one processor configured to execute the instructions to: generating a plurality of job lots, each job lot comprising one or more products from a combination of orders selected for active picking from a fulfillment center; based on the item identifier assigned to the corresponding job lot splitting at least one batch of jobs into one or more container groups corresponding to at least one of the total weight or total volume of the items; adding a plurality of batch indicators referencing the plurality of batches of jobs to the first Queuing; receiving multiple batch requests from multiple user devices of fulfillment center pickers, in response to detecting that the lot request is a second lot request generated in response to a previous failed request, adding a priority parameter to the lot request; adding the plurality of lot requests to a second queue Rows; a first group of batch indicators is retrieved from the first queue and a second group of batch requests is retrieved from the second queue, wherein batch requests with the priority parameter are retrieved without Lot requirements for the priority parameter were previously retrieved; when one or more lot indices are associated with the first physical location, aligning individual lot indices of the first group with those of the second group associated with a batch request, the first physical location matching a second physical location of the user device sending the batch request; and the individual batch request being associated with one or more batch indicators transmitted to a respective user device, wherein the respective user device is configured to retrieve one or more batch jobs referenced by the one or more batch pointers.

Images