System and Method for Multiple Product and Price Discovery

A system and computer-implemented method are disclosed for optimizing product purchasing to enable consumers to efficiently locate and purchase multiple goods and/or services. A centralized product and price discovery system employs a computer implemented method for determining an optimized purchasing plan using user defined and system defined preferences including the cost of individual products at different locations, product specification differentiation (size, weight, origin of manufacture, user rating), and the cost and/or time to obtain the products from those locations. The optimized plan depends on such factors as the type of transportation employed or the desired maximum distance to be traveled to obtain all the products. The system also improves a vendor's ability to understand the purchasing behaviour of consumers (by region, interests etc.) including the current demand, pricing and frequency of purchases and the type of products being purchased together.

DETAILED DESCRIPTION OF THE INVENTION

Definitions

The term “products,” refers to both goods and services herein for simplicity, and may also be referred to as items. A product may refer to anything that a vendor or other supplier provides to a consumer in exchange, in whole or in part, for money or something having monetary value provided by the consumer to the vendor.

The terms “user,” “consumer,” and “vendor” are used in context to describe the association of a person with the PPDS, a device and the network and may in some cases be the same person. A consumer may be an individual, a group of individuals, a corporate buyer, a charitable organization, or any other consuming entity or representative thereof that obtains a product from a vendor in exchange for consideration.

The term “vendor location” may refer to a point of sales, such as a brick and mortar retail outlet, a vendor's warehouse, a manufacturer's premises, a pick-up point, or any other physical location from where a product may be obtained.

The term “preferences” refers to user defined features of the invention including settings that are adjustable by consumers, vendors, systems operators, or automatically by analysis systems, and can include adjustments made on a real-time basis or based on historical use.

The term “consumer identified location” refers to a location associated with the consumer. It can refer to the location of a consumer, such as the consumer's home, temporary place of residence, place of work, place where visiting, vacation location or any current location. Such location may be identified by the consumer from a pull-down list, or identified automatically by a GPS device. It is also possible to enter the address or coordinates, use 3rdparty services to determine the location, use other technologies such as cellular or Wi-Fi triangulation. It is to be understood to be the location from which a consumer starts the trip to the one or more vendors from which the multiple products are to be obtained. By default, the consumer identified location is also the location at which the trip to obtain the products ends. However, this end location may be specified by the consumer to be a different location, which would be applicable if the consumer is purchasing the products en route to another destination.

The term “network” can include both a mobile network and data network without limiting the terms meaning, and includes the use of wireless (2G, 3G, 4G, WiFi, WiMAX, Wireless USB, Zigbee, Bluetooth and satellite), and/or hard wired connections such as internet, ADSL, DSL, cable modem, T1, T3, fibre, dial-up modem, and may include connections to flash memory data cards and/or USB memory sticks where appropriate. A network could also mean dedicated connections between computing devices and electronic components, such as buses for intra-chip communications.

The term “module” can refer to any component in this invention and its network and to any or all of the features of the invention without limitation.

The term “server” is used to refer to any computing device, or group of devices, that provide the functions described herein as being provided by one or more servers.

The term “processor” is used to refer to any electronic circuit or group of circuits that perform calculations, and may include, for example, single or multicore processors, an ASIC, and dedicated circuits implemented, for example, on a reconfigurable device such as an FPGA.

The term “database” refers to both persistent and volatile means of storing information suitable for performing computing functions such as searching, inserting and updating. Typically, these are relational databases such as in MySQL. It is also possible to use no-SQL databases, in-memory data structures, plain computer files or any other means of storing data. A database may be a parallel system database in which the processors are tightly coupled and constitute a single database system or may be a distributed database in which storage devices are not all attached to a common processing unit such as a CPU, and is controlled by a distributed database management system. A distributed database system may be stored in multiple computers, located in the same physical location; or may be dispersed over a network of interconnected computers.

The term “hardware” includes, but is not limited to, the physical housing for a computer as well as the display screen, connectors, wiring, circuit boards having processor and memory units, power supply, and other electrical components. It could also be a system on chip, or system on package.

