DETAILED ACTION
This Office Action is in response to Applicant's response to application filed on 17 March 2025. Currently, claims 1-20 are pending. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Information Disclosure Statement
The information disclosure statement (IDS) submitted is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1, 4-20 are clearly drawn to at least one of the four categories of patent eligible subject matter recited in 35 U.S.C. 101 (a system). Claims 1, 4-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more. Claim 1 recites the abstract idea of controlling item placement for managing warehouse productivity by performing cost analysis and discrete event simulation to the input dataset to obtain a candidate dataset and generating a recommendation for an optimal mix of volume flow through different forward pick areas of a warehouse by applying a linear programming solver on the candidate dataset. The claims are directed to optimizing warehouse management by generating recommendation for the flow of different pick areas. Under prong 1 of Step 2A, these claims are considered abstract because the claims are a type of certain methods of organizing human activity such as commercial interactions (including business relations) and mathematical concepts. Applicant’s claims are a type of organized human activity related to business because the claims are organizing (optimizing) the pick areas of a warehouse which can be considered human activity. In addition, the claims are a mathematical concept because the generating a recommendation by applying a linear program solver to data is considered a mathematical concept. Under prong 2 of Step 2A, the judicial exception is not integrated into a practical application because the claims (the judicial exception and any additional elements individually or in combination such as one or more warehouse databases and one or more processors configured to: interface with the one or more warehouse databases and extract, transform and load information from the one or more warehouse databases to form an input dataset) are not an improvement to a computer or a technology, the claims do not apply the judicial exception with a particular machine, the claims do not effect a transformation or reduction of a particular article to a different state or thing nor do the claims apply the judicial exception in some other meaningful way beyond generally linking the use of the judicial exception to a particular technological environment such that the claims as a whole is more than a drafting effort designed to monopolize the exception. These limitations at best are merely implementing an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea - see MPEP 2106.05(f). Under Step 2B, the claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception because the additional elements individually or in combination such as one or more warehouse databases and one or more processors configured to: interface with the one or more warehouse databases and extract, transform and load information from the one or more warehouse databases to form an input dataset (as evidenced by para [00111], [00141], [00178] and Fig. 6 of applicant’s own specification) are well understood, routine and conventional in the field. Dependent claims 4-5, 8, 10, 12, 14, 17-20 also do not include additional elements that are sufficient to amount to significantly more than the judicial exception because the additional elements either individually or in combination are merely an extension of the abstract idea itself by further showing wherein performing discrete event simulation comprises using a model representing a fulfillment center as a series of interconnected components or entities, including machines, workers, customers or combinations thereof, that interact with each other over time, as a series of discrete events that match how orders flow through the fulfillment center, wherein the model is run a plurality of iterations, with different input parameters and scenarios, to determine impact of different conditions and decisions on performance of the fulfillment center and wherein the components include orders, products, workers, equipment, robotics, automation, and transportation systems, wherein the discrete events include arrivals, product movements, equipment processing and worker actions, which occur at specific points in time and , wherein performing the discrete event simulation comprises representing picking by container dwell times in both manual and automated picking areas/workstations, wherein dwell times are modeled using a probability distribution based on historical data, wherein the dwell times indicate how much capacity in each picking area is being utilized and wherein the one or more processors are further configured to provide ongoing monitoring of benchmarked values pertaining to process path mix including an optimal number of units assigned to robots for picking tasks (ASRS) and an acceptable threshold that ensures uninterrupted flow during unit picking activities involving both robots (ASRS) and manual pickers and wherein the one or more processors are further configured to monitor week-over-week slotting performance metrics for each fulfillment center, analyze aggregated volume mix, heat mapping, identify improvement opportunities, and/or address constraints faced in achieving an optimal distribution of units between bot picking (ASRS) and manual picking activities and wherein the one or more processors are further configured to monitor fluctuations in volume of incoming units to a fulfillment center and implement adjustments to achieve a balanced distribution of workload (units to be picked) across various mods, levels, and zones and wherein the one or more processors are further configured to adapt to demand volatility by realigning item placement within a defined mix, including causing shifting items to more prominent locations, adjusting quantities based on demand forecasts, or accounting for new products allocated to a fulfillment center and wherein the one or more processors are further configured to provide insights into number of containers fulfilled through inter-Module Order Distribution (MOD) travel, within 1 MOD, 2 MODs, 3 MODs, and 4 MODs and wherein the one or more processors are further configured to adjust item placement to align with recommended mix from different location types, continuously to reduce costs and improve cycle time and wherein extracting information comprises obtaining a list of items, slots and forward pick assignments by location type, wherein information related to slots include data pertaining to slot numbers, aisle locations, rack positions, and any other relevant slot attributes, wherein information related to forward pick assignments include information on allocation of items to specific pick locations for enhancing order fulfillment efficiency. Dependent claims 6-7, 9, 11, 13, 15-16 do not include additional elements that are sufficient to amount to significantly more than the judicial exception because the additional elements individually or in combination such as wherein the model comprises engineering computer-aided design (CAD) drawings that replicate infrastructure the fulfillment center, wherein data collected during the extract, transform and load is used to populate key points within the model to build a logical model required for analysis and, wherein the model is run continuously to build inputs for the linear programming solver, wherein the model is iteratively run based on the input dataset, until optimal volume thresholds flowing through different forward pick location types is determined and wherein performing the discrete event simulation comprises performing random replications by running a simulation model multiple times with different sets of random input values, to obtain a range of results and analyze statistical measures such as mean, standard deviation, confidence intervals, or percentiles and get eliminate results based on chance or bias and wherein performing the discrete event simulation comprises defining a set of experimental parameters for a discrete event simulation engine to automatically run simulations, including defining a range or distribution for each parameter and using the discrete event simulation engine to automatically generate random values within those ranges for each replication and wherein the one or more processors are further configured to generate a summary dashboard for real-time monitoring of fulfillment center slotting health, including listing open or unslotted location, charges by location type, and containers percentage with multi-mod (Module Order Distribution) travel and wherein transforming the information comprises cleaning, enriching, and manipulating data into a consistent format that meets format requirements of a discrete event simulation engine and wherein the one or more processors are further configured to track metrics in real time, compare the metrics against predefined targets or benchmarks, and set up browser alerts or e-mail notifications based on thresholds being exceeded (as evidenced by para [00111], [00141], [00178] and Fig. 6 of applicant’s own specification) are well understood, routine and conventional in the field.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
Claims 1, 4-5, 11-12, 14, 19-20 are rejected under 35 U.S.C. 103 as being unpatentable over Rorro et al. (US 2022/0207452 A1) (hereinafter Rorro) in view of Yao et al. (US 20180182054 A1) (hereinafter Yao).
Claim 1:
Rorro, as shown, discloses the following limitations of claim 1:
A system for controlling item placement for managing warehouse productivity, the system comprising: one or more warehouse databases: and one or more processors configured to: interface with the one or more warehouse databases (see para [0034], "Referring again to FIG. 1A, for example, the system 150 for generating warehouse process plans and coordinating warehouse operations can include various computing servers 160 and data sources 162. In some examples, the computing servers 160 can represent various forms of servers, including but not limited to network servers, web servers, application servers, or other suitable computing servers. In some examples, the data sources 162 can represent databases, file systems, and/or cached data sources. The computing servers 160, for example, can access data from the data sources 162, can execute software that processes the accessed data, and can provide information based on the accessed data to the computing devices 122a-d. Communications between the computing servers 160, the computing devices 122a-d, and various data collection devices (not shown) in the warehouse environment 100, for example, can occur over one or more communication networks (not shown), including a LAN (local area network), a WAN (wide area network), and/or the Internet. In the present example, the computing servers 160 and the data sources 162 can be used to implement a warehouse coordination system, which is described in further detail with respect to FIG. 2.");
extract, transform and load information from the one or more warehouse databases to form an input dataset (see para [0035]-[0036], " Referring now to FIG. 2, an example system 200 for generating warehouse process plans and coordinating warehouse operations is depicted. The system 200 in the present example includes a warehouse coordination system 210 that receives data (e.g., using a data collection component) from one or more warehouse management systems 220, performance tracking systems 230, and configuration systems 240. The warehouse management system(s) 220, for example, can provide real-time information related to a state of the warehouse environment 100 (shown in FIG. 1A). For example, the warehouse management system(s) 220 can provide information related to containers of goods that have been received and are waiting to be placed in the storage area 110 (shown in FIG. 1A). As another example, the warehouse management system(s) 220 can provide information related to requests for goods that are to be picked from the storage area 110 and that are to be loaded into containers 106 (shown in FIG. 1A) and sent to a retail store. As containers 106 and/or goods in the warehouse environment 100 are involved in a warehouse operation (e.g., receipt, transport, put away, pick, repackaging, shipment, etc.), for example, real-time operation data (e.g., including an operation timestamp and various identifiers related to the operation, such as location, worker, team, equipment, container, and/or goods identifiers), can be collected and stored by the warehouse management system(s) 220. The performance tracking system(s) 230, for example, can maintain and provide data related to historical performance of various warehouse equipment, workers, and/or teams. For example, the performance tracking system(s) 230 can provide data that indicates productivity rates (e.g., a number of warehouse operations per time period over a defined time range, such as over a previous week, month, quarter, etc.) of warehouse equipment, workers, and/or teams, such that productivity of current combinations of equipment, workers, and/or teams can be projected over a current shift. The configuration system(s) 240, for example, can maintain and provide data related to a configuration (e.g., physical layout, processing capabilities, available equipment, etc.) of the warehouse environment 100. Data received from the warehouse management system(s) 220, the performance tracking system(s) 230, and/or the configuration system(s) 240, for example, can be combined and stored in an enhanced warehouse data source 250 for use by the warehouse coordination system 210. In the present example, the warehouse coordination system 210 can include and/or communicate with a plan creation interface generator 260, a performance monitoring interface generator 270, and a warehouse planning simulator 280. The plan creation interface generator 260, for example, can be used by the warehouse coordination system 210 to generate respective plan creation interfaces for presentation on each of the computing devices 122a-d (shown in FIG. 1A) when requested during the pre-shift period 132 (shown in FIG. 1B). The performance monitoring interface generator 270, for example, can be used by the warehouse coordination system 210 to generate respective performance monitoring interfaces for presentation on each of the computing devices 122a-d when requested during any of the shift periods 134a-c and/or during the end of shift recap period 146c (shown in FIG. 1B). The warehouse planning simulator 280, for example, can be used by the warehouse coordination system 210 (e.g., as part of a plan creation process) to run granular, discrete process simulations for operations to be performed by a team during a shift.");
perform cost analysis and discrete event simulation to the input dataset to obtain a candidate dataset (see para [0045]-[0046], " In response to receiving the user input and the simulation command, at 366, the warehouse coordination system 210 performs a simulation of the tasks to be performed over the shift for the warehouse process, according to the user inputs. For example, the warehouse coordination system 210 can receive from the client device 302 (e.g., similar to one of the computing devices 122a-d, shown in FIG. 1A) a data structure that includes data that indicates the selected, sequenced, and staffed work tasks input by the operations manager using the plan creation interface 180 (shown in FIG. 1), and can use the warehouse planning simulator 280 (shown in FIG. 2) to run a granular, discrete process simulation of the work tasks being performed in the warehouse environment 100 (shown in FIG. 1A). Running the process simulation, for example, can include modeling the selected work tasks according to the assigned sequence and the applied resources over time, using a collection of state variables that represent a current state of various warehouse entities (e.g., vehicles, equipment, workers, containers, products, etc.) within the warehouse environment 100. The state variables, for example, can be modified by the simulation to model an evolution of the state of the various warehouse entities over time. At 368, the warehouse coordination system 210 transmits an output of the simulation of the tasks to be performed over the shift for the warehouse process, and at 370, the client device 302 presents the simulated output. Referring to FIG. 1A, for example, the plan creation interface 180 can include a simulation output interface 186 through which the operations manager can review the output of the simulation of the tasks (e.g., predicted throughput of a team over a shift when performing the warehouse process according to the specified plan). If the output is not acceptable, for example, the operations manager can again use the work task input interface 182 to adjust the work plan (e.g., by selecting different tasks, resequencing the tasks, and/or assigning different resources to the tasks), and can provide a command to run a simulation of the adjusted work plan. By experimenting with various different task, sequence, and resource scenarios, for example, operations managers can efficiently generate and refine feasible work plans for their respective teams. When the output is determined by the operations manager as being acceptable, for example, the operations manager can confirm and submit the work plan for his or her team for possible inclusion in an overall plan for a shift. In the present example, at 372 the work plan is confirmed and submitted by the operations manager at 372, who provides a command to confirm and submit the work plan by selecting the submission control 188 of the simulation output interface 186."); and
generate a recommendation for an optimal mix of volume flow through different forward pick areas of a warehouse by applying a linear programming solver on the candidate dataset (see para [0102], "FIG. 7H, for example, shows a receiving plan import interface for importing data from the receiving plan for use in creating a storage and retrieval plan. For example, input can be received from the receiving plan for a given shift to evaluate the estimated incoming pallet quantities that can be processed by one or more storage and retrieval teams. If the receiving plan is not uploaded, for example, a message can be presented prompting for upload of the receiving plan. The receiving plan import interface can include a Put Teams table, for example, that shows a volume of Large, Medium, or Small Pallets that can be processed for a given period. A number of periods may vary, for example, based on a particular warehouse environment. A carton-to-pallet algorithm can be used to covert a total number of cartons (e.g., from an incoming appointment) into a total number of pallets, for example. The receiving plan import interface can also provide a percentage of RAPs Pallet Quantities along with Estimated Hours, and along with a percentage breakout of Dock to Aisle %. Inbound Planning Estimated Pallets and RAPs Pallet Quantity can be considered to determine a put team's staffing levels, for example. Through the receiving plan import interface, for example, a user can manually adjust various values (e.g., RAP values, and/or staffing values) to more accurately reflect a total backlog of work available." and see para [0104], "FIGS. 7J and 7K, for example, show summary information that can be provided with respect to simulation output data. For example, in response to the user selecting the “Generate Outputs” control (shown in FIG. 7A), simulated output can be generated based on data input using the warehouse configuration portion(s), the sequencing portion(s), and the resource application portion(s) of the storage and retrieval plan creation user interface. The simulated output can be used by an operations manager, for example, to analyze, validate, and make decisions for a shift. In the present example, the simulation output data for the storage and retrieval processes can include warehouse state data, pick/put data, and mover data. The warehouse state data, for example, can include data related to carton/pallet states in terms of total cartons and pallets that are unpicked, along with inventory age information. A density detail can be added for pending cartons and pallets, for example, to indicate a backlog that may be provided to a next shift. A total number of available locations can be provided for each aisle, based on size (e.g., small, medium, and large), for example, along with pending staged pallets. The pick/put data, for example, can provide details related to each pick and put team working on selected volumes based on the storage and retrieval plan. Breakout, for example, can be based on a team identifier and workstation. A total volume can be determined based on selected volumes and resource allocations, for example. A projected volume, for example, can be based on period available hours and productivity of a team, and can be determined for each aisle. Mover data, for example, can include output details for each trip identifier at a period level, to identify a total number of processed cartons, along with a size of a processed pallet, based on team type." and see para [0115], " In some implementations, input recommendations may be provided by a plan creation user interface. For example, the computing server(s) 160 can use various machine learning techniques to determine an optimal input value for a particular input (or group of inputs, such as sequencing controls), and can provide the optimal input value as a recommended value (e.g., a default value provided within or in proximity to an input control). A user can choose to accept the recommended value as an input value, or can provide another input value, for example. Input recommendations may be provide for any, all, or none of the input controls presented on the various plan creation user interfaces, for example." and Fig. 6a).
Although Rorro shows applying machine learning to apply a recommendation which is a type of algorithm, Rorro does not explicitly describe applying a linear programming solver. In analogous art, Yao discloses the following limitations:
extract, transform and load information from the one or more warehouse databases to form an input dataset (see para [0025], "Accordingly, utilizing a database management system in the manner described herein may be more efficient and faster than alternative methods because extract, transfer, and load operations on order data and other data used herein may already be performed by the database management system for other reasons");
generate a recommendation for an optimal mix of volume flow through different forward pick areas of a warehouse by applying a linear programming solver on the candidate dataset (see para [0027], "The database management system may comprise a task assignment system 106 and an optimization engine 108. The task assignment system 106 may receive and/or access various input data and format warehouse management described herein into one or more linear programming problems. The task assignment system 106 may also call the optimization engine 108 to solve the generated integer or linear programming problems. Based on the results of the optimization engine 108, the task assignment system may generate task assignments 116. Task assignments 116 may describe tasks, which include a route through a warehouse and one or more orders including products in the orders to be picked. Task assignments 116 may also include picking agent assignment data indicating a picking agent to which or whom a task is assigned. Although the pick assignment system 106 and optimization engine 108 are shown as components of the database management system 102, in some examples, these components may be executed outside of the database management system 102. For example, one or both of the task assignment system 106 and optimization engine 108 may be implemented as client applications utilizing the database 104 through the database management system 102. Also, in some examples, one or both of the task assignment system 106 and optimization engine 108 may be implemented outside the context of a database management system 102 altogether.")
It would have been obvious to one or ordinary skill in the art at the time of the invention to combine the teachings of Yao with Rorro because using linearly programming provides another technique for improving the efficiency in picking warehouse orders (see Yao, para [0001]-[0002]).
Moreover, it would have been obvious to one of ordinary skill in the art at the time of the invention to include the warehouse management system as taught by Yao in the warehouse coordination system of Rorro, since the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
Claim 4:
Further, Rorro discloses the following limitations:
wherein performing discrete event simulation comprises using a model representing a fulfillment center as a series of interconnected components or entities, including machines, workers, customers or combinations thereof, that interact with each other over time, as a series of discrete events that match how orders flow through the fulfillment center, wherein the model is run a plurality of iterations, with different input parameters and scenarios, to determine impact of different conditions and decisions on performance of the fulfillment center (see para [0045], "In response to receiving the user input and the simulation command, at 366, the warehouse coordination system 210 performs a simulation of the tasks to be performed over the shift for the warehouse process, according to the user inputs. For example, the warehouse coordination system 210 can receive from the client device 302 (e.g., similar to one of the computing devices 122a-d, shown in FIG. 1A) a data structure that includes data that indicates the selected, sequenced, and staffed work tasks input by the operations manager using the plan creation interface 180 (shown in FIG. 1), and can use the warehouse planning simulator 280 (shown in FIG. 2) to run a granular, discrete process simulation of the work tasks being performed in the warehouse environment 100 (shown in FIG. 1A). Running the process simulation, for example, can include modeling the selected work tasks according to the assigned sequence and the applied resources over time, using a collection of state variables that represent a current state of various warehouse entities (e.g., vehicles, equipment, workers, containers, products, etc.) within the warehouse environment 100. The state variables, for example, can be modified by the simulation to model an evolution of the state of the various warehouse entities over time." and see para [0083], " In the present example shown in FIG. 6D, a staffing inputs control can be provided for allocating staffing resources for various periods of a shift. Based on a specified period assigned in a Shift Period Configuration (e.g., described in further detail with respect to FIG. 8B), for example, Productive Minutes can be determined for a respective period. A “Shift Period” column, for example, can show a period of a shift. A “Productive Minutes” column, for example, can show a total amount of productive minutes available per period, based on inputs to the Shift Period Configuration. User input can be provided under a “Staffing” column, for example, to indicate a total number of resources (e.g., workers) allocated per period. A “Staffed Hours” column, for example, can be calculated based on the Productive Minutes and the number input in the Staffing column, which results in a total number of staffed hours. The total number of staffed hours can match with Total Selected Hours, for example, to match 100% carton processing for a shift." and see para [0073] and Fig. 6).
Claim 5:
Further, Rorro discloses the following limitations:
wherein the components include orders, products, workers, equipment, robotics, automation, and transportation systems (see para [0028]-[0029], "In general, workers and equipment may be organized into different teams, each team performing a different sort of task in the warehouse environment. For example, a receiving team 120a can include workers 114 and/or equipment 116 for performing various receiving tasks, such as unloading containers 106 from vehicles 104. A storage and retrieval team 120b, for example, can include workers 114 and/or equipment 116 for performing various storage and/or retrieval tasks, such as moving the containers 106 throughout the warehouse environment 100, placing the containers 106 in the storage racks 112, and removing the containers 106 from the storage racks 112. A sortation team 120c, for example, can include workers 114 and/or equipment 116 for performing various sortation tasks, such as breaking apart containers 106 of goods and/or repackaging goods into different containers 106. A shipping team 120d, for example, can include workers 114 and/or equipment 116 for performing various shipping tasks, such as loading containers 106 into outbound vehicles 104 for transportation to other locations (e.g., warehouses, distribution centers, stores, customer locations, etc.). In general, each team may include and/or be directed by one or more operations managers that use computer applications running on computing devices to create work plans for their team (e.g., a work plan that specifies work to be performed by the team during a shift), and to monitor the progress of the team according to the work plan (e.g., over the course of the shift). For example, an operations manager of the receiving team 120a can use computing device 122a, an operations manager of the storage and retrieval team 120b can use computing device 122b, an operations manager of the sortation team 120c can use computing device 122c, and an operations manager of the shipping team 120d can use computing device 122d. Each of the computing devices 122a-d, for example, can be various forms of stationary or mobile processing devices including, but not limited to a desktop computer, a laptop computer, a tablet computer, a personal digital assistant (PDA), a smartphone, or other processing devices."), wherein the discrete events include arrivals, product movements, equipment processing and worker actions, which occur at specific points in time (see para [0035], " Referring now to FIG. 2, an example system 200 for generating warehouse process plans and coordinating warehouse operations is depicted. The system 200 in the present example includes a warehouse coordination system 210 that receives data (e.g., using a data collection component) from one or more warehouse management systems 220, performance tracking systems 230, and configuration systems 240. The warehouse management system(s) 220, for example, can provide real-time information related to a state of the warehouse environment 100 (shown in FIG. 1A). For example, the warehouse management system(s) 220 can provide information related to containers of goods that have been received and are waiting to be placed in the storage area 110 (shown in FIG. 1A). As another example, the warehouse management system(s) 220 can provide information related to requests for goods that are to be picked from the storage area 110 and that are to be loaded into containers 106 (shown in FIG. 1A) and sent to a retail store. As containers 106 and/or goods in the warehouse environment 100 are involved in a warehouse operation (e.g., receipt, transport, put away, pick, repackaging, shipment, etc.), for example, real-time operation data (e.g., including an operation timestamp and various identifiers related to the operation, such as location, worker, team, equipment, container, and/or goods identifiers), can be collected and stored by the warehouse management system(s) 220. The performance tracking system(s) 230, for example, can maintain and provide data related to historical performance of various warehouse equipment, workers, and/or teams. For example, the performance tracking system(s) 230 can provide data that indicates productivity rates (e.g., a number of warehouse operations per time period over a defined time range, such as over a previous week, month, quarter, etc.) of warehouse equipment, workers, and/or teams, such that productivity of current combinations of equipment, workers, and/or teams can be projected over a current shift. The configuration system(s) 240, for example, can maintain and provide data related to a configuration (e.g., physical layout, processing capabilities, available equipment, etc.) of the warehouse environment 100. Data received from the warehouse management system(s) 220, the performance tracking system(s) 230, and/or the configuration system(s) 240, for example, can be combined and stored in an enhanced warehouse data source 250 for use by the warehouse coordination system 210.")
Claim 11:
Rorro does not explicitly disclose wherein performing the discrete event simulation comprises defining a set of experimental parameters for a discrete event simulation engine to automatically run simulations, including defining a range or distribution for each parameter and using the discrete event simulation engine to automatically generate random values within those ranges for each replication. In analogous art, Yao discloses the following limitations:
wherein performing the discrete event simulation comprises defining a set of experimental parameters for a discrete event simulation engine to automatically run simulations, including defining a range or distribution for each parameter and using the discrete event simulation engine to automatically generate random values within those ranges for each replication (see para [0046], "At operation 412, the task assignment system 106 may determine a next path from the current node. The next path may be selected from the paths that meet the current node. Each path may have an associated path probability and, in some examples, the next path may be selected from the paths meeting the current node randomly or pseudo-randomly considering the path probabilities. For example, a sum of the path probabilities for paths meeting the current node may be one or may be normalized to one by the task assignment system 106. In some examples, the task assignment system 106 may utilize a set of numbers. Ranges of the set of numbers may be assigned to each path meeting the current node, for example, based on the corresponding path probabilities. For example, consider an example where a first path and a second path meet the current node where the first path has a path probability that is twice the second path. The task assignment system 106 may assign two-thirds of the set of numbers to the first path and one-third to the second path. Then the task assignment system 106 may randomly select a number from the set of numbers. If the randomly selected number is assigned to the first path, then the task assignment system 106 may select the first path. If the randomly selected number is assigned to the second path, then the task assignment system 106 may select the second path.")
It would have been obvious to one of ordinary skill in the art at the time of the invention to include the warehouse management system as taught by Yao in the warehouse coordination system of Rorro, since the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
Claim 12:
Further, Rorro discloses the following limitations:
wherein the one or more processors are further configured to monitor week-over-week slotting performance metrics for each fulfillment center, analyze aggregated volume mix, heat mapping, identify improvement opportunities, and/or address constraints faced in achieving an optimal distribution of units between bot picking (ASRS) and manual picking activities (see para [0078], " Once the appointments are assigned, for example, the plan creation user interface can be used to provide additional details regarding the appointments. Referring again to FIG. 6A, for example, an overview can be provided that breaks down Cartons Per Hour (CPH) by area (e.g., ART and Manual Dock). For each area, for example, budget, planned, staffing, and trend information can be provided. A “Budget” column, for example, can indicate a selected volume for each mode mix divided by a current month's budget for each mode mix. A “Planned” column, for example, can indicate a selected volume for each mode mix divided by a team's current performance to budget. A “Staffing” column, for example, can indicate a selected volume divided by planned productivity divided by hours in a shift. A “Trend” column, for example, can indicate a team's performance to budget over a previous number of weeks (e.g., 4 weeks, 8 weeks, 12 weeks, or another suitable number of weeks). User input can be provided under an “Override” column, for example, to modify productivities used in CPH and appointment unload times. Values entered under the “Override” column, for example, can be a number value, and can be entered for ART, Manual Dock, both, or neither. Based on the allocation, for example, the total number of appointments and total carton quantity can be provided to users with respect to volumes generated for a shift. If capacity constraints exist based on zone, for example, such directional numbers can be used to take action by making adjustments to the appointments.")
Claim 14:
Further, Rorro discloses the following limitations:
wherein the one or more processors are further configured to monitor fluctuations in volume of incoming units to a fulfillment center and implement adjustments to achieve a balanced distribution of workload (units to be picked) across various mods, levels, and zones (see para [0078], " Once the appointments are assigned, for example, the plan creation user interface can be used to provide additional details regarding the appointments. Referring again to FIG. 6A, for example, an overview can be provided that breaks down Cartons Per Hour (CPH) by area (e.g., ART and Manual Dock). For each area, for example, budget, planned, staffing, and trend information can be provided. A “Budget” column, for example, can indicate a selected volume for each mode mix divided by a current month's budget for each mode mix. A “Planned” column, for example, can indicate a selected volume for each mode mix divided by a team's current performance to budget. A “Staffing” column, for example, can indicate a selected volume divided by planned productivity divided by hours in a shift. A “Trend” column, for example, can indicate a team's performance to budget over a previous number of weeks (e.g., 4 weeks, 8 weeks, 12 weeks, or another suitable number of weeks). User input can be provided under an “Override” column, for example, to modify productivities used in CPH and appointment unload times. Values entered under the “Override” column, for example, can be a number value, and can be entered for ART, Manual Dock, both, or neither. Based on the allocation, for example, the total number of appointments and total carton quantity can be provided to users with respect to volumes generated for a shift. If capacity constraints exist based on zone, for example, such directional numbers can be used to take action by making adjustments to the appointments.")
Claim 19:
Further, Rorro discloses the following limitations:
wherein the one or more processors are further configured to adjust item placement to align with recommended mix from different location types, continuously to reduce costs and improve cycle time (see para [0078], "Once the appointments are assigned, for example, the plan creation user interface can be used to provide additional details regarding the appointments. Referring again to FIG. 6A, for example, an overview can be provided that breaks down Cartons Per Hour (CPH) by area (e.g., ART and Manual Dock). For each area, for example, budget, planned, staffing, and trend information can be provided. A “Budget” column, for example, can indicate a selected volume for each mode mix divided by a current month's budget for each mode mix. A “Planned” column, for example, can indicate a selected volume for each mode mix divided by a team's current performance to budget. A “Staffing” column, for example, can indicate a selected volume divided by planned productivity divided by hours in a shift. A “Trend” column, for example, can indicate a team's performance to budget over a previous number of weeks (e.g., 4 weeks, 8 weeks, 12 weeks, or another suitable number of weeks). User input can be provided under an “Override” column, for example, to modify productivities used in CPH and appointment unload times. Values entered under the “Override” column, for example, can be a number value, and can be entered for ART, Manual Dock, both, or neither. Based on the allocation, for example, the total number of appointments and total carton quantity can be provided to users with respect to volumes generated for a shift. If capacity constraints exist based on zone, for example, such directional numbers can be used to take action by making adjustments to the appointments." Examiner notes that "continuously to reduce costs and improve cycle time." is considered intended use and not given patentable weight.)
Claim 20:
Further, Rorro discloses the following limitations:
wherein extracting information comprises obtaining a list of items, slots and forward pick assignments by location type, wherein information related to slots include data pertaining to slot numbers, aisle locations, rack positions, and any other relevant slot attributes, wherein information related to forward pick assignments include information on allocation of items to specific pick locations for enhancing order fulfillment efficiency (see para [0027]-[0028], "The warehouse environment 100 can be a storage warehouse, a packing warehouse, a retail warehouse, a distribution center, or another sort of warehouse or facility, for example. In the present example, the warehouse environment 100 includes multiple docks 102 at which vehicles 104 (e.g., trucks) can be loaded and/or unloaded with various containers 106 (e.g., pallets, boxes, etc., containing various goods). The warehouse environment 100 in the present example also includes a storage area 110, which can include various storage racks 112 which can be arranged in rows and/or columns and configured to store the containers 106 in different levels. For example, elevators and/or rack conveyor belts may be used to elevate the containers 106 to different levels and move them to and from desired locations in the storage racks 112. Various workers 114 and equipment 116 (e.g., forklifts, pallet jacks, automated guided vehicles (AGVs), etc.) can be employed in the warehouse environment 100, for example, to perform various warehouse tasks. In general, workers and equipment may be organized into different teams, each team performing a different sort of task in the warehouse environment. For example, a receiving team 120a can include workers 114 and/or equipment 116 for performing various receiving tasks, such as unloading containers 106 from vehicles 104. A storage and retrieval team 120b, for example, can include workers 114 and/or equipment 116 for performing various storage and/or retrieval tasks, such as moving the containers 106 throughout the warehouse environment 100, placing the containers 106 in the storage racks 112, and removing the containers 106 from the storage racks 112. A sortation team 120c, for example, can include workers 114 and/or equipment 116 for performing various sortation tasks, such as breaking apart containers 106 of goods and/or repackaging goods into different containers 106. A shipping team 120d, for example, can include workers 114 and/or equipment 116 for performing various shipping tasks, such as loading containers 106 into outbound vehicles 104 for transportation to other locations (e.g., warehouses, distribution centers, stores, customer locations, etc.)." and see para [0090], "FIG. 7B, for example, shows a portion of the storage and retrieval plan creation user interface that can be used to receive user input that indicates a configuration of a warehouse environment as it applies to storage and retrieval operations. For example, in response to a user selecting the “Enter Blocked Aisles” control (shown in FIG. 7A), a portion of the storage and retrieval plan creation user interface for entering information about blocked aisles can be presented to the user. In general, the blocked aisles interface can provide a list of workstations (e.g., as shown in a “Workstation” column) and aisles (e.g., as shown in an “Aisle” column) that are being physically blocked. If an aisle is blocked, for example, some operations may not be able to be performed in the aisle, such as operations that involve powered equipment. Such aisle blockage information may not be tracked by a warehouse management system (e.g., the warehouse management system(s) 220, shown in FIG. 2), for example, but may be used in a simulation of storage and retrieval processes. Workstations, for example, can be a high-level grouping of aisles (e.g., including storage racks 112) in the warehouse environment 100. The workstations, for example, can be grouped by a type of goods stored in the area, because different types of goods may be stored using different types of storage racking, or because of various regulations (e.g., food items being stored separately from other types of goods). In the present example, a user of the blocked aisle portion of the storage and retrieval plan creation user interface can provide input about blocked aisles under a “Block Type” column, and under a “Pallets” column. A “Block Type” control, for example, can be used to input either a “Backhaul (B)” or “Puts (P)” type of blockage in a particular Workstation/Aisle. A “Pallets” control, for example, can be used to input a number of pallets being processed in the particular Workstation/Aisle." and see para [0096], [0099] where for enhancing order fulfillment efficiency is considered intended use an not given patentable weight).
Claims 2-3, 13, 17-18 are rejected under 35 U.S.C. 103 as being unpatentable over Rorro and Yao, as applied above, and further in view of Gopalakrishnan et al. (US 10,099,864 B1) (hereinafter Gopalakrishnan).
Claims 2-3, 17:
Rorro does not specifically disclose automatically control, based on the recommendation, physical item placement in the warehouse by: causing automated storage and retrieval system robots to redistribute items between storage areas according to the recommendation. In analogous art, Yao discloses the following limitations:
wherein the one or more processors is further configured to: automatically control, based on the recommendation, physical item placement in the warehouse by: causing automated storage and retrieval system robots to redistribute items between storage areas according to the recommendation (see para [0032], "The task assignment system 106 may assign tasks to picking agents described by the picking agent data 114. For example, the task assignment system 106 may similarly format a linear programming problem and provide the linear programming problem to the optimization engine 108. The optimization engine may return a solution including the task assignments 116 for assigning the tasks 111 to picking agents described by the picking agent data 114. The task assignments 116 may take any suitable form. For example, the task assignments 116 may include paper work slips for human picking agents, data for printing paper work slips for human picking agents, data for instructing robotic picking agents, etc.")
It would have been obvious to one of ordinary skill in the art at the time of the invention to include the warehouse management system as taught by Yao in the warehouse coordination system of Rorro, since the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
Rorro and Yao do not specifically disclose adjusting automated conveyor system routing and merge point controls to implement the recommended volume flow. In analogous art, Gopalakrishnan discloses the following limitations:
adjusting automated conveyor system routing and merge point controls to implement the recommended volume flow (col 9, line 59 to col 10, line 14, "The container flow logic engine 114 can advantageously maximize the productivity within the logistics system by increasing the picker and system utilization, maximizing the throughput of the system by balancing the conveyor traffic and system load at any given time, minimizing container cycle time, and facilitating processing priority container by a specified time. FIG. 2 is a flowchart of an example method 200 for induction optimization in a zone-to-zone conveyor order fulfillment picking system according to the techniques described herein. The operations described in reference to FIG. 2 may be performed by the container flow logic engine 114 (or one of its components, as described above) to optimize the container (i.e. outbound shipping cartons, envelopes or totes) flow of an each picking zone-to-zone conveyor system in an order fulfillment center. This method, as well as the other techniques described herein, are configured to maximize the productivity within a conveyor system by increasing picker and system utilization, maximize the throughput of the conveyor system by balancing conveyor traffic and system load at a given time, minimizes container cycle time and facilitates processing priority container by specified time."); and
dynamically adjusting container release rates at merge points based on real-time monitoring of physical work-in-progress metrics to prevent system gridlock (col 9, line 59 to col 10, line 14, where balancing conveyor traffic shows preventing gridlock is obvious to one or ordinary skill in the art and col 4, line 16 to col 5, line 5).
wherein the system continuously monitors container dwell times and physical work-in-progress at merge points, and automatically adjusts container routing and release timing to maintain the recommended optimal mix while preventing gridlock conditions in a physical conveyor system (col 10, line 25-67, "At 204, the container flow logic engine 114 may receive confirmatory input reflecting pick completion for a subset of the cartons being conveyed by the conveying system. Confirmatory input may include, for example, conveyor scanner confirmations, pick confirmations, or other inputs reflecting pick completion (whether at induction, completion, or at a zone in the conveying system), as described in further detail elsewhere herein. At 206, the container flow logic engine 114 may generate an estimated time of arrival for one or more cartons not yet inducted into the conveying system based on the scan data and the confirmatory input. In some embodiments, the ETA forecaster 116 estimates the expected time of arrival of a carton or container (which may not currently be inducted in the system) at one or more pick zones (that the container is required to visit to get the necessary picks) from the point of induction based on a set of acceptable static/dynamic routes using a real time, or lag basis, as described in further detail elsewhere herein. Each outbound container can have either one or multiple (split case or break pack) pick lines. In order to get these pick lines fulfilled a container might need to visit one or more pick zones. In some embodiments, the estimated time of arrival may be calculated based on a combination of one or more of conveyor velocity of the conveying system, an expected destination of the cartons being conveyed by the conveying system, registered time between two successive scan points a container passes, dwell time of a container in a zone measured based on time diverted and time pick confirmed/pushed out and picker productivity. At 208, the container flow logic engine 114 may generate a load forecast based on the estimated time of arrival. In some embodiments, the load forecast includes an estimate, for a given future point in time, of a carton load being processed by the conveyor system. In some embodiments, the load forecaster 118 estimates the number of cartons in every point of the conveyor system including zones, inclines, declines, accumulation and transportation conveyor sections at a given future point of time. The load forecaster 118 may further generate the load cast based on cartons currently in the system (e.g., specific ones or a quantity thereof) and their expected destinations before exiting the systems, and based on different selection choices of new batch of containers." Examiner additionally notes to maintain the recommended optimal mix while preventing gridlock conditions in a physical conveyor system is interpreted as intended use and thus not given patentable weight.)
wherein the one or more processors are further configured to adapt to demand volatility by realigning item placement within a defined mix, including causing shifting items to more prominent locations, adjusting quantities based on demand forecasts, or accounting for new products allocated to a fulfillment center (col 7, line 20-30, "The load forecaster 118 may generate recommended staffing allocations for a forecast, which require relocation of various associates to different zones based on forecasted demand in those zones. In response, associates working in the different pick zones may be reallocated based on the requirements of the cartons to be inducted into the system as estimated by the load forecaster 118. Further, the load forecaster 118 may provide recommendation data reflecting recommended slot balance, stock time recommendations for different zones, etc.")
It would have been obvious to one or ordinary skill in the art at the time of the invention to combine the teachings of Gopalakrishnan with Rorro and Yao because adjusting automated conveyor system routing enables more effective load balancing for an inventory management system (see Gopalakrishnan, col 1, line 15-36).
Moreover, it would have been obvious to one of ordinary skill in the art at the time of the invention to include the order fulfillment picking system as taught by Gopalakrishnanin in the Rorro and Yao combination, since the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
Claims 13 and 18:
Further, Rorro discloses the following limitations:
wherein the one or more processors are further configured to generate a summary dashboard for real-time monitoring of fulfillment center slotting health, including listing open or unslotted location, charges by location type, and containers percentage with multi-mod (Module Order Distribution) travel (see para [0025], "The warehouse operation coordination platform described in this document includes labor and production planning tools for generating detailed work plans for warehouses at the team level (e.g., receiving, storage and retrieval, sortation, and shipping), across multiple teams. The platform also includes reporting tools for providing real-time information about work progress with respect to the generated plans, such that work across the various teams can be better coordinated, and production staffing needs can be shifted when appropriate. At a high level, the platform has three main components: a data ingestion component that receives relevant data from warehouse management systems (WMS) and performance tracking systems used to generate the work plans, a plan creation tool through which operation managers can generate and simulate plans for their portion of the warehouse, and a performance monitoring tool that provides work progress information to each of the operation managers to promote collaboration between the teams." and see para [0032], " During the warehouse shift (e.g., during an operations monitoring period 144a of the first shift period 134a, an operations monitoring period 144b of the second shift period 134b, and an operations monitoring period 144c of the third shift period 134c), for example, operations performed by various teams (e.g., teams 120a-d, shown in FIG. 1A) can be monitored. In the present example, real-time data that pertains to operations performed by the receiving team 120a in the warehouse environment 100 (shown in FIG. 1A) can be collected (e.g., by data collection devices, such as manual input devices, scanners, cameras, or other suitable devices in the warehouse environment 100), and used to determine progress of the receiving team 120a relative to its work plan for the shift. Similarly, in the present example, real-time data that pertains to operations performed by each of the storage and retrieval team 120b, the sortation team 120c, and the shipping team 120d, can be collected and used to determine progress of the respective team relative to its corresponding work plan for the shift. In general, information related to progress relative to a work plan can be provided to each of the computing devices 122a-d (shown in FIG. 1A) for review by operations managers of the respective teams 120a-d. For example, computing device 122a can be used to present performance monitoring information for the receiving team 120a, computing device 122b can be used to present performance monitoring information for the storage and retrieval team 120b, computing device 122c can be used to present performance monitoring information for the sortation team 120c, and computing device 122d can be used to present performance monitoring information for the shipping team 120d. In some implementations, a different interface may be provided for presenting performance monitoring information for each different team. Example interfaces for presenting performance monitoring information are described in further detail below." and see para [0035], "Referring now to FIG. 2, an example system 200 for generating warehouse process plans and coordinating warehouse operations is depicted. The system 200 in the present example includes a warehouse coordination system 210 that receives data (e.g., using a data collection component) from one or more warehouse management systems 220, performance tracking systems 230, and configuration systems 240. The warehouse management system(s) 220, for example, can provide real-time information related to a state of the warehouse environment 100 (shown in FIG. 1A). For example, the warehouse management system(s) 220 can provide information related to containers of goods that have been received and are waiting to be placed in the storage area 110 (shown in FIG. 1A). As another example, the warehouse management system(s) 220 can provide information related to requests for goods that are to be picked from the storage area 110 and that are to be loaded into containers 106 (shown in FIG. 1A) and sent to a retail store. As containers 106 and/or goods in the warehouse environment 100 are involved in a warehouse operation (e.g., receipt, transport, put away, pick, repackaging, shipment, etc.), for example, real-time operation data (e.g., including an operation timestamp and various identifiers related to the operation, such as location, worker, team, equipment, container, and/or goods identifiers), can be collected and stored by the warehouse management system(s) 220. The performance tracking system(s) 230, for example, can maintain and provide data related to historical performance of various warehouse equipment, workers, and/or teams. For example, the performance tracking system(s) 230 can provide data that indicates productivity rates (e.g., a number of warehouse operations per time period over a defined time range, such as over a previous week, month, quarter, etc.) of warehouse equipment, workers, and/or teams, such that productivity of current combinations of equipment, workers, and/or teams can be projected over a current shift. The configuration system(s) 240, for example, can maintain and provide data related to a configuration (e.g., physical layout, processing capabilities, available equipment, etc.) of the warehouse environment 100. Data received from the warehouse management system(s) 220, the performance tracking system(s) 230, and/or the configuration system(s) 240, for example, can be combined and stored in an enhanced warehouse data source 250 for use by the warehouse coordination system 210." and see para [0077], [0081], [0104])
Although Rorro shows tracking and integration with shipping, Rorro and Yao do not explicitly disclose with multi-mod (Module Order Distribution) travel. In analogous art, Gopalakrishnanin discloses the following limitations:
with multi-mod (Module Order Distribution) travel (col 3, line 9-60, where the different zones can be considered the different MODs)
wherein the one or more processors are further configured to provide insights into number of containers fulfilled through inter-Module Order Distribution (MOD) travel, within 1 MOD, 2 MODs, 3 MODs, and 4 MODs (col 3, line 9-60, where the different zones can be considered the different MODs)
It would have been obvious to one of ordinary skill in the art at the time of the invention to include the order fulfillment picking system as taught by Gopalakrishnan in the Rorro and Yao combination, since the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
Claim 6 is rejected under 35 U.S.C. 103 as being unpatentable over Rorro and Yao, as applied above, and further in view of Cai (US 20210294930 A1)
Claim 6:
Rorro and Yao do not specifically disclose wherein the model comprises engineering computer-aided design (CAD) drawings that replicate infrastructure the fulfillment center, wherein data collected during the extract, transform and load is used to populate key points within the model to build a logical model required for analysis. In analogous art, Cai discloses the following limitations:
wherein the model comprises engineering computer-aided design (CAD) drawings that replicate infrastructure the fulfillment center, wherein data collected during the extract, transform and load is used to populate key points within the model to build a logical model required for analysis (see para [0043]-[0046], showing using CAD for warehouse design and see para [0046], " FIG. 1 is an exemplary operating environment 100 in which one or more network-connected client devices 102 and a server system 104 interact with each other via one or more communication networks 106 in accordance with some embodiments. The operating environment 100 corresponds to a virtual user domain created and hosted by the server system 104, and the virtual user domain includes a plurality of user accounts. For each user account, a user 120 can log onto the respective user account and extract relevant warehouse information on a client device 102 via a web browser or a dedicated warehouse planning application. In some embodiments, the dedicated warehouse planning application is implemented entirely on the client device 102 to plan a storage space of a warehouse by storing and extracting floor plan information, inventory information and resource information locally. In some embodiments, the web browser or dedicated warehouse planning application of the client device 102 displays a graphical user interface (GUI) via which user instructions are received and communicated to the server system 104. The client device 102 thereby plans the storage space of the warehouse jointly with server system 104. In some embodiments, warehouse space planning is made based at least partially on the floor plan, inventory, and resource information, which is optionally stored at the server system 104 or received from a warehouse information source 108 distinct from the server system 104." and see para [0056]-[0058]).
It would have been obvious to one or ordinary skill in the art at the time of the invention to combine the teachings of Cai with Rorro and Yao because using CAD drawings enables a an efficient way to have customized warehouse planning solutions (see Cai, para [0001]-[0002]).
Moreover, it would have been obvious to one of ordinary skill in the art at the time of the invention to include the system for a computer-aided warehouse space planning as taught by Cai with the Rorro and Yao combination, since the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
Claim 7 is rejected under 35 U.S.C. 103 as being unpatentable over Rorro and Yao, as applied above, and further in view of Witzig et al. (US 2024/0265314 A1) (hereinafter Witzig).
Claim 7:
Rorro and Yao do not specifically disclose wherein the model is run continuously to build inputs for the linear programming solver, wherein the model is iteratively run based on the input dataset, until optimal volume thresholds flowing through different forward pick location types is determined. In analogous art, Witzig discloses the following limitations:
wherein the model is run continuously to build inputs for the linear programming solver, wherein the model is iteratively run based on the input dataset, until optimal volume thresholds flowing through different forward pick location types is determined (see para [0021]-[0022], "[0021] In contrast, in the example embodiments, the optimizer may break-up the network into small sequences/segments, for example, each sequence of locations within the supply chain may be a segment that is individually considered by the optimizer. To start the optimization process, the software application may generate a mathematical model (e.g., mixed integer programming model, etc.) of the supply chain based data of the supply chain. The model may include variables and constraints (e.g., lot restrictions) that are imposed on the variables. The lot restrictions (e.g., incremental, minimum, etc.) represent different constraints within the supply chain. To generate an optimum configuration of the supply network, the system described herein may “solve” the mathematical model using a linear programming (LP) solver, a mixed-integer programming (MIP) solver, or the like. When solving the model, the software application may command the optimizer to incrementally enforce constraints such as hard caps into the relaxed model starting with a highest priority/dependent operation of the supply network which may be at the beginning. The software application may start by imposing restrictions in an incremental manner working from the highest priority operation to the lowest priority operation. After each imposition, a new solution may be generated by the optimizer which identifies an optimal flow of materials, goods, products, parts, etc., through the supply network. The flow may include locations, production attributes, transportation attributes, dependencies, and the like. This process may be iteratively repeated with new restrictions being added into the relaxed mathematical model at each iteration and solved by the optimizer. The result is many possible configurations of the supply network that can be compared to each other based on properties therein (e.g., cost, production, etc.) to select an optimal configuration of the supply network (i.e., a best configuration based on attributes therein). The optimal configuration returned by the optimizer can be converted into a graphical user interface." where it would be obvious to one of ordinary skill in the art that the optimal flow solution could be for the volume flow for pick locations)
It would have been obvious to one or ordinary skill in the art at the time of the invention to combine the teachings of Witzig with Rorro and Yao because iteratively running the model will enable more accurate results that can be used to make more effective decisions related to the supply chain (see Witzig, para [0001]-[0002]).
Moreover, it would have been obvious to one of ordinary skill in the art at the time of the invention to include the system for generating a model of an optimum flow of materials within a supply network as taught by Witzig with the Rorro and Yao combination, since the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
Claim 8 is rejected under 35 U.S.C. 103 as being unpatentable over Rorro and Yao, as applied above, and further in view of Sethuraman et al. (US 11,526,838 B1) (hereinafter Sethuraman)
Claim 8:
Rorro and Yao do not specifically disclose wherein performing the discrete event simulation comprises representing picking by container dwell times in both manual and automated picking areas/workstations, wherein dwell times are modeled using a probability distribution based on historical data, wherein the dwell times indicate how much capacity in each picking area is being utilized. In analogous art, Sethuraman discloses the following limitations:
wherein performing the discrete event simulation comprises representing picking by container dwell times in both manual and automated picking areas/workstations, wherein dwell times are modeled using a probability distribution based on historical data, wherein the dwell times indicate how much capacity in each picking area is being utilized (col 3, line 32-45, "Additionally, the capacity management system may utilize the machine learning techniques to determine a package dwell time probability associated with one or more packages to be delivered to the delivery locker. The dwell time probability may include an estimated probability that the packages will remain in the locker for a certain period of time before they are removed (e.g., before the customer picks up the package or the package is returned to the sender). For example, based on historical data, the dwell time probability may be determined to indicate a probability that a package will remain in the locker for a certain number of days at each shipping speed on each day during a predetermined time period" where it would be obvious to one of ordinary skill in the art that manual and automated picking area/workstation calculations using historical modeling could be made in the same way as for package dwell time)
It would have been obvious to one or ordinary skill in the art at the time of the invention to combine the teachings of Sethuraman with Rorro and Yao because including a determination of dwell time based on historical data enables more accurate and efficient management of unutilized capacity (see Sethuraman, col 1, line 14-32).
Moreover, it would have been obvious to one of ordinary skill in the art at the time of the invention to include the capacity management system for delivery lockers as taught by Sethuraman with the Rorro and Yao combination, since the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
Claims 9 is rejected under 35 U.S.C. 103 as being unpatentable over Rorro and Yao, as applied above, and further in view of Humphries et al. (US 2014/0200946 A1) (hereinafter Humphries)
Claim 9:
Rorro and Yao do not specifically disclose wherein performing the discrete event simulation comprises performing random replications by running a simulation model multiple times with different sets of random input values, to obtain a range of results and analyze statistical measures such as mean, standard deviation, confidence intervals, or percentiles and get eliminate results based on chance or bias. In analogous art, Humphries discloses the following limitations:
wherein performing the discrete event simulation comprises performing random replications by running a simulation model multiple times with different sets of random input values, to obtain a range of results and analyze statistical measures such as mean, standard deviation, confidence intervals, or percentiles and get eliminate results based on chance or bias (see para [0037], " As mentioned above, the optimization engine 120 runs a number (e.g. 10, 50, 100, 1000, etc.) of simulations for the generated inventory polices. In some of these embodiments, the optimization engine 120 first generates a random future demand based on the Monte Carlo probability distribution, and then simulates how each inventory policy would perform under the generated random future demand. In addition, the optimization engine 120 would also obtain a deviation between the inventory policy's associated future demand model, and the random future demand generated for each simulation.")
It would have been obvious to one or ordinary skill in the art at the time of the invention to combine the teachings of Humphries with Rorro and Yao because performing random replications to generate statistical data provides more information to make accurate proximations in decision making (see Humphries, [0005]-[0012]).
Moreover, it would have been obvious to one of ordinary skill in the art at the time of the invention to include the method for inventory optimization as taught by Humphries with the Rorro and Yao combination, since the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
Claims 10 is rejected under 35 U.S.C. 103 as being unpatentable over Rorro and Yao, as applied above, and further in view of Hinojosa et al. (US 2024/0417175 A1) (hereinafter Hinojosa).
Claim 10:
Rorro and Yao do not specifically disclose wherein the one or more processors are further configured to provide ongoing monitoring of benchmarked values pertaining to process path mix including an optimal number of units assigned to robots for picking tasks (ASRS) and an acceptable threshold that ensures uninterrupted flow during unit picking activities involving both robots (ASRS) and manual pickers. In analogous art, Hinojosa discloses the following limitations:
wherein the one or more processors are further configured to provide ongoing monitoring of benchmarked values pertaining to process path mix including an optimal number of units assigned to robots for picking tasks (ASRS) and an acceptable threshold that ensures uninterrupted flow during unit picking activities involving both robots (ASRS) and manual pickers (see para [0027]-[0028], showing process is using both manual and automated processes and pickers and see para [0038]-[0039], " Referring to FIG. 6, an exemplary field selection process 600 for selecting a unit sortation field 302 from among a plurality of unit sortation fields 302 is illustrated. The field selection process 600 determines which of the available unit sortation fields 302 a set of orders are to be released in. The field selection process 600 balances the workload across the multiple unit sortation fields 302. In one exemplary embodiment, the field selection process 600 is a heuristic algorithm and uses the following inputs: a maximum work in progress threshold for each unit sortation field 302 (i.e., could be expressed as a quantity of open orders); the number of available order consolidation totes for each unit sortation field 302; the number of pending donor tote retrievals for each unit sortation field 302; the number of pending sortation items for each unit sortation field 302; a shuttle and lift utilization in the automated retrieval and storage system (AS/RS) 402; and sortation equipment utilization for each unit sortation field 302. In step 602 of FIG. 6, the selection of a unit sortation field is initiated or begun by receiving the above described inputs to evaluate each of the unit sortation fields. In step 604 of FIG. 6, all unit sortation fields 302 that are eligible for the release of new orders are identified. For each unit sortation field 302, there could be a maximum threshold workload determining whether a particular unit sortation field 302 is eligible to release more order into or not. This threshold can be based upon a work-in-progress (WIP)-based system or by a number of available order consolidation totes in that unit sortation field 302 (i.e., a combination of the maximum WIP threshold for each unit sortation field 302 and the number of available order consolidation totes for each unit sortation field 302). Given all eligible unit sortation fields 302, the field selection process 600, in step 606 of FIG. 6, will select the unit sortation field 302 with the least amount of pending workload according to a ranking of unit sortation fields 302 with respect to their respective quantities of pending work/orders. Pending workload can be measured by the number of pending donor tote retrievals and/or the number of pending sortation items in this unit sortation field 302 depending on the current system bottleneck. A “current system bottleneck” will be calculated based on utilization levels in AS/RS 402 and unit sortation fields 302 (i.e., the shuttle and lift utilization in the automated retrieval and storage system (AS/RS) 402 and the sortation equipment utilization for each unit sortation field 302). For the output, in step 608 of FIG. 6, the field selection process 600 selects a unit sortation field 302 to release new orders in. The next step (in the over-all pre-sorting solution) would be to perform an order selection process 700 for selecting orders for the selected unit sortation field 302, given the selected unit sortation field 302. As a data-driven improvement to the field selection process 600, learning mode methods, such as, artificial intelligence (AI) learning, machine learning (ML), deep learning, quantum learning, and quantum machine learning methods, and the like, could be used to predict pending workload for each unit sortation field 302. In that case, a supervised learning algorithm such as random forest or boosted tree could be used to estimate total workload in hours to complete all pending orders in a unit sortation field 302. The training data should include information about the completion steps and time effort required at each step for historical orders. In another example, one or more learning algorithms, such as a hybrid learning algorithm, may be utilized to further optimize the process, including a balancing of the workload in an extremely short cycle time." where balancing the workload based on thresholds and reducing bottleneck can be considered to show uninterrupted flow would be obvious. Examiner further notes that "that ensures uninterrupted flow during picking" is considered intended use and not given patentable weight.).
It would have been obvious to one or ordinary skill in the art at the time of the invention to combine the teachings of Hinojosa with Rorro and Yao because having optimal number of units of ASRS enables more efficient operation of a distribution center (see Hinojosa, para [0002]-[0003]).
Moreover, it would have been obvious to one of ordinary skill in the art at the time of the invention to include the system for pre-sorting in order fulfillment facilities as taught by Hinojosa with the Rorro and Yao combination, since the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
Claim 16 is rejected under 35 U.S.C. 103 as being unpatentable over Rorro and Yao, as applied above, and further in view of Velten et al. (US 2023/0245061 A1) (hereinafter Velten).
Claim 16:
Rorro and Yao do not specifically disclose wherein the one or more processors are further configured to track metrics in real time, compare the metrics against predefined targets or benchmarks, and set up browser alerts or e-mail notifications based on thresholds being exceeded. In analogous art, Velten discloses the following limitations:
wherein the one or more processors are further configured to track metrics in real time, compare the metrics against predefined targets or benchmarks, and set up browser alerts or e-mail notifications based on thresholds being exceeded (see para [0016], " determining, by the control circuit, a set of categories of merchandise items whose first-time pick metrics are below a predetermined threshold; determining, by the control circuit, a subset from the set constituting a predetermined number of categories of merchandise items, the subset including predetermined core merchandise categories that are in the set of categories and including merchandise categories with the highest sales data relative to the other merchandise categories in the set of categories; and transmitting, by the control circuit, a notification identifying the subset of categories of merchandise items.")
It would have been obvious to one or ordinary skill in the art at the time of the invention to combine the teachings of Velten with Rorro and Yao because alerts based on such data can enable more attention to prioritize decisions related to inventory (see Velten, para [0003]-[0004]).
Moreover, it would have been obvious to one of ordinary skill in the art at the time of the invention to include the method for arranging merchandise at shelving locations as taught by Velten with the Rorro and Yao combination, since the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Srinivas et al. (US 2025/0066124 A1), a computerized warehouse management system that generates a plan for optimizing the order-picking operations for a collaborative human-robot order-picking system and is flexible and scalable to handle any facility layout, swarm of robots, multiple pickers, and logistical/operational constraints and the platform optimizes four key decisions to improve warehouse operations efficiency, including order batching, batch assignment to robots and pickers, batch sequencing, and collaborative human-robot routing
Gravelle et al. (CA 3119904 A1), an order fulfillment system including an automated storage and retrieval system (ASRS) structure, robotic vehicles, storage bins, and different service areas in a continuous arrangement positioned adjacent to an outer perimeter of the ASRS structure at one or more service levels of the ASRS structure
Tarczyński, "Linear programming models for optimal workload and batching in pick-and-pass warehousing systems", a paper about MILP models that optimize the order-picking process where the first model uses information about expected demand for items to solve the storage location problem and balance the workload across zones
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SUJAY KONERU whose telephone number is 571-270-3409. The examiner can normally be reached on Monday-Friday, 9 am to 5 pm.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Patricia Munson can be reached on 571- 270-5396. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/SUJAY KONERU/
Primary Examiner, Art Unit 3624