DETAILED ACTION
Status of Claims
This communication is the final action on the merits in response to the amendments and arguments filed on September 19, 2025. Claims 50 and 58 were amended. Claims 66-70 were added. Claims 50-70 are currently pending and have been examined.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 50-70 are rejected under 35 U.S.C. 103 as being unpatentable over Malecha et al. (US-20190347606) in view of Wilson et al. (US-20170161312) and Beigl et al. (US-20030222762).
Claim 50
Malecha teaches the following limitations:
A computer-implemented method for apportioning inventory units to a plurality of warehouse nodes to meet desired service levels to replenish retail stores, the computer- implemented method comprising: receiving, from a merchant, a placement request comprising (i) locations of one or more retail stores where inventory units of the merchant are to be shipped for sale to consumers and (ii) a shipping speed which specifies a desired time frame in which a shipment of inventory units from a storage warehouse is to be delivered to a retail store ([0039] The replenishment management system 204 also receives inventory adjustments from a user interface 214. Inventory adjustments are instructions received from a user to modify inventory levels at one or more locations or nodes within the supply chain; [0040] the user interface 214 can provide user access to view and set inventory levels and inventory fulfillment thresholds for retail locations in the supply chain; [0099] the method 500 can generate and send instructions to the order management system within the enterprise supply chain as illustrated in FIGS. 1-3, above, based, for example, on desired inventory levels and/or positions within the supply chain network. The supply chain includes a plurality of retail locations and a plurality of distribution locations… In some instances, the method 500 is performed using a software tool such as can include the inventory allocation engine 320, the inventory movement analyzer 303, and which exposes a user interface 214 for user interaction; [0101] At operation 502, the optimal inventory location for each of a plurality of items at each of the plurality of retail locations and distribution locations is determined. Optimal inventory locations are determined by the inventory allocation engine 320 of FIG. 3. Inventory is held at these locations in order to quickly replenish stock in response to expected customer demand from stores and online sales; [0106] At operation 506, the time when an inventory item is needed is determined; [0108] At operation 508, instructions are sent to the order management system. The instructions determine how much inventory should be carried at any time period, where the inventory items should be located, and when the inventory items are needed. The order management system directs movement of inventory to retail stores and distribution centers that require replenishment to achieve the optimal inventory positions that were determined);
receiving, from the merchant, demand data associated with the one or more retail stores that sell merchant inventory units to consumers, wherein the demand data is based on (a) historical demand of the inventory units and/or (b) anticipated demand for the inventory units due to current or upcoming events ([0102] The optimal inventory location for each item is determined by a forecasted demand probability distribution for each item at each location at each time period. The demand probability distribution determines the probability of selling or fulfilling a particular quantity of an item at each location, at each time period. A time period may be a day of the week, and considers the time of the year. The demand probability distribution also considers upcoming known promotions and historical lost sales due to stock-outs; [0103] the demand probability distribution for each of a plurality of retail locations can be calculated for a particular item or items, and these probability distributions can be used in determining a probability distribution for demand at a flow center servicing those retail locations; [0105] Desired inventory levels are determined by the guest availability goal for each item at each location at different time periods. The availability goal is determined by aligning the importance of each item to customers at each time period. For example, pumpkin pie filling has a higher availability goal during Thanksgiving because customers desire pumpkin pie filling at this time period. During other time periods, pumpkin pie filling has a low availability goal because it is less desirable to customers);
selecting a set of warehouse nodes from a warehouse node database that: are suitable for handling a type of inventory unit being sold by the merchant ([0070] An item attribute database 310 stores information about attributes of the items or products that are being shipped and sold within the supply chain. Attributes of the products include weight, volume, units, and whether particular handling is required. Special handling may be required for items that require refrigeration, items that are flammable, or other hazardous materials in items. The transportation management system 206 relies on information in the item attribute database 310 to select equipment for transporting items as well as managing storage of the items in warehouses; [0074] Warehouse databases 315 store information about warehouses (distribution centers) within the supply chain. The information includes data about available storage space, availability of specialized storage space (e.g. refrigerator or freezer space), and whether certain areas within the warehouse are reserved for particular items or purposes); and
are served by carriers that deliver to a geographical region encompassing the locations of the one or more retail stores and within the specified shipping speed ([0101] At operation 502, the optimal inventory location for each of a plurality of items at each of the plurality of retail locations and distribution locations is determined. Optimal inventory locations are determined by the inventory allocation engine 320 of FIG. 3. Inventory is held at these locations in order to quickly replenish stock in response to expected customer demand from stores and online sales; [0031] A variety of products are prepared for shipment to one or more flow centers 106. The flow centers 106 are typically positioned to enable quick shipment to one or more retail stores 108. Each flow center 106 may supply inventory to multiple retail stores 108; [0033] It is noted that, between receive centers 108, flow centers 106, and stores 108, there may be preexisting, predetermined delivery routes established. For example, there may be daily or weekly transit routes between a receive center and one or more flow centers. The receive center can provide to the flow centers the selection of individual items that are needed by stores 108 serviced by the one or more flow centers proximate to and/or servicing those stores. The flow centers can also have daily or other periodic transportation routes established to stores that are serviced, thereby ensuring prompt replenishment of items at stores in response to item sales),
wherein warehouse nodes maintain warehouse node information ([0053] The warehouse management engine 308 manages all events that occur at a warehouse or distribution center in the process of moving inventory through the supply chain. The functions of the warehouse management engine 308 differ for each node depending on that node's role. Warehouse operations are different between receive centers, flow centers, and storage in retail stores. The warehouse management system 308 relies on information supplied by the item attribute database 310 and warehouse databases 315; [0074] Warehouse databases 315 store information about warehouses (distribution centers) within the supply chain)
wherein the warehouse nodes of the set are owned by operators different from the merchant ([0029] FIG. 1 illustrates a schematic diagram 100 of an example supply chain for a retail enterprise. The diagram 100 illustrates the flow of inventory from vendor 102 to customer 110. The inventory moves through various nodes to arrive at the customer. In this example, the nodes include a receive center 104, two flow centers 106a, 106b, four retail stores 108a, 108b, 108c, 108d, and three customer residences 110a, 110b, 110c. In practice, the supply chain could include many more nodes in different proportions);
warehouse node information from the set of warehouse nodes ([0053] The warehouse management engine 308 manages all events that occur at a warehouse or distribution center in the process of moving inventory through the supply chain. The functions of the warehouse management engine 308 differ for each node depending on that node's role. Warehouse operations are different between receive centers, flow centers, and storage in retail stores. The warehouse management system 308 relies on information supplied by the item attribute database 310 and warehouse databases 315; [0074] Warehouse databases 315 store information about warehouses (distribution centers) within the supply chain)
apportioning a number of inventory units of the inventory units to warehouse nodes of the selected set of warehouse nodes, wherein the apportioned number of inventory units is based in part on the received demand data ([0101] At operation 502, the optimal inventory location for each of a plurality of items at each of the plurality of retail locations and distribution locations is determined. Optimal inventory locations are determined by the inventory allocation engine 320 of FIG. 3. Inventory is held at these locations in order to quickly replenish stock in response to expected customer demand from stores and online sales; [0102] The optimal inventory location for each item is determined by a forecasted demand probability distribution for each item at each location at each time period. The demand probability distribution determines the probability of selling or fulfilling a particular quantity of an item at each location, at each time period. A time period may be a day of the week, and considers the time of the year. The demand probability distribution also considers upcoming known promotions and historical lost sales due to stock-outs; [0104] At operation 504, the inventory levels of the plurality of items at each of the nodes is determined. As described above, the optimal inventory location dictate the number of units of each item that are to be held at each node within the supply chain for a given timeframe. Once optimal inventory positions are established, the inventory management system 202 will use the current inventory levels (monitored by the Inventory Tracking Engine 302) and calculated future optimal inventory positions (including the time they are needed in the receiving destination) to pre-position inventory for upcoming events (promotions, sales plans, new item sets, etc.) or other expected changes in sales patterns);
tracking inventory levels at the selected set of warehouse nodes as inventory is shipped to retail stores ([0101] the inventory positions are monitored by the inventory-tracking engine 302. The inventory-tracking engine 302 receives updates on inventory positions from the transportation management system 206 and the warehouse management engine 308 as items flows through the supply chain. Changes are recorded in the inventory data store 314; [0046] The inventory-tracking engine 302 operates to monitor inventory levels at each warehouse and store in the supply chain. The inventory-tracking engine 302 also receives inputs from the transportation management system 206 regarding the movement of inventory between nodes. Inventory coming into the supply chain from vendors or returns is recorded by the inventory tracking engine 302 as well as inventory leaving the supply chain to satisfy sales or inventory removal. Updates to inventory records are saved in an inventory data store 314. The inventory-tracking engine 302 serves as a single source of information for that status of every aspect of inventory within a supply chain for a retail enterprise); and
if an inventory level at a warehouse node falls below a predetermined threshold, enabling replenishment of inventory at the warehouse node ([0047] The inventory movement analyzer 303 receives status updates from the inventory-tracking engine 302 and analyzes the changing inventory levels at each node within the supply chain to determine if any inventory movements are needed based on current inventory levels at the plurality of nodes, as well as desired inventory levels at each of those nodes. The inventory movement analyzer 303 receives inventory requests from the replenishment management system 204, the inventory removal system 224, and the returns management system 226. Based on these inventory requests, the inventory movement analyzer 303 determines whether the inventory levels are at their preferred levels. The preferred levels are determined on a per-item basis periodically; in some instances, preferred levels are determined alongside current inventory levels for each day. The inventory movement analyzer 303 evaluates the current inventory levels at each node and compares them to that day's goal and the following day's goal to determine if inventory movements need to be changed to redistribute inventory
[0048] The inventory movement analyzer 303 also determines how items should be moved between nodes of the supply chain, based on the inventory goals. Inventory goals can be set, for example, based on output from an inventory allocation engine 320, described in further detail below. If inventory is available within the supply chain to satisfy an inventory request and the costs are not too high to move the inventory, the inventory movement analyzer 303 will send a signal to the transfer order generator 304. If the inventory movement analyzer 303 determines that there is insufficient supply of an item within the supply chain to satisfy an inventory request or that the cost of moving items outweighs the cost of ordering new stock, the inventory movement analyzer 303 sends a signal to the purchase order generator 306).
However, Malecha does not explicitly teach the following limitations:
maintain… information in a non- standardized format, and
converting non-standardized… information… into a plurality of node data sets of a standardized format;
transmitting an alert to the merchant if an inventory level at a warehouse node falls below a predetermined threshold,
Wilson, in the same field of endeavor, teaches the following limitations:
maintain… information in a non- standardized format ([0003] information system interface engines have been designed that operate to receive information in dissimilar formats), and
converting non-standardized… information… into a plurality of node data sets of a standardized format ([0003] information system interface engines have been designed that operate to receive information in dissimilar formats, and convert this information to a standard format so that it can be operated on by a single user application; [0014] The ISI 210 generally operates to receive messages with information in dissimilar formats, parses the information in the messages in order to detect information of interest (critical information) and then maps the critical information into a standard format that allows the ENS 200 to operate on the information, and identifies the message type… Message types in the context of this description can mean a formatted (i.e., HL7) message generated by different information systems (ADT, radiology, cardiology, patient monitoring systems). The ISI 210 described with reference to FIG. 2 is configured to receive messages from a core information system such as an ADT system, and to receive messages from a non-core IS, such as a cardiology system. The ISI can operate to parse information in a message received from the ADT system in order to detect critical information (i.e., patient name and corresponding medical record number) and then maintain this critical patient information in a store or data repository 230, and the ISI can operate to parse information in a message from the cardiology IS in order to detect critical information);
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to have modified the information receiving and maintaining features of Malecha with the limitations taught by Wilson. One of ordinary skill in the art would have been motivated to make this modification for the benefit of minimizing the number of applications needed to access information from dissimilar systems (Wilson – [0003]).
However, Malecha, in combination with Wilson, does not explicitly teach the following limitations:
transmitting an alert to the merchant if an inventory level at a warehouse node falls below a predetermined threshold,
Beigl, in the same field of endeavor, teaches the following limitations:
transmitting an alert to the merchant if an inventory level at a warehouse node falls below a predetermined threshold ([0008] The items may be products in a store or in a warehouse and the surfaces may be the surfaces of one or more store shelves or warehouse shelves. The computer may generate a message when the number of items placed on the surfaces of store shelves or warehouse shelves decreases below a predetermined threshold. The message may be an out-of-stock message and the items may be associated with a specific item manufacturer name or item product name),
This known technique is applicable to the system of Malecha, in combination with Wilson, as they both share characteristics and capabilities, namely, they are directed to tracking inventory and movement of goods in a supply chain. One of ordinary skill in the art, before the effective filing date of the claimed invention, would have recognized that applying the known technique of Beigl would have yielded predictable results and resulted in an improved system. It would have been recognized that applying the technique of Beigl to the teachings of Malecha, in combination with Wilson, would have yielded predictable results because the level of one of ordinary skill in the art would have known to incorporate such features (i.e., transmitting an alert when inventory levels are low) into similar systems.
Claim 51 (and Similarly Claim 59)
Malecha further teaches the following limitations:
further comprising: receiving, from one or more warehouse nodes, warehouse node information ([0053] The warehouse management engine 308 manages all events that occur at a warehouse or distribution center in the process of moving inventory through the supply chain. The functions of the warehouse management engine 308 differ for each node depending on that node's role. Warehouse operations are different between receive centers, flow centers, and storage in retail stores. The warehouse management system 308 relies on information supplied by the item attribute database 310 and warehouse databases 315; [0074] Warehouse databases 315 store information about warehouses (distribution centers) within the supply chain)
storing, in the warehouse node database… plurality of node data ([0074] Warehouse databases 315 store information about warehouses (distribution centers) within the supply chain)
However, Malecha does not explicitly teach the following limitations:
receiving… information in a non-standardized format;
converting the non-standardized… information into a plurality of node data sets of a standardized format, wherein each node data set is associated with a corresponding… node; and
storing, in the… database, the plurality of node data sets of the standardized format.
Wilson, in the same field of endeavor, teaches the following limitations:
receiving… information in a non-standardized format ([0003] information system interface engines have been designed that operate to receive information in dissimilar formats);
converting the non-standardized… information into a plurality of node data sets of a standardized format, wherein each node data set is associated with a corresponding… node ([0003] information system interface engines have been designed that operate to receive information in dissimilar formats, and convert this information to a standard format so that it can be operated on by a single user application; [0014] The ISI 210 generally operates to receive messages with information in dissimilar formats, parses the information in the messages in order to detect information of interest (critical information) and then maps the critical information into a standard format that allows the ENS 200 to operate on the information, and identifies the message type… Message types in the context of this description can mean a formatted (i.e., HL7) message generated by different information systems (ADT, radiology, cardiology, patient monitoring systems). The ISI 210 described with reference to FIG. 2 is configured to receive messages from a core information system such as an ADT system, and to receive messages from a non-core IS, such as a cardiology system. The ISI can operate to parse information in a message received from the ADT system in order to detect critical information (i.e., patient name and corresponding medical record number) and then maintain this critical patient information in a store or data repository 230, and the ISI can operate to parse information in a message from the cardiology IS in order to detect critical information); and
storing, in the… database, the plurality of node data sets of the standardized format ([0014] The ISI 210 generally operates to receive messages with information in dissimilar formats, parses the information in the messages in order to detect information of interest (critical information) and then maps the critical information into a standard format that allows the ENS 200 to operate on the information, and identifies the message type… The ISI can operate to parse information in a message received from the ADT system in order to detect critical information (i.e., patient name and corresponding medical record number) and then maintain this critical patient information in a store or data repository 230).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to have modified the information receiving and maintaining features of Malecha with the limitations taught by Wilson. One of ordinary skill in the art would have been motivated to make this modification for the benefit of minimizing the number of applications needed to access information from dissimilar systems (Wilson – [0003]).
Claim 52 (and Similarly Claim 60)
Malecha further teaches the following limitations:
receiving warehouse node information ([0053] The warehouse management engine 308 manages all events that occur at a warehouse or distribution center in the process of moving inventory through the supply chain. The functions of the warehouse management engine 308 differ for each node depending on that node's role. Warehouse operations are different between receive centers, flow centers, and storage in retail stores. The warehouse management system 308 relies on information supplied by the item attribute database 310 and warehouse databases 315; [0074] Warehouse databases 315 store information about warehouses (distribution centers) within the supply chain)
However, Malecha does not explicitly teach the following limitations:
receiving… information in a non-standardized format comprises: receiving first… information in a first format generated using a first software platform at a node device associated with a first… node of the one or more… nodes; and
receiving second… information in a second format generated using a second software platform different from the first software platform at another node device associated with a second… node of the one or more… nodes.
Wilson, in the same field of endeavor, teaches the following limitations:
receiving… information in a non-standardized format comprises: receiving first… information in a first format generated using a first software platform at a node device associated with a first… node of the one or more… nodes ([0014] The ISI 210 generally operates to receive messages with information in dissimilar formats, parses the information in the messages in order to detect information of interest (critical information) and then maps the critical information into a standard format that allows the ENS 200 to operate on the information, and identifies the message type... Message types in the context of this description can mean a formatted (i.e., HL7) message generated by different information systems (ADT, radiology, cardiology, patient monitoring systems). The ISI 210 described with reference to FIG. 2 is configured to receive messages from a core information system such as an ADT system, and to receive messages from a non-core IS, such as a cardiology system); and
receiving second… information in a second format generated using a second software platform different from the first software platform at another node device associated with a second… node of the one or more… nodes ([0014] The ISI 210 generally operates to receive messages with information in dissimilar formats, parses the information in the messages in order to detect information of interest (critical information) and then maps the critical information into a standard format that allows the ENS 200 to operate on the information, and identifies the message type... Message types in the context of this description can mean a formatted (i.e., HL7) message generated by different information systems (ADT, radiology, cardiology, patient monitoring systems). The ISI 210 described with reference to FIG. 2 is configured to receive messages from a core information system such as an ADT system, and to receive messages from a non-core IS, such as a cardiology system).
This known technique is applicable to the system of Malecha as they both share characteristics and capabilities, namely, they are directed to systems that receive and maintain information from various sources. One of ordinary skill in the art, before the effective filing date of the claimed invention, would have recognized that applying the known technique of Wilson would have yielded predictable results and resulted in an improved system. It would have been recognized that applying the technique of Wilson to the teachings of Malecha would have yielded predictable results because the level of one of ordinary skill in the art would have known to incorporate such features (i.e., data received from different sources in different formats using different software platforms) into similar systems.
Claim 53 (and Similarly Claims 61 and 67)
Malecha further teaches the following limitations:
wherein apportioning the number of inventory units comprises: calculating, for each warehouse node of the selected set of warehouse nodes, a demand level at a corresponding geographic region ([0027] methods and systems for determining per-SKU, per store forecasts on a daily basis for purposes of determining inventory movement requirements. In particular, the supply chain is for a collection of retail stores that also operates an online ordering system. The inventory management system operates to monitor and manage inventory levels in a plurality of nodes. Nodes can include retail stores and warehouses. Warehouses serve to store inventory and also function as distribution centers. The distribution centers can have particular purposes such as a receive center for receiving products from vendors and preparing them for distribution to other nodes, or a flow center for holding individual, unit level inventory stock on a short term basis, for distribution to retail stores and individual customers. The inventory management system determines how much inventory is needed at each store on daily basis, such that the entire system need not recalculate inventory requirements in response to each individual event. The movements of inventory can be based on expected demand as well as reactions to actual demand from customers); and
calculating an amount of inventory units to be apportioned to each warehouse node to meet a corresponding demand level ([0076] The proactive replenishment engine 316 receives proactive demand signals from the demand forecast engine 212 and user interface 214. These demand signals come in the form of a forecasted demand probability distribution that is determined for each item, at each location, for a given timeframe. Demand probability distributions are further described below. The demand probability distributions are utilized by the inventory allocation engine 320 to determine the optimal inventory positions of each item in the supply chain. The proactive replenishment engine 316 operates to ensure that inventory is replenished to keep up with anticipated demand; [0087] The first problem of determining the optimal inventory positions can be solved by leveraging and expanding upon an optimal inventory policy approach for multi-echelon supply chains developed by Clark-Scarf. Clark-Scarf's approach will do joint optimization across all nodes considering inputs such as forecasted probability of demand, availability goals and trade off costs (cost to hold, cost to move, etc.) for each node to support availability for a customer. The forecasted probability of demand is determined for each item at each location for a given timeframe by the demand forecast engine 212. This determines the probability of selling or fulfilling a particular quantity of an item, at each location, each day of the week, and whether that materially changes based on the time of year. The forecasted probability of demand also accounts for upcoming known promotions as well as historical lost sales due to stock-outs).
Claim 54 (and Similarly Claims 62 and 68)
Malecha further teaches the following limitations:
further comprising: calculating the predetermined threshold as a function of one or more of a lead time for shipping the inventory units to the warehouse node, an average periodic demand, or an amount of usage during the lead time ([0035] a supply chain management system is provided that assists in coordination of product shipments among nodes of the supply chain, and uses inventory models to automatically rebalance inventory within the supply chain of the enterprise to ensure predicted and actual item demand from customers of the enterprise is fulfilled to a predetermined threshold success rate. The supply chain management system allows for balancing of items across the supply chain based on inventory and demand models, as well as real time demand signals, and performs automated generation of purchase and transfer orders throughout the supply chain based on such demand and lead time calculations between paints both within and external to the supply chain; [0085] The availability goal for each item at each location for different time periods must also be determined. This applies to both online and in-store purchase. The availability goal determines how much stock is needed to meet an expected demand from customers. The current inventory levels must be determined for each node and the amount of time it will take to transport inventory between nodes must be determined).
Claim 55 (and Similarly Claims 63 and 69)
Malecha further teaches the following limitations:
further comprising: determining a ranking of the warehouse nodes of the selected set of warehouse nodes based on one or more of: proximity of each warehouse node to a requested delivery region, shipment time to a requested delivery region, storage costs, shipment costs, or warehouse node quality ([0008] a method of managing inventory items within a supply chain comprises receiving, at a software tool implemented on a computing system, inputs related to an inventory item. The inputs include a cost of holding each of the plurality of inventory items at a location type. The method further includes determining, individually for each inventory item of a plurality of inventory items, an optimal inventory balance across a plurality of locations, wherein the optimal inventory balance is a predetermined statistical availability level set based on a desired customer availability of the inventory item, and wherein the plurality of locations include a plurality of locations selected from among retail locations, receiving centers, and flow centers; [0028] Inventory stocks are continually rebalanced throughout the supply chain in order to position items in locations where they are mostly likely to be needed in order to reduce shipping time and storage time; [0082] The inventory allocation engine 320 operates to determine optimal inventory positions by item, location, and timeframe for each node within the supply chain).
Claim 56 (and Similarly Claims 64 and 70)
Malecha further teaches the following limitations:
wherein apportioning the number of inventory units comprises determining, in order of the ranking of the warehouse nodes of the selected set of warehouse nodes, an apportionment of the number of inventory units ([0008] a method of managing inventory items within a supply chain comprises receiving, at a software tool implemented on a computing system, inputs related to an inventory item. The inputs include a cost of holding each of the plurality of inventory items at a location type. The method further includes determining, individually for each inventory item of a plurality of inventory items, an optimal inventory balance across a plurality of locations, wherein the optimal inventory balance is a predetermined statistical availability level set based on a desired customer availability of the inventory item, and wherein the plurality of locations include a plurality of locations selected from among retail locations, receiving centers, and flow centers; [0028] Inventory stocks are continually rebalanced throughout the supply chain in order to position items in locations where they are mostly likely to be needed in order to reduce shipping time and storage time; [0082] The inventory allocation engine 320 operates to determine optimal inventory positions by item, location, and timeframe for each node within the supply chain).
Claim 57 (and Similarly Claim 65)
Malecha further teaches the following limitations:
further comprising: responsive to determining that the inventory level at a warehouse node has fallen below the predetermined threshold, triggering reapportionment of the inventory units without instructions from the merchant ([0035] a supply chain management system is provided that assists in coordination of product shipments among nodes of the supply chain, and uses inventory models to automatically rebalance inventory within the supply chain of the enterprise to ensure predicted and actual item demand from customers of the enterprise is fulfilled to a predetermined threshold success rate. The supply chain management system allows for balancing of items across the supply chain based on inventory and demand models, as well as real time demand signals, and performs automated generation of purchase and transfer orders throughout the supply chain based on such demand and lead time calculations between paints both within and external to the supply chain; [0047] The inventory movement analyzer 303 receives status updates from the inventory-tracking engine 302 and analyzes the changing inventory levels at each node within the supply chain to determine if any inventory movements are needed based on current inventory levels at the plurality of nodes, as well as desired inventory levels at each of those nodes. The inventory movement analyzer 303 receives inventory requests from the replenishment management system 204, the inventory removal system 224, and the returns management system 226. Based on these inventory requests, the inventory movement analyzer 303 determines whether the inventory levels are at their preferred levels. The preferred levels are determined on a per-item basis periodically; in some instances, preferred levels are determined alongside current inventory levels for each day. The inventory movement analyzer 303 evaluates the current inventory levels at each node and compares them to that day's goal and the following day's goal to determine if inventory movements need to be changed to redistribute inventory; [0048] The inventory movement analyzer 303 also determines how items should be moved between nodes of the supply chain, based on the inventory goals. Inventory goals can be set, for example, based on output from an inventory allocation engine 320, described in further detail below. If inventory is available within the supply chain to satisfy an inventory request and the costs are not too high to move the inventory, the inventory movement analyzer 303 will send a signal to the transfer order generator 304. If the inventory movement analyzer 303 determines that there is insufficient supply of an item within the supply chain to satisfy an inventory request or that the cost of moving items outweighs the cost of ordering new stock, the inventory movement analyzer 303 sends a signal to the purchase order generator 306).
Claim 58 (and Similarly Claim 66)
Malecha teaches the following limitations:
A computer-implemented method for apportioning inventory units to a plurality of warehouse nodes to meet desired service levels to replenish retail stores, the computer- implemented method comprising: receiving, from a merchant, locations of one or more retail stores where inventory units of the merchant are to be shipped for sale to consumers ([0039] The replenishment management system 204 also receives inventory adjustments from a user interface 214. Inventory adjustments are instructions received from a user to modify inventory levels at one or more locations or nodes within the supply chain; [0040] the user interface 214 can provide user access to view and set inventory levels and inventory fulfillment thresholds for retail locations in the supply chain; [0099] the method 500 can generate and send instructions to the order management system within the enterprise supply chain as illustrated in FIGS. 1-3, above, based, for example, on desired inventory levels and/or positions within the supply chain network. The supply chain includes a plurality of retail locations and a plurality of distribution locations; [0101] At operation 502, the optimal inventory location for each of a plurality of items at each of the plurality of retail locations and distribution locations is determined. Optimal inventory locations are determined by the inventory allocation engine 320 of FIG. 3. Inventory is held at these locations in order to quickly replenish stock in response to expected customer demand from stores and online sales);
receiving, from the merchant, a shipping speed which specifies a desired time frame in which a shipment of inventory units from a storage warehouse is to be delivered to a retail store ([0039] The replenishment management system 204 also receives inventory adjustments from a user interface 214. Inventory adjustments are instructions received from a user to modify inventory levels at one or more locations or nodes within the supply chain; [0040] the user interface 214 can provide user access to view and set inventory levels and inventory fulfillment thresholds for retail locations in the supply chain; [0106] At operation 506, the time when an inventory item is needed is determined; [0108] At operation 508, instructions are sent to the order management system. The instructions determine how much inventory should be carried at any time period, where the inventory items should be located, and when the inventory items are needed. The order management system directs movement of inventory to retail stores and distribution centers that require replenishment to achieve the optimal inventory positions that were determined);
receiving, from the merchant, demand data associated with the one or more retail stores that sell merchant inventory units to consumers, wherein the demand data is based on (a) historical demand of the inventory units and/or (b) anticipated demand for the inventory units due to current or upcoming events ([0102] The optimal inventory location for each item is determined by a forecasted demand probability distribution for each item at each location at each time period. The demand probability distribution determines the probability of selling or fulfilling a particular quantity of an item at each location, at each time period. A time period may be a day of the week, and considers the time of the year. The demand probability distribution also considers upcoming known promotions and historical lost sales due to stock-outs; [0103] the demand probability distribution for each of a plurality of retail locations can be calculated for a particular item or items, and these probability distributions can be used in determining a probability distribution for demand at a flow center servicing those retail locations; [0105] Desired inventory levels are determined by the guest availability goal for each item at each location at different time periods. The availability goal is determined by aligning the importance of each item to customers at each time period. For example, pumpkin pie filling has a higher availability goal during Thanksgiving because customers desire pumpkin pie filling at this time period. During other time periods, pumpkin pie filling has a low availability goal because it is less desirable to customers);
selecting a set of warehouse nodes from a warehouse node database that: are suitable for handling a type of inventory unit being sold by the merchant ([0070] An item attribute database 310 stores information about attributes of the items or products that are being shipped and sold within the supply chain. Attributes of the products include weight, volume, units, and whether particular handling is required. Special handling may be required for items that require refrigeration, items that are flammable, or other hazardous materials in items. The transportation management system 206 relies on information in the item attribute database 310 to select equipment for transporting items as well as managing storage of the items in warehouses; [0074] Warehouse databases 315 store information about warehouses (distribution centers) within the supply chain. The information includes data about available storage space, availability of specialized storage space (e.g. refrigerator or freezer space), and whether certain areas within the warehouse are reserved for particular items or purposes); and
are served by carriers that deliver to a geographical region encompassing the locations of the one or more retail stores and within the specified shipping speed ([0101] At operation 502, the optimal inventory location for each of a plurality of items at each of the plurality of retail locations and distribution locations is determined. Optimal inventory locations are determined by the inventory allocation engine 320 of FIG. 3. Inventory is held at these locations in order to quickly replenish stock in response to expected customer demand from stores and online sales; [0031] A variety of products are prepared for shipment to one or more flow centers 106. The flow centers 106 are typically positioned to enable quick shipment to one or more retail stores 108. Each flow center 106 may supply inventory to multiple retail stores 108; [0033] It is noted that, between receive centers 108, flow centers 106, and stores 108, there may be preexisting, predetermined delivery routes established. For example, there may be daily or weekly transit routes between a receive center and one or more flow centers. The receive center can provide to the flow centers the selection of individual items that are needed by stores 108 serviced by the one or more flow centers proximate to and/or servicing those stores. The flow centers can also have daily or other periodic transportation routes established to stores that are serviced, thereby ensuring prompt replenishment of items at stores in response to item sales),
wherein warehouse nodes maintain warehouse node information ([0053] The warehouse management engine 308 manages all events that occur at a warehouse or distribution center in the process of moving inventory through the supply chain. The functions of the warehouse management engine 308 differ for each node depending on that node's role. Warehouse operations are different between receive centers, flow centers, and storage in retail stores. The warehouse management system 308 relies on information supplied by the item attribute database 310 and warehouse databases 315; [0074] Warehouse databases 315 store information about warehouses (distribution centers) within the supply chain)
wherein the warehouse nodes of the set are owned by operators different from the merchant ([0029] FIG. 1 illustrates a schematic diagram 100 of an example supply chain for a retail enterprise. The diagram 100 illustrates the flow of inventory from vendor 102 to customer 110. The inventory moves through various nodes to arrive at the customer. In this example, the nodes include a receive center 104, two flow centers 106a, 106b, four retail stores 108a, 108b, 108c, 108d, and three customer residences 110a, 110b, 110c. In practice, the supply chain could include many more nodes in different proportions);
warehouse node information from the set of warehouse nodes ([0053] The warehouse management engine 308 manages all events that occur at a warehouse or distribution center in the process of moving inventory through the supply chain. The functions of the warehouse management engine 308 differ for each node depending on that node's role. Warehouse operations are different between receive centers, flow centers, and storage in retail stores. The warehouse management system 308 relies on information supplied by the item attribute database 310 and warehouse databases 315; [0074] Warehouse databases 315 store information about warehouses (distribution centers) within the supply chain)
apportioning a number of inventory units of the inventory units to warehouse nodes of the selected set of warehouse nodes, wherein the apportioned number of inventory units is based in part on the received demand data ([0101] At operation 502, the optimal inventory location for each of a plurality of items at each of the plurality of retail locations and distribution locations is determined. Optimal inventory locations are determined by the inventory allocation engine 320 of FIG. 3. Inventory is held at these locations in order to quickly replenish stock in response to expected customer demand from stores and online sales; [0102] The optimal inventory location for each item is determined by a forecasted demand probability distribution for each item at each location at each time period. The demand probability distribution determines the probability of selling or fulfilling a particular quantity of an item at each location, at each time period. A time period may be a day of the week, and considers the time of the year. The demand probability distribution also considers upcoming known promotions and historical lost sales due to stock-outs; [0104] At operation 504, the inventory levels of the plurality of items at each of the nodes is determined. As described above, the optimal inventory location dictate the number of units of each item that are to be held at each node within the supply chain for a given timeframe. Once optimal inventory positions are established, the inventory management system 202 will use the current inventory levels (monitored by the Inventory Tracking Engine 302) and calculated future optimal inventory positions (including the time they are needed in the receiving destination) to pre-position inventory for upcoming events (promotions, sales plans, new item sets, etc.) or other expected changes in sales patterns);
tracking inventory levels at the selected set of warehouse nodes as inventory is shipped to retail stores ([0101] the inventory positions are monitored by the inventory-tracking engine 302. The inventory-tracking engine 302 receives updates on inventory positions from the transportation management system 206 and the warehouse management engine 308 as items flows through the supply chain. Changes are recorded in the inventory data store 314; [0046] The inventory-tracking engine 302 operates to monitor inventory levels at each warehouse and store in the supply chain. The inventory-tracking engine 302 also receives inputs from the transportation management system 206 regarding the movement of inventory between nodes. Inventory coming into the supply chain from vendors or returns is recorded by the inventory tracking engine 302 as well as inventory leaving the supply chain to satisfy sales or inventory removal. Updates to inventory records are saved in an inventory data store 314. The inventory-tracking engine 302 serves as a single source of information for that status of every aspect of inventory within a supply chain for a retail enterprise); and
if an inventory level at a warehouse node falls below a predetermined threshold, enabling replenishment of inventory at the warehouse node ([0047] The inventory movement analyzer 303 receives status updates from the inventory-tracking engine 302 and analyzes the changing inventory levels at each node within the supply chain to determine if any inventory movements are needed based on current inventory levels at the plurality of nodes, as well as desired inventory levels at each of those nodes. The inventory movement analyzer 303 receives inventory requests from the replenishment management system 204, the inventory removal system 224, and the returns management system 226. Based on these inventory requests, the inventory movement analyzer 303 determines whether the inventory levels are at their preferred levels. The preferred levels are determined on a per-item basis periodically; in some instances, preferred levels are determined alongside current inventory levels for each day. The inventory movement analyzer 303 evaluates the current inventory levels at each node and compares them to that day's goal and the following day's goal to determine if inventory movements need to be changed to redistribute inventory
[0048] The inventory movement analyzer 303 also determines how items should be moved between nodes of the supply chain, based on the inventory goals. Inventory goals can be set, for example, based on output from an inventory allocation engine 320, described in further detail below. If inventory is available within the supply chain to satisfy an inventory request and the costs are not too high to move the inventory, the inventory movement analyzer 303 will send a signal to the transfer order generator 304. If the inventory movement analyzer 303 determines that there is insufficient supply of an item within the supply chain to satisfy an inventory request or that the cost of moving items outweighs the cost of ordering new stock, the inventory movement analyzer 303 sends a signal to the purchase order generator 306).
However, Malecha does not explicitly teach the following limitations:
maintain… information in a non- standardized format, and
converting non-standardized… information… into a plurality of node data sets of a standardized format;
transmitting an alert to the merchant if an inventory level at a warehouse node falls below a predetermined threshold,
Wilson, in the same field of endeavor, teaches the following limitations:
maintain… information in a non- standardized format ([0003] information system interface engines have been designed that operate to receive information in dissimilar formats), and
converting non-standardized… information… into a plurality of node data sets of a standardized format ([0003] information system interface engines have been designed that operate to receive information in dissimilar formats, and convert this information to a standard format so that it can be operated on by a single user application; [0014] The ISI 210 generally operates to receive messages with information in dissimilar formats, parses the information in the messages in order to detect information of interest (critical information) and then maps the critical information into a standard format that allows the ENS 200 to operate on the information, and identifies the message type… Message types in the context of this description can mean a formatted (i.e., HL7) message generated by different information systems (ADT, radiology, cardiology, patient monitoring systems). The ISI 210 described with reference to FIG. 2 is configured to receive messages from a core information system such as an ADT system, and to receive messages from a non-core IS, such as a cardiology system. The ISI can operate to parse information in a message received from the ADT system in order to detect critical information (i.e., patient name and corresponding medical record number) and then maintain this critical patient information in a store or data repository 230, and the ISI can operate to parse information in a message from the cardiology IS in order to detect critical information);
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to have modified the information receiving and maintaining features of Malecha with the limitations taught by Wilson. One of ordinary skill in the art would have been motivated to make this modification for the benefit of minimizing the number of applications needed to access information from dissimilar systems (Wilson – [0003]).
However, Malecha, in combination with Wilson, does not explicitly teach the following limitations:
transmitting an alert to the merchant if an inventory level at a warehouse node falls below a predetermined threshold,
Beigl, in the same field of endeavor, teaches the following limitations:
transmitting an alert to the merchant if an inventory level at a warehouse node falls below a predetermined threshold ([0008] The items may be products in a store or in a warehouse and the surfaces may be the surfaces of one or more store shelves or warehouse shelves. The computer may generate a message when the number of items placed on the surfaces of store shelves or warehouse shelves decreases below a predetermined threshold. The message may be an out-of-stock message and the items may be associated with a specific item manufacturer name or item product name),
This known technique is applicable to the system of Malecha, in combination with Wilson, as they both share characteristics and capabilities, namely, they are directed to tracking inventory and movement of goods in a supply chain. One of ordinary skill in the art, before the effective filing date of the claimed invention, would have recognized that applying the known technique of Beigl would have yielded predictable results and resulted in an improved system. It would have been recognized that applying the technique of Beigl to the teachings of Malecha, in combination with Wilson, would have yielded predictable results because the level of one of ordinary skill in the art would have known to incorporate such features (i.e., transmitting an alert when inventory levels are low) into similar systems.
Response to Arguments
Applicant’s Argument Regarding 35 USC 101 Rejection of Claims 50-65:
Step 2A-Prong Two: Yes
Claim 50, in view of proposed amendments, recites features analogous to acts (b) and (c) of Example 42 Claim 1 (Subject Matter Eligibility Examples: Abstract Ideas p. 18-19), which was found to be patent eligible under Step 2A prong 2. In particular, claim 50 recites that "warehouse nodes maintain warehouse node information in a non-standardized format" and recites "converting non-standardized warehouse node information from the set of warehouse nodes into a plurality of node data sets of a standardized format."
The additional elements of amended claim 50 enable warehouse nodes to share warehouse node information in a standardized format in order to be used in apportionment regardless of the format in which the information was received.
Examiner’s Response: Applicant’s arguments have been fully considered and they resolve the identified issue. As such, the rejection is withdrawn.
Applicant’s Argument Regarding 35 USC 103 Rejections of Claims 50-65:
Malecha, Wilson, and Beigl, whether taken in combination or alone, fail to disclose the amendments to claim 50 for the following two reasons.
First, the references as applied fail to disclose at least "receiving, from a merchant, a placement request comprising (i) locations of one or more retail stores where inventory units of the merchant are to be shipped for sale to consumers," as required by the claims.
During the interview, the examiner cited to paragraph 39 of Malecha as purportedly disclosing the limitation. In particular, Malecha discloses "[i]nventory adjustments are instructions received from a user to modify inventory levels at one or more locations or nodes within the supply chain." However, in paragraph [0039], Malecha references an administrative user being one to provide the instructions, not the cited "[v]endors 102" that "produce/provide the items or products that will be sold by the retail entity" ([0030]).
In particular, users are described in paragraph 39-40 "The replenishment management system 204 also receives inventory adjustments from a user interface 214. Inventory adjustments are instructions received from a user to modify inventory levels at one or more locations or nodes within the supply chain. ...In some embodiments, the user interface 214 can provide inventory management inputs for an administrative user of the supply chain management system. For example, the user interface 214 can provide user access to view and set inventory levels and inventory fulfillment thresholds for retail locations in the supply chain, either individually or collectively." Figure 2, reproduced below, also does not show that the vendors provide the instructions through the "User Interface/API 214" nor the "Replenishment Management System 204".
In particular, administrative users are internal to the supply chain management system, with authority to set inventory policies, thresholds, and respond to demand signals, see e.g., "an administrative user [is] of the supply chain management system" ([0039]-[0040]). Figure 2 of Malecha shows that vendors are external to the supply chain management system, and also shows that vendors receive purchase orders from the supply chain management system, but vendors never provide input to the supply chain management system. Instead, vendors simply "produce/provide the items or products that will be sold by the retail entity. A purchase order is typically placed to request products from a vendor." ([0030]; FIG. 2). Thus, as shown in Figure 2 of Malecha, the cited embodiment of Malecha does not disclose receiving a location of retail stores from a merchant as required by the claim.
Second, the references as applied fail to disclose at least "receiving, from a merchant, a placement request comprising (i) locations of one or more retail stores where inventory units of the merchant are to be shipped for sale to consumers and (ii) a shipping speed." That is, the references fail to disclose receiving a placement request comprising both the locations and shipping speed from a merchant. As discussed above, the paragraph [0039] of Malecha discussed during the interview describes an administrative user, not a merchant placing instructions to modify inventory levels at one or more locations or nodes. Furthermore, the instructions described in paragraph [0039] do not include a shipping speed.
Examiner’s Response: Applicant’s arguments have been fully considered but they are not persuasive.
Regarding Applicant’s argument that Malecha references an administrative user being one to provide the instructions, not the cited "[v]endors 102" that "produce/provide the items or products that will be sold by the retail entity," nowhere in Malecha does it teach that an administrative user of the supply chain system cannot also be a merchant, and further, based on the general definition of a merchant (i.e., any entity that buys and sells goods or services) and under broadest reasonable interpretation, the retail stores of Malecha are also considered merchants, not just the vendors. The supply chain management system of Malecha can be used by any administrative user; it does not discriminate what kind of user can be an administrative user of the system; functionally, the system of Malecha can be used by a user of a retail store, which is a merchant.
Regarding Applicant’s argument that the references do not teach receiving a placement request comprising both the locations and shipping speed from a merchant, as the user instructions of Malecha do not include a shipping speed, as previously stated, Malecha does teach that the administrative user placing instructions can be a merchant, and Malecha also teaches that instructions are sent that include when the inventory items are needed ([0108]). Further, paragraph [0076] recites “The proactive replenishment engine 316 receives proactive demand signals from the demand forecast engine 212 and user interface 214. These demand signals come in the form of a forecasted demand probability distribution that is determined for each item, at each location, for a given timeframe.” For even further clarity, paragraph [0039] of Malecha recites “The replenishment management system 204 is further described in connection with U.S. patent application Ser. No. 15/898,837, entitled ‘Method and System for Supply Chain Management’, the disclosure of which is hereby incorporated by reference in its entirety.” The incorporated U.S. patent application No. 15/898,837, in paragraph [0080], recites “The product availability goal is determined by the overall retail enterprise and is the amount of availability for each item at each location at different time periods that is set for both online and in-store customers. For example, pumpkin pie filling may have a higher availability goal at Thanksgiving than other times of year. Availability goals can be adjusted to reflect the importance of the product to the customers at that time of year. Availability goals may be adjusted through the user interface 214, which communicates with the replenishment policy engine 321,” and further recites, in paragraph [0081], “The replenishment policy engine 321 receives inputs from the user interface 214 to modify the optimized inventory positions and replenishment procedures. The replenishment procedures and optimized inventory positions may be modified for particular promotional events, in advance of seasonal changes in demand, or other inputs from a user. The replenishment policy engine 321 keeps track of inputs from the user interface 214 and mediates time-based changes in replenishment procedures and optimized inventory positions.”
The combination of the applied references reasonably teaches all the limitations of the claim.
Conclusion
The prior art made of record and not relied upon, considered pertinent to applicant’s disclosure or directed to the state of art, is listed on the enclosed PTO-892.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to KARMA EL-CHANTI whose telephone number is (571)272-3404. The examiner can normally be reached T-Sa 10am-6pm ET.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Sarah Monfeldt can be reached at (571)270-1833. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/KARMA A EL-CHANTI/Examiner, Art Unit 3629 /SARAH M MONFELDT/Supervisory Patent Examiner, Art Unit 3629