The term “software” includes, but is not limited to, program code that performs the computations necessary for calculating and optimizing user inputs, the reporting and analysis of product specific data, displaying information, and, managing of input and output data. Software can be both internal to the PPDS and external, i.e. consumer and vendor systems, and a combination of multiple systems.

The term “firmware” includes, but is not limited to, program code and data used to control and manage the interactions between the various modules of the system. Firmware persistently stores updatable processor readable instructions and data, which may be used for part of the PPDS.

The detailed descriptions within are presented largely in terms of methods or processes, symbolic representations of operations, functionalities and features of the invention. These method descriptions and representations are the means used by those skilled in the art to most effectively convey the substance of their work to others skilled in the art. A software implemented method or process is here, and generally, conceived to be a self-consistent sequence of steps leading to a desired result. These steps involve physical manipulations of physical quantities. Often, but not necessarily, these quantities take the form of electrical or magnetic signals capable of being stored, transferred, combined, compared, and otherwise manipulated. It will be further appreciated that the line between hardware, software and firmware is not always sharp, it being understood by those skilled in the art that software implemented processes may be embodied in hardware, firmware, or software, in the form of coded instructions such as in microcode and/or in stored programming instructions.

All of the methods and processes described herein may be embodied in, and fully automated via, software code modules executed by one or more computing devices. The code modules may be stored in any type(s) of computer-readable media or other computer storage system or device (e.g., hard disk drives, solid state memories, etc.). The methods may alternatively be embodied partly or wholly in specialized computer hardware, such as ASIC or FPGA circuitry. The results of the disclosed methods and tasks may be persistently stored by transforming physical storage devices, such as solid state memory chips and/or magnetic disks, into a different state.

In general, unless otherwise indicated, singular elements may be in the plural and vice versa with no loss of generality. The use of the masculine can refer to masculine, feminine or both.

The present description is of the best presently contemplated mode of carrying out the subject matter disclosed and claimed herein. The description is made for the purpose of illustrating the general principles of the subject matter and not to be taken in a limiting sense; the subject matter can find utility in a variety of implementations without departing from the scope of the disclosure made, as will be apparent to those of skill in the art from an understanding of the principles that underlie the subject matter.

The present invention provides a PPDS for the analysis and optimization of the purchase of multiple products and services. The system includes hardware and software, and/or firmware for managing a rule based system that incorporates individual user defined preferences and user preference patterns for specific fields, such as region, product type, product country of origin, user rating, price range, location, etc. A use pattern can be transferred from one individual user to another or be shared to assist with reducing the number of selective preferences. User preference patterns and product grouping patterns can be assigned to geospatial regions and be used for comparative analysis and to improve efficiency within the system.

Consumer Side of PPDS

In many cases, consumers are interested in comparing various offerings, not only in terms of quality, but also in terms of pricing. The PPDS is a technology that improves on that experience. The PPDS provides an interface through which consumers can enter a description of multiple items (products) they are interested in, together with a general location or a specific address such as a home or office.

The PPDS then uses that information to first locate which vendors carry or offer the products specified by the consumer. This is done in consideration of various product attributes or preferences the consumer has specified (if any), such as quality, price range, origin, service level, vendor/product reputation, and user rating. Secondly the PPDS then determines the distances between locations of the qualifying vendors determined in the first instance by the consumer selected preferences, and the location of the general area or address specified by the user. Such distances may be determined by computation by the processor, or by the processor reading previously computed distances, or by reading them from another source. The PPDS then computes the total cost of purchasing each of the products at each of the locations. The total cost is the actual price offered by the vendor, as well as optionally the cost of getting the product; for instance, using a delivery service, private vehicle, or public transit. The PPDS then performs optimizations to determine the best (i.e. the most cost or time effective way, within optional constraints) of getting all the desired products. In the optimization process, the emphasis is placed on the total combined cost of acquiring the products. The results are then displayed back to the user.

The consumer can view the optimized solution of purchasing the products. The solution consists of instructions on where to obtain the products. The solution optionally includes an optimal sequence of obtaining the products and optionally an optimal route to take to obtain them. In some cases, it is expected that the consumer will accept whatever optimization solution the PPDS produces, without reviewing it, which may be the case, for example, if the consumer requires all products to be obtained using a delivery service.

