Patent Grant
11017369
Inventory management is a crucial aspect of doing business for merchants. For merchants who do business at multiple locations, inventory management involves not only the tracking of merchandise sales at different merchant stores (e.g., purchases at various point-of-sale terminals), but also the fast and accurate communication of pricing and associated discounts based on available inventory between the merchant's headquarters to the different locations. Although merchants often have systems in place to handle these functionalities, these systems can quickly become technologically out-of-date and inadequate for their intended purposes as a merchant's business expands. Yet technology upgrades often require extensive infrastructure changes to these systems (i.e., legacy systems), which can be expensive.
Embodiments of the inventory management technology will be described and explained through the use of the accompanying drawings in which:
Introduced here is a technology (“the inventory management technology”) for processing transactions on behalf of a merchant who employs a legacy computer system for managing inventory, where the processing of transactions includes managing merchandise data associated with transactions occurring at various point-of-sale (POS) devices that include both legacy POS devices and new (i.e., non-legacy) POS devices. Among other benefits as will be discussed further below, the inventory management technology enables the merchant to maintain consistency of merchandise data among both the legacy POS devices and the non-legacy POS devices. As used herein, the term “merchandise data” refers to inventory data and bundle pricing data that includes bundle pricing rules for applying discounts to merchandise items purchased across the various POS devices. As used here, the term “legacy” refers to a computer system or other computing device that maintains a previous or outdated computer architecture that is constructed for a specialized, limited purpose, whose integration with new technologies may necessitate a complete disintegration of the architecture and/or pose significant technical challenges.
In at least some embodiments, the inventory management technology involves a network-based payment processing system (PPS) working in coordination with a legacy computer system of a merchant (“legacy merchant system” or simply “merchant system”). The PPS can be operated by a payment processing service to facilitate, on behalf of the merchant, a processing of customer purchases at one or more POS devices associated with the PPS (i.e., non-legacy POS devices). The PPS can include a payment processing database system (PPDS), an adapter module installed at the merchant system, and a payment processing engine installed at a cloud-based server system. In at least some embodiments, the payment processing engine operates as a communication bridge between the merchant system and the PPS. In particular, in at least some embodiments the payment processing engine receives the most up-to-date inventory data and bundle pricing rules from the legacy merchant system via the adapter module.
The adapter module, which is installed at the legacy merchant system, operates as a mechanism to facilitate communication of data between the legacy merchant system, which can communicate only to the legacy POS devices and/or other legacy systems, and other remote systems and/or devices. In particular, the adapter module translates between the legacy formats, which are traditionally used by the back-end computers of the legacy merchant, and the “modern” or new formats used by the current computer systems of the payment service (e.g., the PSS and/or the mobile devices operating as POS coupled to the PSS). In one example implementation, data is obtained from a cloud-based data store (or database system) and transmitted to the adapter module using Protocol Buffers (e.g., by payment processing engine); the adapter module turns the data into a CSV formatted file that the legacy merchant system can interpret. The implementation can also work in the other direction, where the adapter can obtain a legacy formatted CSV, translate it into protocol buffers, and send, or cause it to be sent, to the cloud-based data store for storage (e.g., data is sent to the payment processing engine residing at the server associated with the data store). Note that Protocol Buffers is just one example of formats that can be utilized in the inventory management technology. As used here, the term “Protocol Buffers” refer to a method of serializing structured data that can be useful in developing programs to communicate with each other over a wire or for storing data. The method involves an interface description language that describes the structure of some data and a program that generates source code from that description for generating or parsing a stream of bytes that represents the structured data. Use of protocol buffers can be ideal in certain situations for communicating large amounts of data between clients and servers while minimizing the amount of information you have to transmit, simplifying updates to how they communicate and providing clear documentation of the interface between the two.
In embodiments of the inventory management technology, the adapter module receives commands and/or instructions from the payment processing engine, which cannot otherwise communicate with the legacy merchant system, and translates those commands and/or instructions and executes them at the legacy merchant system. For example, the adapter module, based on a request from the payment processing engine, can access a database system associated with the legacy merchant system to retrieve the up-to-date inventory data and bundle pricing rules for transmission to the payment processing engine. Using the bundle pricing rules retrieved by the adapter module, the payment processing engine can compute one or more “minimum-price carts” that apply pricing discounts to eligible items in virtual shopping carts of transactions occurring at the POS device(s) associated with the PPS. Furthermore, the adapter module can receive data (e.g., post-sales transaction data or “post-transaction data”) from the payment processing module, and communicate that data to the legacy merchant system such that the system can update its inventory data stored at the database system associated the legacy merchant system. Using this post-transaction data, the legacy merchant system can reconfigure the bundle pricing rules based on the updated inventory data.
Consider, as an example, that the merchant is a clothing retailer company, or simply a “retailer service”. A retailer service may offer a large inventory of inventory items (e.g., hundreds of thousands of clothing articles) in different categories (e.g., clothing departments) for purchase at a large number of retailer stores. A retailer service such as this generally utilizes a legacy computer system to maintain merchandise data for items being offered at multiple legacy POS devices located at different retailer stores. The merchandise data, as discussed above, can include inventory data associated with inventory items of a particular store and bundle pricing data that include bundle pricing rules for applying discounts to the inventory items. The legacy computer system generally includes a centralized server computer system (e.g., at the retailer's headquarters) that communicates with one or more local computer servers, each located at and servicing a particular retailer store and that store's legacy POS devices. In particular, a local computer server communicates merchandise data back and forth between the legacy POS devices and the centralized server computer system. An example of such a local computer server is shown as location system 320 of
As its business expands and newer POS devices and newer payment processing implementations become available, the retailer service desires to take advantage of the new technological advancements. However, because the legacy computer system has been in place for a long time, and has to maintain a large amount of data, a transition to a completely new inventory management system is highly burdensome, expensive, and technologically challenging. The alternative to a complete replacement of the legacy computer system is integration with new systems. Integration can also be problematic, however, as merchandise data maintained by the retailer service needs to be updated across both the new POS devices and the legacy POS devices. As a result, distribution of the merchandise data by the legacy computer system to the new POS devices can be slow and prone to technical errors (e.g., software bugs). Accordingly, any solutions for the retailer service must balance the need for a robust infrastructure as well as the need for simplicity of execution that provides seamless integration between legacy systems and non-legacy systems.
The inventory management technology introduced here efficiently integrates with a legacy merchant system to process transactions on behalf of a retailer service, by use of the payment processing engine in communication with the adapter module, without the need for drastic infrastructure changes. Referring back to the example, a customer makes a purchase of one or more inventory items at a POS device associated with the PPS (e.g., the customer is at the “check-out” with a proposed purchase). Such proposed purchase by the customer results in a set of operations carried out by various components and/or systems of the PPS (e.g., the operations discussed in reference to
In a first operation, the POS device sends to the PPDS pre-sale transaction data (“pre-transaction data”) associated with the one or more inventory items being purchased. The pre-transaction data includes information about the items in the customer's virtual shopping cart. A “virtual shopping cart” as used here refers to one or more inventory items selected in a customer's proposed purchase at the POS device. The virtual shopping cart can be generated, for example, on a display of the POS device when a sales employee, for example, scans barcodes or Quick Response (QR) codes of the inventory items into the POS device. An example of the virtual shopping cart is shown in
The PPDS, upon receiving the pre-transaction data, forwards it in a request message to the payment processing engine, to request that a minimum-price cart be generated for the virtual shopping cart. In some embodiments, the POS device sends the pre-transaction data directly to the payment processing engine. In other embodiments, the payment processing engine, which has access to the most up-to-date bundle pricing rules (received via the adapter module), calculates a minimum-price cart for the customer based on the bundle pricing rules. The bundle pricing rules specify discount pricings for one or more discount pricing bundles (groups) of inventory items. The minimum-price cart is a particular discount pricing bundle of items selected for eligible items in the customer's virtual shopping cart, where the discount pricing bundle includes a discount for those eligible items. For example, assume that the customer has decided to purchase three shirts at a regular price of $12.99. The payment processing engine can identify a discount bundle rule that specifies that a bundle of three shirt X qualifies for a discount of “$30 for 3” (i.e., the discount pricing bundle). Further details regarding the identification of an applicable discount bundle rule will because below at least in reference to
Upon identifying the discount bundle rule, the payment processing engine can apply the discount bundle rule to the customer's three shirts based on the fact that the shirts necessary for that bundle are included in the transaction. In particular, the payment processing engine can send the minimum-price cart back to the PPDS for transmission to the POS device. The minimum-price cart can be in the form of new data that gets transmitted, or pushed, to the PPDS, which then transmits that data to the POS device. In other embodiments, the payment processing engine sends the minimum-price cart directly to the POS device. In such embodiments, the minimum-price cart can be in the form of updated data about the virtual shopping cart that gets transmitted, or pushed, by the payment processing engine to the POS device. Having the minimum-price cart computed by the payment processing engine, as opposed to the POS device for example, relieves the POS device from having to perform any heavy computations. Furthermore, the retailer service (and the POS device) can rest assured that the computed minimum-price cart is current since the payment processing engine maintains the most up-to-date information available from the legacy merchant system.
In some embodiments, where the transaction is an online transaction, the payment processing engine, which has the most up-to-date inventory data, can also verify that the items being purchased are indeed available in the retailer's inventory. In such embodiments, the online transaction can occur, for example, at a website on a web browser executing on a computing device.
Among other benefits, the inventory management technology enables the retailer service to maintain accurate inventory data and apply discount pricing rules across both legacy POS devices and new POS devices. Furthermore, with the new POS devices, having the discount pricing rules implemented by the payment processing engine, as opposed to any of those POS devices for example, relieves each individual POS device from having to perform any heavy computations. Since communication of the up-to-date inventory data and discount pricing rules can be accomplished by integration of the adapter module, the legacy merchant system can remain intact without need for drastic infrastructure changes. Furthermore, because information can be communicated from the legacy merchant system to any remote systems via the adapter module and the payment processing engine, the inventory management technology enables integration with as many new POS devices and/or systems as desired based on the expansion needs of the retailer service.
It is noted the inventory management technology can be used for any merchant system implementation that requires management of inventory and pricing associated with a large inventory of items (e.g., hundreds of thousands of items). Further, while, for convenience, various embodiments of the inventory management technology are described with reference to a retailer service, in other embodiments, the inventory management technology is equally applicable to various other types of merchant (e.g., perishable goods merchant) or any service that requires seamless communication of a large amount of data between legacy and non-legacy systems.
Moreover, the technology introduced here can be embodied as special-purpose hardware (e.g., circuitry), as programmable circuitry appropriately programmed with software and/or firmware, or as a combination of special-purpose and programmable circuitry. Hence, embodiments may include a machine-readable medium having stored thereon instructions that may be used to cause one or more processors to perform the methods, variations of the methods, and other operations described here. The machine-readable medium may include, but is not limited to, floppy diskettes, optical discs, compact disc read-only memories (CD-ROMs), magneto-optical discs, read-only memories (ROMs), random access memories (RAMs), erasable programmable read-only memories (EPROMs), electrically erasable programmable read-only memories (EEPROMs), application-specific integrated circuits (ASICs), magnetic or optical cards, flash memory, or other type of media/machine-readable medium suitable for storing electronic instructions.
In this description, the terms “connected” or “coupled” and related terms are used in an operational sense and are not necessarily limited to a direct physical connection or coupling. Thus, for example, two devices may be coupled directly, or via one or more intermediary media or devices. As another example, devices may be coupled in such a way that information can be passed there-between, while not sharing any physical connection with one another. Based on the disclosure provided herein, one of ordinary skill in the art will appreciate a variety of ways in which connection or coupling exists in accordance with the aforementioned definition.
The term “module,” or “engine” refers broadly to general- or special-purpose hardware, software, or firmware (or any combination thereof) components. Modules and engines are typically functional components that can generate useful data or other output using specified input(s). A module or engine may or may not be self-contained. Depending upon implementation-specific or other considerations, the modules or engines may be centralized or functionally distributed. An application program (also called an “application”) may include one or more modules and/or engines, or a module and/or engine can include one or more application programs.
The phrases “in some embodiments,” “according to some embodiments,” “in the embodiments shown,” “in other embodiments,” and the like generally mean the particular feature, structure, or characteristic following the phrase is included in at least one implementation of the inventory management technology, and may be included in more than one implementation. In addition, such phrases do not necessarily refer to the same embodiments or different embodiments. Furthermore, if the specification states a system, a component, or a feature “may”, “can”, “could”, or “might” be included or have a characteristic, that particular component or feature is not required to be included or have the characteristic.
The client devices 102-1-102-N (“legacy POS devices 102-1-102-N) can each be any conventional POS system capable of processing purchase transactions associated with the legacy merchant system 110. An example of a legacy POS device 102 is an NEC® POS Terminal. The legacy POS devices 102-1-102-N can be configured to communicate via the network 108 with the legacy merchant system 110. In some embodiments, the legacy POS devices 102-1-102-N can retrieve or submit information (e.g., inventory data, pricing data, transaction data, etc.) to the legacy merchant system 110 and run one or more applications (e.g., a legacy point-of-sale application) with customized content retrieved from the legacy merchant system 110. For example, the legacy POS devices 102-1-102-N can execute a customized client to enable receiving inventory data and/or pricing data from the legacy merchant system 110, or transmitting pre-transaction and/or post-transaction data to the legacy merchant system 110.
The client devices 104-1-104-N are associated with the PPS 120, and each can be any computing device capable of receiving user input as well as transmitting and/or receiving data via the network 108. The client devices 104-1-104-N can be conventional computer systems (e.g., a desktop or a laptop computer) or mobile computing devices having computer functionality (e.g., a tablet device, a mobile telephone, or a smart-phone). An example of a client device 104 is a mobile computing device such as a tablet computer (e.g., an Apple® iPad®) or smartphone (e.g., an Apple® iPhone®). In some embodiments, the client device 104 can run one or more applications with customized content retrieved from and/or transmitted by the PPS 120, where the one or more applications enable the client device 104 to operate as a POS terminal for a merchant (“POS device 104” or “non-legacy POS device 104”). For example, the POS device 104 can execute a browser application and/or a customized client to retrieve or submit information (e.g., inventory data, pricing data, pre-transaction data, post-transaction data, etc.) from and/or to the PPS 120.
The network 108 can include any combination of local area and/or wide area networks, and wired and/or wireless communication systems. In one embodiment, network 108 uses standard communications technologies and/or protocols. Thus, network 108 may include links using technologies such as Ethernet, IEEE 802.11/WiFi based communications, worldwide interoperability for microwave access (WiMAX), 3G, 4G, CDMA, digital subscriber line (DSL), etc. Similarly, the networking protocols used on network 108 may include, for example, multiprotocol label switching (MPLS), transmission control protocol/Internet protocol (TCP/IP), User Datagram Protocol (UDP), hypertext transport protocol (HTTP), simple mail transfer protocol (SMTP) and file transfer protocol (FTP). Data exchanged over the network 108 may be represented using technologies and/or formats including hypertext markup language (HTML) or extensible markup language (XML). In addition, all or some links can be encrypted using conventional encryption technologies such as secure sockets layer (SSL), transport layer security (TLS), and Internet Protocol security (IPsec).
The merchant system 110 can include one or more computer servers used to manage merchandise data relating to items offered for sale at various merchant stores of a merchant. As discussed above, the merchandise data can include inventory data of inventory items and bundle pricing rules associated with the inventory items. The inventory data of a particular inventory item can include, for example, an item name, an item descriptions, an item price, and an item Stock Keeping Unit (SKU). In some embodiments, the inventory data can include other identifying information associated with the particular item, such as an item category (e.g., product category), an item location or “merchant location” (e.g., a physical inventory location at which the item is being held such as a physical store), an image of the item, an item history (e.g., return status, transit information, etc.), and the like.
The merchant system 110 maintains a “master” copy of the merchandise data, which can get distributed to the legacy POS devices 102-1-102-N to enable each legacy POS device to have the most recent, or up-to-date, information. The legacy merchant system 110 can receive transaction data and/or inventory data from each of the legacy POS devices 102-1-102-N to maintain an accurate master copy of the merchandise data. For example, at the end of every business day, the legacy POS device 102 sends the legacy merchant system 110 a report of purchases, which can be used by the legacy merchant system 110 to update the master copy of the merchandise data. For example, based on the number of items sold, the legacy merchant system 110 can adjust the bundle pricing rules (e.g., “No more discount for Item X which is a popular sales item”). In another example, based on the number of items sold, the legacy merchant system 110 can update its inventory of the available of its merchandise (e.g., Item X sold out at all stores on the West Coast). As will be discussed in further detail below, the legacy merchant system 110 can also receive transaction data and/or inventory data from each of the POS devices 104-1-104-N via the facilitation of the PPS 120. Furthermore, through the PPS 120, the master copy of the merchandise data can get distributed to the POS devices 104-1-104-N.
The PPS 120 can include can one or more secure servers. In some embodiments, the PSS 120 includes a secure database server (e.g., PPDS 222 of
In some embodiments, the processing server communicates with the database server via an application (e.g., payment processing engine 222 of
The PPS 220 is operated by a payment processing service on behalf of a merchant to facilitate transactions executing at one or more client devices 228A-228N. The PPS 220 can include one or more server computer systems employed to facilitate the processing of transactions and/or other commercial functions associated with the transactions via a network (e.g., the network 108 of
The payment processing engine 224 can be executing, or running, on one or more servers 226. In some embodiments, the payment processing engine 224 is an application executing on the server(s) 226. In some embodiments, the server(s) 226 can be operated by a cloud service provider that provides utilization of the server(s) 226 to the payment processing service. In some embodiments, the server(s) 226 can be one or more servers of the PPS 220. In the embodiments of
In accordance with the embodiments of
In some embodiments, the POS database system 212 operates as a datacenter that maintains a “master” copy of the inventory data and the bundle pricing data (i.e., merchandise data) in the one or more databases. As discussed above, the master copy of the merchandise data can get distributed to the legacy POS devices 102-1-102-N (by the POS database system 212) and the POS devices 104-1-104-N (by the adapter module) such that each POS device has the most recent, or up-to-date, information. Furthermore, each POS device can send reporting information back to the merchant system 210 for updating the master copy of data. In particular, the POS database system 212 facilitates the distribution and the reporting of data to and from the legacy POS devices, while the PPS 220 facilitates those processes to and from the (non-legacy) POS devices on behalf of the merchant system 210.
In accordance with the embodiments of
Operation of the system is now further described with reference to
At operations 232A-232N, the client devices 228A-228N respectively send pricing requests to the PPDS 222. The client devices 228A-228N are POS devices managed by the PPS 220 for executing purchase transactions on behalf of the merchant. For example, each client device 228 is physically located at a merchant store at which a sales employee scans inventory items into a virtual customer shopping cart that is generated on a display of the client device 228. An example of such a display showing the virtual shopping cart is illustrated in
At operation 234, the PPDS 222 forwards the pre-transaction data to the payment processing engine 224 as a request to provide prices, and more particularly, a request to provide a minimum-price cart with any applicable discounts applied to the prices of inventory items in the customer's proposed purchase. The payment processing engine 224 accesses the locally stored bundle pricing rules (previously received from the adapter module 214) and performs one or more computations to generate the minimum-price cart for the customer.
In some embodiments, generating the minimum-price cart includes first determining a set of one or more potential pricing bundles for each item in the virtual shopping cart. In particular, the payment processing engine 224 determines each potential pricing bundle by identifying whether the virtual shopping cart has available all of the items required by a bundle pricing rule for that potential pricing bundle. For example, a bundle pricing rule specifies that Hat X has a discounted price $10 (where the regular price is $12) if Hat X is “bundled”, or bought together, with Shirt Y. In this example, the payment processing engine 224, upon first identifying Hat X, would search for Shirt Y (or vice versa) in order to satisfy the bundle pricing rule before applying the discount to Hat X. If Shirt Y is identified, the payment processing engine 224 proceeds to the next bundle pricing rule that is applicable to Hat X (to identify the next potential pricing bundle). For example, another bundle pricing rule specifies a discount of $5 for Hat X if Hat X is bundled with 5 other Hat X's. The payment processing engine 224 continues determining all potential pricing bundles applicable to Hat X, and continues to do so until every item in the virtual shopping cart has been analyzed (e.g., Hat Y, Sock Z, etc.).
Next, the payment processing engine 224 determines a maximum potential discount for each item if all of the potential pricing bundles are applied. Based on the maximum potential pricing discount for each item, the payment processing engine 224 generates and assigns a ranking for each item. For example, even though Hat X qualifies for two different pricing bundles, the pricing bundle with the $5 discount provides the most savings to the customer. As a result, the potential pricing discount of the latter bundle is selected for Hat X. However, Pants Z is eligible for a bundle that needs Hat X, where Pants Z has a maximum potential pricing discount of $10 if bundled with Hat X. Accordingly, the bundle of Pants Z with Hat X is ranked the highest, and as such, that bundle is selected for the virtual shopping cart of the customer.
At operation 236, the payment processing engine 224 sends the result of the bundle analysis to the PPDS 222, which forwards the result to a corresponding client device 228 (that has requested the minimum-price cart), as indicated by operation 238. In some embodiments, the payment processing engine 224 sends the result directly to the client device 228. In some embodiments, the result is sent in the form of data for populating a new shopping cart for the customer. For example, the client device 228 uses the information it receives to generate a new version of the virtual shopping cart, where the new version includes updated pricing information on a display for the sales employee. An example of such a display is illustrated in
In some embodiments, the client devices 228A-228N send post-sale transaction data (or post-transaction data) to the PPDS 222, as indicated by operations 240A-240N. The PPDS 222 forwards this data to the payment processing engine 224, as indicated by operation 242. At operation 244, the payment processing engine 224 forwards the data to the merchant system 210 via communication with the adapter module 214 to enable updating of the master copy of the inventory data at the merchant system 210. In some embodiments, the payment processing engine 224 generates updated inventory data based on the inventory data and the post-transaction data before transmission to the legacy merchant system 210. In such embodiments, the payment processing engine 224 sends a processed version of the post-transaction data for updating the inventory data stored at the POS database system 212.
In some embodiments, the payment processing engine 224 not only maintains a local copy of the inventory data received from the merchant system 210, but also sends the inventory data to the PPDS 222, as indicated by operation 250. The PPDS 222, in turn, can push the inventory data to the client devices 228A-228N. The client devices 228A-228N, as a result, can have the most up-to-date information about the merchant's inventory items. In some embodiments, the payment processing engine 224 sends the inventory data directly to the client devices 228A-228N. In some embodiments, the payment processing engine 224 simply maintains its copy of the inventory data locally, without forwarding the data to the client devices 228A-228N and/or the PPDS 222.
In some embodiments, prior to determining the minimum-price cart upon request of a particular client device 228, the payment processing engine 224 performs an additional step of verifying that the transaction items in the shopping cart are available for purchase based on the inventory data (received via the adapter module 214). The verifying can include comparing the transaction items with the inventory data to see if the transaction items are still available (e.g., unidentified item or item no longer in inventory). This can be useful, for example, in a scenario of an online purchase transaction with an online shopping cart.
In some embodiments, the payment processing engine 224 precomputes one or more minimum-price carts based on the discount bundle rules received via the adapter module 214, and transmits the minimum-price carts data to the client devices 228A-228N without being prompted with a request (i.e., pushes the minimum-price carts data. In such embodiments, each minimum-price cart includes a discount pricing bundle for eligible transaction items in a theoretical proposed purchase transaction that may be conducted at a POS device. Such computations can be compiled, for example, in an index that can be readily accessible by a POS device to execute the computation of bundles “on-the-fly,” i.e., at the time of a transaction, without having to wait for a response from the payment service engine 224 and/or the PPDS 222. In some embodiments, the pre-computed minimum-price carts can be transmitted to the PPDS 222 for storage. In such embodiments, the PPDS 222 can service the requests from the client devices 228A-228N, as opposed to the payment processing engine 224.
In accordance with the embodiments of
In one example, a particular legacy POS device 322 can receive up-to-date inventory data and pricing bundle data from the location system 330, which has that data from the POS database system 310. The particular legacy POS device 322 can also transmit data to the location system 330 to report purchase transactions processed at the legacy POS device 322. Such transmission can be periodically (e.g., daily, weekly, monthly, etc.), where the time period can be configured by an operator of the particular legacy POS device 322, the POS database system 310, or a combination thereof. The location system 330, upon receiving the reported data, can transmit that data back to the POS database system 310 for updating the master copy of data for effective operation of the merchant's business. For example, each of the legacy POS devices 322A-322N transmits sales information (e.g., post-transaction data) at the end of every business day to the location system 330, thereby enabling the location system 330 to have up-to-date information at, e.g., “Store X”. The location system 330, along with the location systems 340 and 350, can each forward that information from their respective legacy POS devices to the POS database system 310. The POS database system 310 in turn, can update its inventory data based on the transactions that have been processed across all of the legacy POS devices 322A-322N, 332A-332N, and 342A-342N.
In some embodiments, based on the information received from the location systems 330, 340, and 350, the POS database system 310 and/or another component or server system associated with the legacy merchant system 300 can reconfigure the bundle pricing rules. For example, based on inventory updates received from the location systems 330, 340, and 350, the legacy merchant system 300 identifies that items A, B, and C are unpopular items (e.g., based on a low number of units sold for a long period of time). In response, the legacy merchant system 300 can compute new pricing bundle rules to help increase sales of those items. In one example, a pricing bundle rule is generated to specify a discount for a bundle of three or more of item A being purchased together. In another example, an existing pricing bundle rule (e.g., specifying a discount for a bundle of items A and B) is updated to specify a discount for bundling item A with popular items E and F. In yet another example, a pricing bundle rule specifies a discount for a bundle of items A, B, and C. The newly generated bundle pricing rules and/or updated pricing bundle rules can be transmitted by the POS database system 310 to the location systems 320, 330, and 340, which can distribute, respectively, the rules to the legacy POS devices 322A-322N, 332A-332N, and 342A-342N.
In some embodiments, a adapter module installed at the POS database system 310 can also transmit newly generated pricing bundle rules and/or updated pricing bundle rules to a payment processing engine. The payment processing engine, in turn, can push that data to the POS devices (i.e., non-legacy devices not in communication with the legacy merchant system 300), thereby enabling those POS devices to have the same up-to-date information as the legacy POS devices 322A-322N, 332A-332N, and 342A-342N. In some embodiments, the payment processing engine indirectly transmits that data by communicating it to a payment processing database system, which transmits the data to the POS devices.
The memory 404 can be any device, mechanism, or populated data structure used for storing information. In some embodiments of the inventory management technology, the memory 404 can be or include any type of, but is not limited to, volatile memory, nonvolatile memory and dynamic memory. In some embodiments, the memory 404 can be or include one or more disk drives, flash drives, one or more databases, and/or the like. In some embodiments, the memory 404 can include one or more tables, one or more files, local cache memories, processor cache memories, relational databases, and/or the like. In some embodiments, the memory 404 can be used to store instructions for executing, or running, one or more applications or modules on the processor(s) 402. For example, the memory 404 could be used in various embodiments to house all or some of the instructions needed to execute the functionality of the minimum-price cart module 410.
The minimum-price cart module is configured to determine one or more minimum-price carts based on the discount bundle rules received from a legacy merchant system (e.g., the merchant system 110 of
Next, the minimum-price cart module 410 determines for the item a maximum potential pricing discount that results when all of the determined potential bundles are applied to the item. Based on the maximum potential pricing discount for each item, the minimum-price cart module 410 can generate and assign a ranking for each item. Based on the ranking, the minimum-price cart module 410 selects a particular bundle as the minimum-price cart; for example, the minimum-price cart module 410 may select the highest ranked potential bundle.
Referring back to the example above, item X can qualify for other pricing bundles that does not involve Shirt Y, one of which provides a potential discount of $5 off the price of item X. The bundle with item Y, on the other hand, offers only a $2 off the price of item X. As such, the bundle without item Y is selected for item X. However, for item Y, of all its potential bundles, the bundling with item X provides the maximum potential discount of $10 off the price of item Y. Accordingly, the bundle of item Y and item X is ranked the highest based on those items' respective maximum potential discounts. As a result, the bundle involving item X and item Y is selected as the minimum-price cart for the customer.
In some embodiments, the minimum-price cart module 410 transmits the generated minimum-price cart to the particular POS device. In other embodiments, the generated minimum-price cart is transmitted first to the PPDS, which then forwards it to the particular POS device. In some embodiments, the generated minimum-price cart is transmitted by the inventory communication module 406. In other embodiments, the generated minimum-price cart is transmitted by the inventory management module 408.
In some embodiments, the minimum-price cart module 410 pre-computes a plurality of minimum-price carts without receiving a request from a particular POS device. In such embodiments, the precomputed minimum-price carts are transmitted to all of the POS devices in communication with the payment processing engine 400 to enable the devices to perform on-the-fly determination of a particular minimum-price cart. The pre-computed minimum-price carts can be an index of minimum-price carts that can be accessed relatively quickly as needed. A POS device can store the index locally for on-the-fly access as needed. For example, for a particular transaction taking place in real-time, the particular POS device can simply access the locally stored index to identify a minimum-price cart that is applicable to that transaction. As a result, the POS device can simply generate its own minimum-price cart without sending a request to the payment processing engine 300 (directly or indirectly via the payment processing database system), and without having to do heavy computations to obtain that minimum-price cart due to the pre-computed minimum-price carts.
At operation 502, the payment processing engine receives inventory data and discount bundle data from a legacy retailer system (e.g., the legacy merchant system 110 of
At operation 504, the payment processing engine receives pre-sale transaction data associated with a proposed purchase transaction occurring at a POS device facilitated by the payment processing service. The pre-sale transaction data includes information about a set of one or more inventory items in a particular customer shopping cart associated with the proposed purchase transaction. In some embodiments, the pre-sale transaction data (or pre-transaction data) can be included in a minimum-price cart request message that requests a minimum-price cart to be generated for the proposed purchase transaction. In some embodiments, the request message can be sent from the POS device directly to the payment processing engine via a network (e.g., the network 108 of
At operation 506, the payment processing engine generates a minimum-price cart for the proposed purchase transaction based on the discount bundle rules received from the legacy merchant system. As discussed above, generating the minimum-price cart includes determining a set of potential bundles for each item in the proposed purchase transaction, determining, for each item, a maximum potential pricing discount that results when all of the set of potential bundles of that item are applied to the item, generating a ranking for the item based on the maximum potential pricing discount, and selecting, based on the ranking, a particular bundle, from the set of potential bundles, for each item to generate the first minimum-price cart.
At operation 508, the payment processing engine transmits via the network the generated minimum-price cart to the payment processing database system for transmission to the POS device. In some embodiments, the payment processing engine transmits the generated minimum-price cart directly to the POS device via the network.
At operation 602, the payment processing engine receives post-transaction data associated with a proposed purchase transaction that has completed at a POS device. The post-transaction data includes information on the purchase of inventory items that has completed at the POS device (e.g., credit card payment and authorization for the purchase). In some embodiments, the POS device is configured to transmit the post-transaction data directly to the payment processing engine. In some embodiments, the POS device transmits the post-transaction data to the payment processing database system, which forwards the data to the payment processing engine. As discussed above, the POS device is managed by the payment processing database system that is associated with a payment processing service. The payment processing database system is employed by the payment processing service to facilitate transactions occurring at the POS device on behalf of the legacy retailer system, which is not technologically integrated with the POS device. The payment processing engine is also employed by the payment processing service. The payment processing engine bridges communication between the payment processing database system and the legacy retailer system through communication via the adapter module.
At operation 604, the payment processing engine processes the post-transaction data to generate updated inventory data based on the completed purchase transaction at the POS device. In some embodiments, processing the post-transaction data includes analyzing information in the post-transaction data (e.g., parsing) and compiling the analyzed information into a file that contains updated inventory data. The file can be, for example, an Excel® file or any form of relational database file. At operation 606, the payment processing engine transmits the updated inventory data to the legacy retailer system through communication with the adapter module. In particular, the updated inventory data is transmitted to the adapter module, which communicates the updated inventory data to a POS database system of the legacy retailer system to enable the POS database system to update its “master” copy of inventory data. In some embodiments, as discussed above in reference to
Regarding the sets of operations 500 and 600, while the various steps, blocks or sub-processes are presented in a given order, alternative embodiments can perform routines having steps, or employ systems having steps, blocks or sub-processes, in a different order, and some steps, sub-processes or blocks can be deleted, moved, added, subdivided, combined, and/or modified to provide alternative or sub-combinations. Each of these steps, blocks or sub-processes can be implemented in a variety of different ways. Also, while steps, sub-processes or blocks are at times shown as being performed in series, some steps, sub-processes or blocks can instead be performed in parallel, or can be performed at different times as will be recognized by a person of ordinary skill in the art. Further any specific numbers noted herein are only examples; alternative implementations can employ differing values or ranges.
In the illustrated embodiment, the processing system 800 includes one or more processors 802, memory 804, one or more communication device(s) 806, one or more input/output (I/O) devices 808, and one or more mass storage devices 810, all of which are coupled to one another through an interconnect 812. The interconnect 812 may be or include one or more buses, point-to-point connections, controllers, adapters and/or other conventional connection devices.
The processor(s) 802 can be or include, for example, one or more general-purpose programmable microprocessors, digital signal processors (DSPs), microcontrollers, application specific integrated circuits (ASICs), programmable gate arrays, or the like, or a combination of such devices. The processor(s) 802 control the overall operation of the processing device 800.
Memory 804 can be or include one or more physical storage devices, which may be in the form of random access memory (RAM), read-only memory (ROM) (which may be erasable and programmable), flash memory, miniature hard disk drive, or other suitable type of storage device, or a combination of such devices. The mass storage device (s) 810 may be or include one or more hard drives, digital versatile disks (DVDs), flash memories, or the like. The memory 804 and/or the mass storage device(s) 810 can store (individually or collectively) data and instructions that configure the processor(s) 802 to execute operations in accordance with the techniques described above.
The communication devices 806 can be or include, for example, an Ethernet adapter, cable modem, Wi-Fi adapter, cellular transceiver, Bluetooth or Bluetooth Low Energy (BLE) transceiver, or the like, or a combination thereof. For example, in the case of a client device, the communication devices 806 can be or include, for example, a cellular telecommunications transceiver (e.g., 3G or 4G/LTE), Wi-Fi transceiver, Bluetooth or BLE transceiver, or the like, or a combination thereof.
Depending on the specific nature and purpose of the processing device 800, the I/O devices 808 can include devices such as a display (which may be a touch screen display), audio speaker, keyboard, mouse or other pointing device, microphone, camera, etc. Note that these I/O devices may be unnecessary, however, if the processing device 800 is embodied solely as a server computer.
Unless contrary to physical possibility, it is envisioned that (i) the methods/steps described herein may be performed in any sequence and/or in any combination, and that (ii) the components of respective embodiments may be combined in any manner.
The machine-implemented operations described above can be implemented by programmable circuitry programmed/configured by software and/or firmware, or entirely by special-purpose circuitry, or by a combination of such forms. Such special-purpose circuitry (if any) can be in the form of, for example, one or more application-specific integrated circuits (ASICs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), etc.
Software used to implement the techniques introduced here may be stored on a machine-readable storage medium and may be executed by one or more general-purpose or special-purpose programmable microprocessors. A “machine-readable medium”, as the term is used herein, includes any mechanism that can store information in a form accessible by a machine (a machine may be, for example, a computer, network device, cellular phone, personal digital assistant (PDA), manufacturing tool, any device with one or more processors, etc.). For example, a machine-accessible medium includes recordable/non-recordable media (e.g., read-only memory (ROM); random access memory (RAM); magnetic disk storage media; optical storage media; flash memory devices; etc.), etc.
| Number | Name | Date | Kind |
|---|---|---|---|
| 5057829 | Velazquez | Oct 1991 | A |
| 5168445 | Kawashima et al. | Dec 1992 | A |
| 5765143 | Sheldon et al. | Jun 1998 | A |
| 5933813 | Teicher | Aug 1999 | A |
| 6151582 | Huang et al. | Nov 2000 | A |
| 6431444 | Gatto | Aug 2002 | B1 |
| 6595342 | Maritzen et al. | Jul 2003 | B1 |
| 6609101 | Landvater | Aug 2003 | B1 |
| 6687679 | Van Luchene et al. | Feb 2004 | B1 |
| 7013290 | Ananian | Mar 2006 | B2 |
| 7092929 | Dvorak et al. | Aug 2006 | B1 |
| 7222786 | Renz et al. | May 2007 | B2 |
| 7343319 | Walker | Mar 2008 | B1 |
| 7552066 | Landvater | Jun 2009 | B1 |
| 7660738 | Siegel et al. | Feb 2010 | B1 |
| 7720708 | Elkins, II et al. | May 2010 | B1 |
| 7818284 | Walker | Oct 2010 | B1 |
| 7882209 | Eslambolchi | Feb 2011 | B1 |
| 7941331 | Dogan et al. | May 2011 | B2 |
| 7979299 | Mehta et al. | Jul 2011 | B1 |
| 8001017 | Franco | Aug 2011 | B1 |
| 8103538 | Bamberg et al. | Jan 2012 | B2 |
| 8204799 | Murray et al. | Jun 2012 | B1 |
| 8239296 | Itoi et al. | Aug 2012 | B2 |
| 8355954 | Goldberg et al. | Jan 2013 | B1 |
| 8417572 | Chenault | Apr 2013 | B1 |
| 8438066 | Yuen et al. | May 2013 | B1 |
| 8533053 | Brown et al. | Sep 2013 | B2 |
| 8650062 | Krech | Feb 2014 | B2 |
| 8732040 | Prabhune et al. | May 2014 | B1 |
| 9168315 | Scaringe | Oct 2015 | B1 |
| 9323441 | Minks-Brown et al. | Apr 2016 | B1 |
| 9619483 | Robinson et al. | Apr 2017 | B1 |
| 9619831 | Kumar et al. | Apr 2017 | B1 |
| 9659310 | Allen et al. | May 2017 | B1 |
| 9786005 | Poursartip et al. | Oct 2017 | B1 |
| 9792597 | Jen et al. | Oct 2017 | B1 |
| 10318569 | Funk et al. | Jun 2019 | B1 |
| 10339548 | Kumar et al. | Jul 2019 | B1 |
| 10373118 | Lefkow et al. | Aug 2019 | B1 |
| 10467583 | Jen et al. | Nov 2019 | B1 |
| 20010034722 | Tidball | Oct 2001 | A1 |
| 20010042008 | Hull | Nov 2001 | A1 |
| 20020010661 | Waddington et al. | Jan 2002 | A1 |
| 20020065839 | McCulloch | May 2002 | A1 |
| 20020072988 | Aram | Jun 2002 | A1 |
| 20020091595 | Itoi et al. | Jul 2002 | A1 |
| 20020133368 | Strutt et al. | Sep 2002 | A1 |
| 20020147656 | Tam et al. | Oct 2002 | A1 |
| 20020188579 | Liu | Dec 2002 | A1 |
| 20030006098 | Wike, Jr. | Jan 2003 | A1 |
| 20030018701 | Kaestle | Jan 2003 | A1 |
| 20030026404 | Joyce et al. | Feb 2003 | A1 |
| 20030033179 | Katz et al. | Feb 2003 | A1 |
| 20030046133 | Morley et al. | Mar 2003 | A1 |
| 20030151821 | Favalora | Aug 2003 | A1 |
| 20030216969 | Bauer et al. | Nov 2003 | A1 |
| 20040019552 | Tobin | Jan 2004 | A1 |
| 20040039639 | Walker et al. | Feb 2004 | A1 |
| 20040098311 | Nair | May 2004 | A1 |
| 20040153359 | Ho et al. | Aug 2004 | A1 |
| 20040181753 | Michaelides | Sep 2004 | A1 |
| 20040186783 | Knight et al. | Sep 2004 | A1 |
| 20040267640 | Bong et al. | Dec 2004 | A1 |
| 20050149414 | Schrodt et al. | Jul 2005 | A1 |
| 20050250555 | Richardson | Nov 2005 | A1 |
| 20050273377 | Ouimet | Dec 2005 | A1 |
| 20060031085 | Postel et al. | Feb 2006 | A1 |
| 20060106699 | Hitalenko | May 2006 | A1 |
| 20060195563 | Chapin et al. | Aug 2006 | A1 |
| 20060224470 | Garcia Ruano | Oct 2006 | A1 |
| 20060235726 | Paraison et al. | Oct 2006 | A1 |
| 20060235739 | Levis et al. | Oct 2006 | A1 |
| 20060253330 | Maggio et al. | Nov 2006 | A1 |
| 20070124221 | Itoi et al. | May 2007 | A1 |
| 20070244765 | Hunter et al. | Oct 2007 | A1 |
| 20080077459 | Desai et al. | Mar 2008 | A1 |
| 20080082427 | Gandhi et al. | Apr 2008 | A1 |
| 20080103846 | Armstrong et al. | May 2008 | A1 |
| 20080120206 | Weiler et al. | May 2008 | A1 |
| 20080147507 | Langhammer | Jun 2008 | A1 |
| 20080191881 | Minerley | Aug 2008 | A1 |
| 20080198761 | Murawski | Aug 2008 | A1 |
| 20080201232 | Walker et al. | Aug 2008 | A1 |
| 20080216001 | Ording | Sep 2008 | A1 |
| 20080228582 | Fordyce et al. | Sep 2008 | A1 |
| 20080281792 | Pickett et al. | Nov 2008 | A1 |
| 20080301095 | Zhu | Dec 2008 | A1 |
| 20090089148 | Gujjar | Apr 2009 | A1 |
| 20090222337 | Sergiades | Sep 2009 | A1 |
| 20090299794 | Marchi et al. | Dec 2009 | A1 |
| 20100138037 | Adelberg et al. | Jun 2010 | A1 |
| 20100169130 | Fineman et al. | Jul 2010 | A1 |
| 20100174596 | Gilman et al. | Jul 2010 | A1 |
| 20100234986 | Clopton et al. | Sep 2010 | A1 |
| 20110010448 | Gill | Jan 2011 | A1 |
| 20110011931 | Farley | Jan 2011 | A1 |
| 20110047022 | Walker et al. | Feb 2011 | A1 |
| 20110054649 | Sarkis | Mar 2011 | A1 |
| 20110054992 | Liberty et al. | Mar 2011 | A1 |
| 20110066504 | Chatow et al. | Mar 2011 | A1 |
| 20110082734 | Zhang et al. | Apr 2011 | A1 |
| 20110191861 | Spears | Aug 2011 | A1 |
| 20110213644 | Phene | Sep 2011 | A1 |
| 20110225023 | Evens et al. | Sep 2011 | A1 |
| 20110238577 | Shuster | Sep 2011 | A1 |
| 20110258083 | Ren | Oct 2011 | A1 |
| 20110258117 | Ahmad | Oct 2011 | A1 |
| 20110313840 | Mason et al. | Dec 2011 | A1 |
| 20120016758 | Bouaziz | Jan 2012 | A1 |
| 20120041675 | Juliver et al. | Feb 2012 | A1 |
| 20120054076 | Wu et al. | Mar 2012 | A1 |
| 20120084119 | Vandehey et al. | Apr 2012 | A1 |
| 20120095882 | Wolff | Apr 2012 | A1 |
| 20120116810 | Knowlton | May 2012 | A1 |
| 20120209661 | Bennett et al. | Aug 2012 | A1 |
| 20120311723 | Britt, Jr. et al. | Dec 2012 | A1 |
| 20130006742 | Richard | Jan 2013 | A1 |
| 20130046634 | Grigg et al. | Feb 2013 | A1 |
| 20130066698 | Levy et al. | Mar 2013 | A1 |
| 20130066733 | Levy et al. | Mar 2013 | A1 |
| 20130124360 | Mitrovic | May 2013 | A1 |
| 20130126610 | Aihara et al. | May 2013 | A1 |
| 20130132140 | Amin et al. | May 2013 | A1 |
| 20130132180 | Aihara et al. | May 2013 | A1 |
| 20130132193 | Aihara et al. | May 2013 | A1 |
| 20130132218 | Aihara et al. | May 2013 | A1 |
| 20130132246 | Amin et al. | May 2013 | A1 |
| 20130132887 | Amin et al. | May 2013 | A1 |
| 20130166332 | Hammad | Jun 2013 | A1 |
| 20130169413 | Schuessler | Jul 2013 | A1 |
| 20130173435 | Cozad, Jr. | Jul 2013 | A1 |
| 20130246176 | Chang et al. | Sep 2013 | A1 |
| 20130246207 | Novak et al. | Sep 2013 | A1 |
| 20130246301 | Radhakrishnan et al. | Sep 2013 | A1 |
| 20130282392 | Wurm | Oct 2013 | A1 |
| 20130311211 | Zafar | Nov 2013 | A1 |
| 20130325672 | Odenheimer et al. | Dec 2013 | A1 |
| 20140012704 | Mizhen et al. | Jan 2014 | A1 |
| 20140025524 | Sims et al. | Jan 2014 | A1 |
| 20140046748 | Nagarajan et al. | Feb 2014 | A1 |
| 20140067596 | McGovern et al. | Mar 2014 | A1 |
| 20140067677 | Ali et al. | Mar 2014 | A1 |
| 20140129135 | Holden et al. | May 2014 | A1 |
| 20140129302 | Amin et al. | May 2014 | A1 |
| 20140129951 | Amin et al. | May 2014 | A1 |
| 20140149201 | Abbott et al. | May 2014 | A1 |
| 20140164126 | Nichols et al. | Jun 2014 | A1 |
| 20140173020 | Reilly et al. | Jun 2014 | A1 |
| 20140180959 | Gillen et al. | Jun 2014 | A1 |
| 20140222711 | Tibbs et al. | Aug 2014 | A1 |
| 20140244416 | Venkat et al. | Aug 2014 | A1 |
| 20140249941 | Hicks et al. | Sep 2014 | A1 |
| 20140279035 | Fleming | Sep 2014 | A1 |
| 20140279204 | Roketenetz et al. | Sep 2014 | A1 |
| 20140279241 | Bartholomew et al. | Sep 2014 | A1 |
| 20140297470 | Ramadge et al. | Oct 2014 | A1 |
| 20140330685 | Nazzari | Nov 2014 | A1 |
| 20140344118 | Parpia et al. | Nov 2014 | A1 |
| 20150066671 | Nichols | Mar 2015 | A1 |
| 20150095091 | Kamdar | Apr 2015 | A1 |
| 20150100433 | Choy et al. | Apr 2015 | A1 |
| 20150134552 | Engels et al. | May 2015 | A1 |
| 20150161564 | Sweeney et al. | Jun 2015 | A1 |
| 20150161714 | Fainshtein | Jun 2015 | A1 |
| 20150178654 | Glasgow et al. | Jun 2015 | A1 |
| 20150269521 | Knapp et al. | Sep 2015 | A1 |
| 20150278912 | Melcher et al. | Oct 2015 | A1 |
| 20150302510 | Godsey et al. | Oct 2015 | A1 |
| 20150310383 | Iser et al. | Oct 2015 | A1 |
| 20150310397 | Xu | Oct 2015 | A1 |
| 20150332414 | Unser | Nov 2015 | A1 |
| 20160086222 | Kurapati | Mar 2016 | A1 |
| 20160092827 | Colodny et al. | Mar 2016 | A1 |
| 20160275424 | Concannon et al. | Sep 2016 | A1 |
| 20160321677 | Dobaj | Nov 2016 | A1 |
| 20170011423 | Douglas et al. | Jan 2017 | A1 |
| 20170032382 | Shulman et al. | Feb 2017 | A1 |
| 20170236152 | Dimaunahan | Aug 2017 | A1 |
| 20170345105 | Isaacson et al. | Nov 2017 | A1 |
| 20180025442 | Isaacson et al. | Jan 2018 | A1 |
| 20180150387 | Kogan et al. | May 2018 | A1 |
| 20180204256 | Bifolco et al. | Jul 2018 | A1 |
| 20180232817 | Isaacson et al. | Aug 2018 | A1 |
| 20180315111 | Alvo et al. | Nov 2018 | A1 |
| 20180365753 | Fredrich et al. | Dec 2018 | A1 |
| 20190272497 | Tingler et al. | Sep 2019 | A1 |
| 20190287125 | Kumar et al. | Sep 2019 | A1 |
| 20190295148 | Lefkow et al. | Sep 2019 | A1 |
| 20190310126 | Gurumohan et al. | Oct 2019 | A1 |
| Number | Date | Country |
|---|---|---|
| 2 332 083 | Jul 2001 | CA |
| Entry |
|---|
| Non-Final Office Action dated Apr. 24, 2017, for U.S. Appl. No. 14/700,044, of Brock, Z., et al., filed Apr. 29, 2015. |
| U.S. Appl. No. 14/700,044 of Brock, Z., et al., filed Apr. 29, 2015. |
| Final Office Action dated Sep. 6, 2017, for U.S. Appl. No. 14/700,044, of Brock, Z., et al., filed Apr. 29, 2015. |
| Non-Final Office Action dated Jun. 15, 2017, for U.S. Appl. No. 14/289,467, of Kumar, A., et al., filed May 28, 2014. |
| Non-Final Office Action dated Jun. 30, 2017, for U.S. Appl. No. 14/522,208, of Cieri, M., et al., filed Oct. 23, 2014. |
| Final Office Action dated Nov. 22, 2017, for U.S. Appl. No. 14/289,467, of Kumar, A., et al., filed May 28, 2014. |
| Final Office Action dated Nov. 24, 2017, for U.S. Appl. No. 14/522,208, of Cieri, M.M., et al., filed Oct. 23, 2014. |
| Non-Final Office Action dated Jan. 26, 2018, for U.S. Appl. No. 14/800,090, of Tsou, V., filed Jul. 15, 2015. |
| Advisory Action dated Feb. 6, 2018, for U.S. Appl. No. 14/289,467, of Kumar, A., et al., filed May 28, 2014. |
| Non-Final Office Action dated Apr. 10, 2018, for U.S. Appl. No. 14/700,044, of Brock, Z., et al., filed Apr. 29, 2015. |
| Non-Final Office Action dated Apr. 18, 2018, for U.S. Appl. No. 14/289,467, of Kumar, A., et al., filed May 28, 2014. |
| Advisory Action dated Nov. 9, 2017, for U.S. Appl. No. 14/700,044, of Brock, Z., et al., filed Apr. 29, 2015. |
| Bidgoli, H., “The Internet Encyclopedia”, John Wiley and Sons, vol. 1, pp. 2735 (2004), Part 1. |
| Bidgoli, H., “The Internet Encyclopedia”, John Wiley and Sons, vol. 1, pp. 2735 (2004), Part 2. |
| Bidgoli, H., “The Internet Encyclopedia”, John Wiley and Sons, vol. 1, pp. 2735 (2004), Part 3. |
| Bidgoli, H., “The Internet Encyclopedia”, John Wiley and Sons, vol. 1, pp. 2735 (2004), Part 4. |
| Bidgoli, H., “The Internet Encyclopedia”, John Wiley and Sons, vol. 1, pp. 2735 (2004), Part 5. |
| Bidgoli, H., “The Internet Encyclopedia”, John Wiley and Sons, vol. 1, pp. 2735 (2004), Part 6. |
| Bidgoli, H., “The Internet Encyclopedia”, John Wiley and Sons, vol. 1, pp. 2735 (2004), Part 7. |
| Bidgoli, H., “The Internet Encyclopedia”, John Wiley and Sons, vol. 1, pp. 2735 (2004), Part 8. |
| Bidgoli, H., “The Internet Encyclopedia”, John Wiley and Sons, vol. 1, pp. 2735 (2004), Part 9. |
| Bidgoli, H., “The Internet Encyclopedia”, John Wiley and Sons, vol. 1, pp. 2735 (2004), Part 10. |
| Bidgoli, H., “The Internet Encyclopedia”, John Wiley and Sons, vol. 1, pp. 2735 (2004), Part 11. |
| Bidgoli, H., “The Internet Encyclopedia”, John Wiley and Sons, vol. 1, pp. 2735 (2004), Part 12. |
| Bidgoli, H., “The Internet Encyclopedia”, John Wiley and Sons, vol. 1, pp. 2735 (2004), Part 13. |
| Bidgoli, H., “The Internet Encyclopedia”, John Wiley and Sons, vol. 1, pp. 2735 (2004), Part 14. |
| Bidgoli, H., “The Internet Encyclopedia”, John Wiley and Sons, vol. 1, pp. 2735 (2004), Part 15. |
| Bidgoli, H., “The Internet Encyclopedia”, John Wiley and Sons, vol. 1, pp. 2735 (2004), Part 16. |
| Bidgoli, H., “The Internet Encyclopedia”, John Wiley and Sons, vol. 1, pp. 2735 (2004), Part 17. |
| Chen, F., and Samroengraja, R., “A Staggered Ordering Policy for One-Warehouse, Multiretailer Systems,” Operations Research, vol. 48, Issue 2, pp. 281-293 (Apr. 1, 2000). |
| Cox, J.F., III, and Walker, E.D., II, “The Poker Chip Game: A Multi-product, Multi-customer, Multi-echelon, Stochastic Supply Chain Network Useful for Teaching the Impacts of Pull versus Push Inventory Policies on Link and Chain Performance,” Informs Transactions on Education, vol. 6, Issue 3, pp. 3-19 (May 1, 2006). |
| Ross, D.F., “Replenishment Inventory Planning,” Chapter 7 of Distribution Planning and Control: Managing in the Era of Supply Chain Management, Chapman & Hall, pp. 263-319 (1996). |
| Wah, B.W., “Wiley Encyclopedia of Computer Science and Engineering,” Wiley-Interscience, vol. 1, pp. 1-2365 (Nov. 2008). |
| “Uber-Android Apps on Google Play,” dated Nov. 10, 2014, Retrieved from the Internet URL: https://play.google.com/store/apps/details?id=com.ubercab&hl=en, on Nov. 12, 2014, pp. 1-2. |
| Non-Final Office Action dated Jul. 6, 2018, for U.S. Appl. No. 14/800,021, of Tsou, V., filed Jul. 15, 2015. |
| Final Office Action dated Jul. 26, 2018, for U.S. Appl. No. 14/800,090, of Tsou, V., filed Jul. 15, 2015. |
| Non-Final Office Action dated Aug. 6, 2018, for U.S. Appl. No. 14/964,231, of Jen, M., et al., filed Dec. 9, 2015. |
| Non-Final Office Action dated Aug. 28, 2018, for U.S. Appl. No. 14/522,208, of Cieri, M.M., et al., filed Oct. 23, 2014. |
| Non-Final Office Action dated Sep. 6, 2018, for U.S. Appl. No. 15/858,911, of Funk, M., et al., filed Dec. 29, 2017. |
| Non-Final Office Action dated Sep. 14, 2018, for U.S. Appl. No. 14/964,263, of Jen, M., et al., filed Dec. 9, 2015. |
| Final Office Action dated Sep. 24, 2018, for U.S. Appl. No. 14/700,044, of Brock, Z., et al., filed Apr. 29, 2015. |
| Advisory Action dated Oct. 30, 2018, for U.S Appl. No. 14/800,090, of Tsou, V., filed Jul. 15, 2015. |
| Final Office Action dated Nov. 14, 2018, for U.S. Appl. No. 14/289,467, of Kumar, A., et al., filed May 28, 2014. |
| Advisory Action dated Dec. 5, 2018, for U.S. Appl. No. 14/700,044, of Brick Z., et al., filed Dec. 9, 2015. |
| Final Office Action dated Jan. 17, 2019, for U.S. Appl. No. 14/964,263, of Mark, J., et al. filed Dec. 9, 2015. |
| Final Office Action dated Jan. 25, 2019, for U.S. Appl. No. 14/522,208, of Cieri, M.M., et al., filed Oct. 23, 2014. |
| Notice of Allowance dated Jan. 29, 2019, for U.S. Appl. No. 15/858,911, of Funk, M., et al., filed Dec. 29, 2017. |
| Final Office Action dated Feb. 4, 2019, for U.S. Appl. No. 14/800,021, of Tsou, V., filed Jul. 15, 2015. |
| Final Office Action dated Feb. 6, 2019, for U.S. Appl. No. 14/964,231, of Jen, M., et al. filed Dec. 9, 2015. |
| Notice of Allowance dated Feb. 7, 2019, for U.S. Appl. No. 14/289,467, of Kumar, A., et al. , filed May 28, 2014. |
| Non Final Office Action dated Sep. 20, 2019, for U.S. Appl. No. 14/800,090, of Tsou, V., filed Jul. 15, 2015. |
| Advisory Action dated Jun. 22, 2020, for U.S. Appl. No. 14/800,090, of Tsou, V., filed Jul. 15, 2015. |
| Non Final Office Action dated Jun. 29, 2020, for U.S. Appl. No. 14/964,263, of Jen, M., et al., filed Dec. 9, 2015. |
| Advisory Action dated Apr. 1, 2019, for U.S. Appl. No. 14/964,263, of Mark, J., et al. filed Dec. 9, 2015. |
| Advisory Action dated Apr. 22, 2019, for U.S. Appl. No. 14/522,208, of Cieri, M.M., et al., filed Oct. 23, 2014. |
| Advisory Action dated Apr. 24, 2019, for U.S. Appl. No. 14/800,021, of Tsou, V., filed Jul. 15, 2015. |
| Advisory Action dated Apr. 30, 2019, for U.S. Appl. No. 14/964,231, of Jen, M., et al., filed Dec. 9, 2015. |
| Non Final office Action dated May 31, 2019, for U.S. Appl. No. 14/800,021, of Tsou, V., filed Jul. 15, 2015. |
| Non Final Office Action dated Jun. 14, 2019, for U.S. Appl. No. 14/522,208, of Cieri, M.M., et al., filed Oct. 23, 2014. |
| Notice of Allowance dated Jun. 20, 2019, for U.S. Appl. No. 14/964,231, of Jen, M., et al., filed Dec. 9, 2015. |
| Non-Final Office Action dated Jun. 3, 2019, for U.S. Appl. No. 14/700,044, of Brock, Z., et al., filed Apr. 29, 2015. |
| Non-Final Office Action dated Jul. 30, 2019, for U.S. Appl. No. 14/964,263, of Jen, M., et al., filed Dec. 9, 2015. |
| Non Final Office Action dated Mar. 19, 2020, for U.S. Appl. No. 16/204,583, of Gjertson, N., et al., filed Nov. 29, 2018. |
| Final Office Action dated Mar. 20, 2020, for U.S. Appl. No. 14/800,090, of Tsou, V., filed Jul. 15, 2015. |
| Non Final Office Action dated Mar. 26, 2020, for U.S. Appl. No. 16/431,671, of Kumar, A., et al., filed Jun. 4, 2019. |
| Advisory Action dated Mar. 30, 2020, for U.S. Appl. No. 14/964,263, of Jen, M., et al., filed Dec. 9, 2015. |
| Final Office Action dated Dec. 27, 2019, for U.S. Appl. No. 14/522,208, of Cieri, M.M., et al., filed Oct. 23, 2014. |
| Final Office Action dated Jan. 22, 2020, for U.S. Appl. No. 14/964,263, of Jen, M., et al., filed Dec. 9, 2015. |
| Final office Action dated Jan. 29, 2020, for U.S. Appl. No. 14/800,021, of Tsou, V., filed Jul. 15, 2015. |
| Non Final Office Action dated Mar. 10, 2020, for U.S. Appl. No. 16/051,257, of Capers M., et al., filed Jul. 31, 2018. |
| Non-Final office Action dated Jun. 12, 2020, for U.S. Appl. No. 14/800,021, of Tsou, V., filed Jul. 15, 2015. |
| Final Office Action dated Jul. 16, 2020, for U.S. Appl. No. 16/051,257, of Capers M., et al., filed Jul. 31, 2018. |