The user can additionally modify any of the attributes of the product or user preferences at any time during the process in order to review and compare various individual and total price points.

Finally, the consumer can either reserve or order the product; or print, store or share the instructions. Optionally, the consumer can follow detailed routing or navigating instructions to get to the location(s).

Once at a location, the consumer can either pick up a pre-reserved product, or use PPDS instructions to determine where the product can be found, for instance, an aisle in a store, or use PPDS indoor navigation to navigate to the precise location (such as an aisle in a store).

Vendor Side of PPDS

The PPDS offers vendors the ability to enter the products carried (together with their attributes, quantity, and pricing) and specify promotions, (bulk) discounts, or sales, either at present or a future date. The PPDS uses this information to determine if it would be more cost efficient to obtain some or all of the products the consumer wants presently or at a future date in order to take advantage of lower pricing. The possibility of future cost savings can then be conveyed to the consumer. Also, if there are bulk/volume/group discounts, the PPDS can inform the consumer and give the consumer the option to aggregate their order with those of other consumers, or alert friends/family/colleagues such that they can purchase together.

The PPDS also gives vendors the ability to track the amount and price of sales; compare pricing with other vendors, either in the same area or region, or compare different areas and regions; determine historical purchases to be able to appropriately respond to demand; view predictions about current and future demands; track product requisition and returns; and track consumer satisfaction.

Both consumer and vendor interfaces can either be web interfaces, or a native applications running on devices such as a personal computer, smart phone, or tablet. The core purpose of the PPDS is to increase efficiency, both market efficiency by providing business/market intelligence, as well as cost efficiency from a consumer's perspective. The PPDS assembles together various technologies in a unique way to provide these capabilities.

Exemplary PPDS Architecture Configuration

The architecture for an exemplary PPDS comprises one or more devices which provide interfaces to consumer and vendor users, as well as backend functionality which includes optimization data processing, data storage, data presentation, and data manipulation capabilities among others. In a typical configuration, the devices are microprocessor based machines which execute software, such as personal computers, servers, smart phones, or tablets.

FIG. 1shows an example of a PPDS configuration. The arrows shown between the consumer user interface10, vendor modules (12,14,16) and within the PPDS backend18are all representative of the bidirectional flow of data between processing modules. The processing modules make up a software package required to perform the disparate processing functions of each module. The individual modules that make up the PPDS backend18may be on separate servers with their own hardware, memory and software in communication with each other or two or more may be part of a single server or a combination of servers.

Still referring toFIG. 1, a consumer operated device (i.e. consumer device) provides a consumer user interface10to a consumer; for instance, via a web-browser or a native application running on a personal computer, tablet or smart phone. The device communicates with the PPDS backend18via a network or other medium20, for example, the internet. The consumer device may be owned by the consumer, it may be a device used by the consumer, or a device used by a representative of the consumer, for example, if the consumer is a business or a manufacturing company that wants to purchase supplies.

The consumer user interface10presents to the user one of or both of the following: 1) an organized category from which the consumer can select or specify products and/or their attributes; and 2) a mechanism for inputting search strings or expressions, for example, “sun glass.” One example of an organized category is a collection of menus and/or check boxes as in any typical graphical user interface. This information is obtained either from a PPDS database22or vendor database12via a module24which can be a web server, application server or middleware. A typical example of obtaining this information is through a combination of internet protocols (such as HTTP requests) and standard database queries.

A search engine26then processes the user entered information to return found products to the consumer. The information that is returned to the consumer is obtained from a PPDS database22and/or one or more vendor database(s)12. A search engine26can be a stand alone module, for instance, a semantic search engine, or it can be part of a standard database query mechanism.

Additionally, the consumer operated device is used to obtain a consumer's desired location, such as an address, or a generic location. This could either be through direct address entry, selection from a menu, or by automated means through the consumer operated device's geo-location capabilities such as its GPS features.

Backend18is typically on an application server or web server, implemented using one of a standard of technologies such as server side scripting languages or traditional programming languages such as Java™. The module18comprises the presentation layer28for obtaining, inserting or updating database information, and for presenting the optimization problem at hand, as well as obtaining its solution.

The presentation layer28is comprised of 1) a collection of inter-module communication interfaces (such as one or more Application Programming Interfaces (API), files or memory objects, and/or generic protocols such as TCP/IP); 2) a problem encoder module30; and 3) a solution decoder module32. The problem encoder module30of the presentation layer28converts database or in-memory information into a form that can be processed by either a generic solver engine34or a dedicated algorithm implementation module36. In the exemplary PPDS architecture configuration shown inFIG. 1, the form of the information is a computable readable representation of an abstract mathematical optimization problem. The presentation layer28also includes a solution decoder module32for performing the reverse operation of the problem encoder module30: i.e. it obtains a computer readable solution of the abstract mathematical problem from either the generic solver engine module34or dedicated algorithm implementation module36, and converts it into a form suitable for database storage and presentation to a consumer device via the web server, application server or middleware module24.

For example, a consumer specifies through a consumer user interface10a list of products, together with their attributes. A combination of a product (e.g. “sun glasses”) and its user preferred attributes (e.g. “round”, “Chinese-made”) is considered a single item. The presentation layer28then obtains from one of or a combination of PPDS database22and vendor database(s)12the price information for each specified item for each vendor. This information is then used to obtain candidate vendor locations from which to buy each item. In some embodiments, vendor locations may be manually entered, if necessary. Further, the presentation layer28either computes the distances between the candidate vendor locations, or obtains the pre-computed information which is stored in PPDS database22. A full calculation requires determining the distances from each candidate vendor location to every other candidate vendor location. Additionally, distances between the consumer identified location (or as obtained from geo-location capability of the consumer user device) and each of the candidate vendor locations is computed.

These distances are then used to compute the travel cost, if any, between the locations depending on the mode of travel specified by the consumer (for instance, public transit, walking, cycling, type of specific car, delivery service, etc). For example, the travel cost may be a predetermined, configurable amount per unit distance travelled, multiplied by the total distance the consumer needs to travel to obtain all the products. In other cases, the cost of public transport may be taken into account. In still other cases, a component of or the whole cost of travel may be based on the total time estimated for the trip multiplied by a cost per unit time. The problem can be represented as a graph, which is shown inFIG. 2.

Optionally, still referring toFIG. 1, a consumer can reserve, order, or pre-pay for items directly online. In that case, the order handling module40updates the databases, processes payments (or delegates payment processing to another software not part of the PPDS backend18. The order module40then forwards order information to the vendor interface module16for the vendor to prepare the order.

The databases12,22store information on products, stock, pricing, discounts, product attributes, statistics, and other management information such as user accounts and billing. The PPDS backend18maintains its own database22. Additionally, vendors can maintain their own databases12, typically, in conjunction with, or as part of, an inventory or order/sales management software. If a vendor does not maintain their own database, they use the PPDS database22.

The statistics engine module42is the central piece for providing business intelligence. It uses information stored in the databases12,22by other modules to derive additional information and to present that information to consumers and vendors. The information may include 1) amounts and prices of various products sold; 2) price differentials; 3) historical purchases; 4) products purchased together or at the same time; 5) product and/or vendor ratings; 6) rate and frequencies at which items are being sold; and 7) items desired by consumers, but not carried by a vendor.

On the vendor side, a vendor user interface14and vendor database(s)12communicate with the PPDS backend18via vendor interface module16. The vendor interface module16depends on software configuration at a vendor's location. For example, if a vendor is using an inventory or order/sales management software, this software is vendor interface module16. The manner in which the PPDS backend18communicates with a vendor interface module16then is fully specified by vendor interface module16either through generic protocols, or through proprietary protocols or APIs. In the absence of a management software, the interface is simply a direct connection to a vendor's database12if available, and to a vendor user interface14running on vendor user's device. TCP/IP can be used in such instances.

The vendor user's device provides a user interface14to the vendor in a similar manner to the consumer's user device. The vendor can use information from the PPDS backend18for performing activities such as updating stocks, view pricing and statistics, and processing or preparing orders.

Exemplary Problem

Referring toFIG. 2, an exemplary optimization problem is shown. In graph theoretical terms, each location is a node, and a path of getting from one location or node to the other is represented as an edge. InFIG. 2the center node50represents a consumer's location and the outer nodes represent vendor locations with each vendor showing which of five queried items they have available and their price. Vendor 1 is represented by node51and has items 1 and 2 for sale. Vendor 2 is represented by node52and has all 5 items for sale. Vendor 3 is represented by node53and has items 1, 3 and 4 for sale. Vendor 4 is represented by node54and has items 3 and 5 for sale. The costs described above are then the edge weights, represented inFIG. 2as w1-w10 between the nodes. The graph does not need to be a complete graph as shown inFIG. 2. The actual type depends on the physical geographical characteristics of the region in question. Further, it may be computationally advantageous to omit some physically possible edges in order to reduce the size of the problem (either because of memory constraints in the system, or simply to reduce the run time of the solver).

The problem graphically shown inFIG. 2is then to obtain all 5 items, from a possible four candidate locations while minimizing the combined prices and the sum of the weights of the edges that need to be visited to retrieve the items, and to go back to the original consumer location. Classically, this is a combinatorial optimization problem.

Optionally, the problem can be augmented with additional constraints such as a maximum total travel distance or maximum total time spent retrieving items. For example, for those who have to walk, a maximum total distance to obtain the items may not exceed a certain number, which represents the distance traveled to obtain the items. Another example, for those in a rush, a maximum total time spent to obtain the items may not exceed a certain amount of time, which may include a combination of travel time and time spent in a vendor location. Additionally, the problem is extensible, in order to simultaneously optimize a purchasing solution for multiple buyers, either individually, or in aggregation.

The problem can be solved using a generic engine34capable of solving generic combinatorial problems. One such example is the open source software suite Ipsolve™. The actual manner of integrating the solver and the presentation layer28depends on the interface exposed by the engine. For automation purposes, as is required here, the interface could be through files, which encode the abstract mathematical problem in a suitable format, or through an API.

It is also possible to solve the problem using a dedicated module36which implements an algorithm specifically designed to solve this problem. There are many possible variations of such algorithms. As an example, a simple algorithm could use brute force to systematically enumerate all possible candidates for the solution and then compare all possible combinations.

Once a solution has been obtained, the solution is directed from the generic engine module34or dedicated module36to solution decoder module32which appropriately formats and presents the solution to the consumer through the consumer user interface10on the consumer's device. The solution advises the consumer where to buy, when to buy a specific subset of items if there are discounts at later dates, as well as the traveling sequence. Optionally, the web module24can also generate and present navigation instructions, or generate a summary of sequences which can then be utilized by the consumer's device to generate and present navigation instructions. The consumer can then print, store, or follow instructions to the vendors. Optionally, delivery instructions can be sent or displayed to a delivery service. A consumer's order may be divided between different delivery services, and each may be provided with its corresponding portion of the route.

Exemplary Solution

A very simple example can be considered in which only items 3 and 5 are to be bought. The cost of the items is shown in Table 1, these items being available only from vendors 2, 3 and 4 (52,53,54respectively inFIG. 2).

Table 2 shows the weights of the edges between the consumer50and the vendors52,53,54. The weights, in their simplest form may be a measurement of the distance of each edge, which would be applicable if the consumer intended visiting the vendors on foot. In this example, the weights used are the distances in kilometres of the edges. Distances would also be suitable weights for driving, provided the cost of driving were determined as a certain price per kilometre multiplied by the distance travelled. However, the costs of toll roads may be included if the vendors are to be visited by car.

Now, a consumer who wants to purchase the items 3, 5 by visiting the vendors on foot may set a preference that the total distance should be less than 3 km. In this case, the result produced is that both items must be purchased from vendor 2, as shown in the first result row of Table 3. However, if the preference is set to be less than 8 km, then other options appear as possible purchasing plans, as shown in the last four rows of Table 3. The system would identify the optimum solution as the one with the lowest total cost of the four possible solutions, which would be to buy item 3 from vendor 2 and item 5 from vendor 4. Note that this is a different recommendation to before. Consumers may input more relaxed preferences if they are cycling rather than walking.

In another scenario, the user may want to visit the vendors by car. In this case, there is a financial cost associated with each of the edges. To keep the example simple, the cost is $1 per km, which covers fuel and depreciation of the car. The results of calculating the solution to such a problem are shown in Table 4. It can be seen that the total cost of obtaining both items is lowest if both items are purchased from vendor 2, even though the actual cost of the items themselves are lower at the other vendors.

To indicate the complexity of the problem at hand, even for such a simple scenario as the one we are considering, the cost per km of traveling by car has now been changed to $0.20/km. This changes the optimum solution provided by the system quite dramatically, as can be seen in Table 5. Here, the optimum solution is to buy item 3 from vendor 3 and item 5 from vendor 4, as shown in the last row of the table.

It will be seen that many other factors may be included in the values of the weights. For example, the direction travelled on an edge may lend a different weight to it, for example if a one-way system is to be navigated. The number of left-hand turns may also add to the weight of an edge, and may be different one way compared to the other. The side of the street the vendors are on may impact the weights. The average driving time may also influence the weights of the edges, so that by car the optimum total price of obtaining the items is based on the purchase cost of the items, the cost of travelling and the time taken to complete the trip.

Flow Diagram

Referring now to the flow diagram ofFIG. 3, one exemplary embodiment of an information processing method100for processing a consumer's product requests is shown. A consumer's request for a product along with any consumer preferred attributes of the product is received by a PPDS application server (PPDS backend module24) at step102. The request may be received directly from a consumer-owned device or another device that the consumer uses, and may originate from a standing order created by the consumer and stored in the PPDS. This processing sequence is repeated via step104until a consumer has entered all their desired items. At step106, consumer identification of a location, for instance a home or work address, is also received by PPDS application server (PPDA backend module24) and processed. The location may be received from the consumer device, from storage or via other means. For example, the PPDS may already have the location of the consumer stored, and it may have been previously entered by the consumer via any device, or determined by a consumer device or other devices interacting with the consumer device. Next, at step108a customer's preferred maximum travel distance and/or preferred mode of travel is also received by PPDS application server (PPDA backend module24) and processed. The consumer's location and mode of travel can be alternately identified1) from the customer entering an address and travel mode, 2) from geo-location capabilities of a consumer's interfacing device, and/or3) from a consumer's default preference data file stored on PPDS database22. A search engine26is utilized to determine which vendors have a qualifying product at step110. Such determination step may be realized by the processor searching the vendor and product databases, or may be performed by the processor simply reading the qualifying vendors from storage, for example, if a similar search had already been done by the same or a different consumer. Product information may be accessed from either the PPDS database22or from individual vendor databases12. For every vendor with at least one qualifying product, a data string is added to a qualifying list or group at step112for problem encoding by the problem encoder30. A data string contains retrieved data such as the vendor name, location, product description, price (historic, current, future), product origin, product weight, product size, product location, quantity available, store rating and product rating. For any items not available, consumer preferences may optionally be relaxed; for instance the maximum distance preferences may be enlarged or product attributes removed in order to offer possible similar qualifying products for the consumer to review and reject or approve. Relaxation of preferences may be automatic and notified to the consumer, or the extent to which preferences are relaxed may be set as a preference by the consumer. Once a consumer has entered all their desired qualifying items, the problem encoder30encodes the resulting accumulated data strings and determines an optimized purchasing plan at step114via either the generic solver engine34or a dedicated algorithm solver engine36, with the optimization default being to minimize overall product costs within a defined maximum travel distance. As described above, the optimization plan may use time rather than distance or a combination of the two, to determine an optimized purchasing plan. The optimized product purchasing solution is then decoded at solution decoder32and communicated to the consumer as a purchasing sequence plan at step116via the application server (PPDS web module24) to be displayed on a consumer's device via consumer user interface10. An optional map may be provided to the consumer or a directive link to a navigational application either on the consumer's interfacing device or a navigational application within the PPDS system or a 3rdparty platform.

The foregoing embodiments of the invention are examples and can be varied in many ways. For example, steps in the flowchart may be performed in a different order to that shown, certain steps may be omitted or others may be added, while still providing a suitable embodiment of the invention. At least part of the server and part of the network may be integrated in one computing device. The database and the server may be incorporated in the same or different devices. The various databases may be stored in the same or different devices. Any determination step taken by the processor may be undertaken by the processor performing a calculation or by reading data that is stored, either within the PPDS or from an external source.