US11640579B2 - Method, system, server processing system computer readable medium for managing inventory - Google Patents

Abstract

Disclosed is a method, server processing system, system and computer readable medium for managing inventory. In one aspect, the method includes, in a server processing system, steps of: receiving, from a plurality of merchant devices including a first and second merchant device associated with a first and second merchant respectively, inventory data and a plurality of merchant locations which are stored in a data store; receiving, from the first merchant device, data indicative of a requested good that is not stocked by the first merchant; determining that the requested good is stocked by a second merchant using the inventory data of one or more merchants that are located within a proximity of the location of the first merchant; and transferring, to the second merchant device, a request to facilitate provision of the requested good to a customer of the first merchant.

Description

CROSS-REFERENCE TO RELATED APPLICATION

This application is a U.S. National Stage filing under 35 U.S.C. § 119, based on and claiming benefits of and priority to Singapore Patent Application No. 10201703945W filed on May 15, 2017. The entire disclosure of the above application is incorporated herein by reference.

TECHNICAL FIELD

The present invention relates to a method, server processing system and computer readable medium for managing inventory between merchants.

BACKGROUND

A common problem that merchant's face relates to the management of inventory, particularly in relation to inventory which may be perishable. Merchants may be required to predict sales of the perishable items in order to order an appropriate amount of inventory. In the event that a merchant has under-predicted future sales, the merchant may run out of inventory resulting in a loss of sales. In the event that a merchant has over-predicted future sales, the merchant may have inventory that perishes which can no longer be sold.

The reference in this specification to any prior publication (or information derived from it), or to any matter which is known, is not, and should not be taken as, an acknowledgement or admission or any form of suggestion that prior publication (or information derived from it) or known matter forms part of the common general knowledge in the field of endeavour to which this specification relates.

SUMMARY

In a first aspect there is provided a method for managing inventory, the method including, in a server processing system:

receiving, from a plurality of merchant devices including a first and second merchant device associated with a first and second merchant respectively, inventory data and a plurality of merchant locations which are stored in a data store;

receiving, from the first merchant device, data indicative of a requested good that is not stocked by the first merchant;

determining that the requested good is stocked by a second merchant using the inventory data of one or more merchants that are located within a proximity of the location of the first merchant; and

transferring, to the second merchant device, a request to facilitate provision of the requested good to a customer of the first merchant.

In a second aspect there is provided a server processing system for managing inventory, wherein the server processing system is configured to:

receive, from a plurality of merchant devices including a first and second merchant device associated with a first and second merchant respectively, inventory data and a plurality of merchant locations which are stored in a data store;

receive, from the first merchant device, data indicative of a requested good that is not stocked by the first merchant;

determine that the requested good is stocked by a second merchant using the inventory data of one or more merchants that are located within a proximity of the location of the first merchant; and

transfer, to the second merchant device, a request to facilitate provision of the requested good to a customer of the first merchant.

In a third aspect there is provided a non-transitory computer storage medium including executable instructions which, when executed by one or more processors, configure a server processing system for managing inventory, wherein the server processing system is configured to:

receive, from a plurality of merchant devices including a first and second merchant device associated with a first and second merchant respectively, inventory data and a plurality of merchant locations which are stored in a data store;

receive, from the first merchant device, data indicative of a requested good that is not stocked by the first merchant;

determine that the requested good is stocked by a second merchant using the inventory data of one or more merchants that are located within a proximity of the location of the first merchant; and

transfer, to the second merchant device, a request to facilitate provision of the requested good to a customer of the first merchant.

In a fourth aspect there is provided a system including:

the server processing system according to the second aspect; and

the plurality of merchant devices including the first merchant device and the second merchant device.

BRIEF DESCRIPTION OF THE FIGURES

Example embodiments should become apparent from the following description, which is given by way of example only, of at least one preferred but non-limiting embodiment, described in connection with the accompanying figures.

FIG.1 illustrates a functional block diagram of an example processing system that can be utilised to embody or give effect to a particular embodiment;

FIG.2 illustrates an example network infrastructure that can be utilised to embody or give effect to a particular embodiment;

FIG.3 is a system diagram representing an example system for managing inventory;

FIG.4 is a flowchart representing an example method performed by a server processing system for managing inventory;

FIG.5 is a schematic diagram of an example merchant device; and

FIG.6 is a flowchart representing an example method of a merchant supplying data to a server for storage in a data store including inventory data;

FIG.7 is a flowchart representing an example method of a merchant requesting provision of a requested good by another merchant; and

FIG.8 is a flowchart representing a method of a server processing system performing bulk settlement of merchant to merchant sales over a period of time.

DETAILED DESCRIPTION

The described method and system enables a merchant to be able to facilitate a sale of one or more goods which are not in stock by arranging for the provision of the requested inventory item by another merchant. This minimises a likelihood of disappointment for a consumer as a desired good is likely to be available. Furthermore, individual merchants need not be overly concerned about maintaining (and paying for) storage place for storage as their respective stock levels can be reduced if there are “shared” stocks of goods amongst groups of merchants. In addition, the optimisation of stock levels for each respective merchant can minimise wastage of goods, particularly for goods with a shelf life.

In general terms, whenever the consumer visits a merchant which does not possess stocks of a desired good, a preferably close-by location of another merchant which possesses the desired good will be provided instead, and the consumer still proceeds to make payment at the merchant, but will need to obtain the desired good from the other merchant, either by hand, or by arranging to have the desired good delivered to the consumer.

The following modes, given by way of example only, are described in order to provide a more precise understanding of the subject matter of a preferred embodiment or embodiments. In the figures, incorporated to illustrate features of an example embodiment, like reference numerals are used to identify like parts throughout the figures.

Particular embodiments of the present invention can be realised using a processing system, an example of which is shown inFIG.1. In particular, theprocessing system100 generally includes at least oneprocessor102, or processing unit or plurality of processors,memory104, at least oneinput device106 and at least oneoutput device108, coupled together via a bus or group ofbuses110. In certain embodiments,input device106 andoutput device108 could be the same device. Aninterface112 also can be provided for coupling theprocessing system100 to one or more peripheral devices, forexample interface112 could be a PCI card or PC card. At least onestorage device114 which houses at least onedatabase116 can also be provided. Thememory104 can be any form of memory device, for example, volatile or non-volatile memory, solid state storage devices, magnetic devices, etc. Theprocessor102 could include more than one distinct processing device, for example to handle different functions within theprocessing system100. Theprocessor102 also includes anavailability engine103 which is configured to determine stock levels of specific goods at respective merchants. Theavailability engine103 can attend to requests of inventory levels at various merchants and provide requisite information on respective inventory levels.

Input device106 receivesinput data118 and can include, for example, a keyboard, a pointer device such as a pen-like device or a mouse, audio receiving device for voice controlled activation such as a microphone, data receiver or antenna such as a modem or wireless data adaptor, data acquisition card, etc.Input data118 could come from different sources, for example keyboard instructions in conjunction with data received via a network.Output device108 produces or generatesoutput data120 and can include, for example, a display device or monitor in whichcase output data120 is visual, a printer in whichcase output data120 is printed, a port for example a USB port, a peripheral component adaptor, a data transmitter or antenna such as a modem or wireless network adaptor, etc.Output data120 could be distinct and derived from different output devices, for example a visual display on a monitor in conjunction with data transmitted to a network. A user could view data output, or an interpretation of the data output, on, for example, a monitor or using a printer. Thestorage device114 can be any form of data or information storage means, for example, volatile or non-volatile memory, solid state storage devices, magnetic devices, etc.

In use, theprocessing system100 is adapted to allow data or information to be stored in and/or retrieved from, via wired or wireless communication means, the at least onedatabase116 and/or thememory104. Theinterface112 may allow wired and/or wireless communication between theprocessing unit102 and peripheral components that may serve a specialised purpose. Theprocessor102 receives instructions asinput data118 viainput device106 and can display processed results or other output to a user by utilisingoutput device108. More than oneinput device106 and/oroutput device108 can be provided. It should be appreciated that theprocessing system100 may be any form of terminal, server, specialised hardware, or the like. Theinterface112 generally enables results of theavailability engine103 to be transmitted to a merchant server(s) and to also receive requests for use of theavailability engine103.

Theprocessing device100 may be a part of anetworked communications system200, as shown inFIG.2.Processing device100 could connect to network202, for example the Internet or a WAN.Input data118 andoutput data120 could be communicated to other devices vianetwork202. Other terminals, for example,thin client204, further processingsystems206 and208,notebook computer210,mainframe computer212,PDA214, pen-basedcomputer216,server218, etc., can be connected tonetwork202. A large variety of other types of terminals or configurations could be utilised. The transfer of information and/or data overnetwork202 can be achieved using wired communications means220 or wireless communications means222.Server218 can facilitate the transfer of data betweennetwork202 and one ormore databases224.Server218 and one ormore databases224 provide an example of an information source.

Other networks may communicate withnetwork202. For example,telecommunications network230 could facilitate the transfer of data betweennetwork202 and mobile orcellular telephone232 or a PDA-type device234, by utilising wireless communication means236 and receiving/transmittingstation238.Satellite communications network240 could communicate withsatellite signal receiver242 which receives data signals fromsatellite244 which in turn is in remote communication withsatellite signal transmitter246. Terminals, for example further processingsystem248,notebook computer250 orsatellite telephone252, can thereby communicate withnetwork202. Alocal network260, which for example may be a private network, LAN, etc., may also be connected tonetwork202. For example,network202 could be connected withEthernet262 which connectsterminals264,server266 which controls the transfer of data to and/or fromdatabase268, andprinter270. Various other types of networks could be utilised.

Theprocessing device100 is adapted to communicate with other terminals, for example further processingsystems206,208, by sending and receiving data,118,120, to and from thenetwork202, thereby facilitating possible communication with other components of thenetworked communications system200.

Thus, for example, thenetworks202,230,240 may form part of, or be connected to, the Internet, in which case, theterminals206,212,218, for example, may be web servers, Internet terminals or the like. Thenetworks202,230,240,260 may be or form part of other communication networks, such as LAN, WAN, Ethernet, token ring, FDDI ring, star, etc., networks, or mobile telephone networks, such as GSM, CDMA or 3G, etc., networks, and may be wholly or partially wired, including for example optical fibre, or wireless networks, depending on a particular implementation.

Referring toFIG.3, there is shown anexample system300 for managing inventory.

In particular, thesystem300 includes a server processing system310 (similar with the processing system100) in communication with a plurality ofmerchant devices320 via one ormore networks340. Theserver processing system310 includes or has access to adata store330. Eachmerchant device320 is associated with amerchant325. The plurality ofmerchant devices320 includes afirst merchant device320A associated with afirst merchant325A and asecond merchant device320B associated with asecond merchant325B. Whilst inFIG.3 the plurality ofmerchants325 is shown as twomerchants325A,325B and the plurality ofmerchant devices320 is shown as twomerchant devices320A,320B, it will be appreciated that the system can include more than twomerchants325 and more than twomerchant devices320.

Operation of thesystem300 will now be described with reference toFIG.4 which shows a flowchart representing amethod400 performed by theserver processing system310 for managing inventory.

In particular, atstep410 themethod400 includes theserver processing system310, particularly an availability engine of thesystem310, receiving, from the plurality ofmerchant devices320, inventory data and a plurality of merchant locations which are stored in adata store330.

Atstep420, themethod400 includes theserver processing system310 receiving, via an interface of thesystem310, from thefirst merchant device320A, data indicative of a requested good that is not stocked by thefirst merchant325A.

Atstep430, themethod400 includes theserver processing system310, particularly the availability engine of thesystem310, determining that the requested good is stocked by asecond merchant325B using the inventory data of one ormore merchants325 that are located within a proximity of the location of thefirst merchant325A.

Atstep440, themethod400 includes theserver processing system310 transferring, to thesecond merchant device320B, a request to facilitate provision of the requested good to a customer of thefirst merchant325A.

It will be appreciated that the above described arrangement provides a number of benefits over traditional approaches. Advantageously, the describedmethod400 andsystem300 enable a merchant to still be able to facilitate a sale of one or more goods which are not stocked by arranging for the provision of the requested inventory item by another merchant.

Referring toFIG.5 there is shown a schematic diagram of an example of amerchant device320. In particular, themerchant device320 may be a handheld computer device such as a smart phone or a PDA such as one manufactured by Apple™, LG™, HTC™, Research In Motion™, or Motorola™. Themerchant device320 may include a mobile computer such as a tablet computer. As shown, themerchant device320 includes adisplay502,non-volatile memory503, random access memory (“RAM”)504, one ormore processing components501, atransceiver component505 that includes one or more transceivers anduser controls507, alocation receiver510 and acamera module512 coupled together in electronic communication via abus506.

Although the components depicted inFIG.5 represent physical components,FIG.5 is not intended to be a hardware diagram; thus many of the components depicted inFIG.5 may be realized by common constructs or distributed among additional physical components. Moreover, it is certainly contemplated that other existing and yet-to-be developed physical components and architectures may be utilized to implement the functional components described with reference toFIG.5.

Thedisplay502 generally operates to provide a presentation of content to a user, and may be realized by any of a variety of displays (e.g., CRT, LCD, HDMI, micro-projector and OLED displays). And in general, the non-volatile memory303 functions to store (e.g., persistently store) data and executable code including code that is associated with the functional components of a browser component and applications, and in one example, an inventorysharing network application508 executing on themerchant device320. In some embodiments, for example, thenon-volatile memory503 includes bootloader code, modem software, operating system code, file system code, and code to facilitate the implementation of one or more portions of the inventorysharing network application508 as well as other components well known to those of ordinary skill in the art that are not depicted for simplicity.

In many implementations, thenon-volatile memory503 is realized by flash memory (e.g., NAND or ONENAND memory), but it is certainly contemplated that other memory types may be utilized as well. Although it may be possible to execute the code from thenon-volatile memory503, the executable code in thenon-volatile memory503 is typically loaded intoRAM504 and executed by one or more of theprocessing components501.

The one ormore processing components501 in connection withRAM504 generally operate to execute the instructions stored innon-volatile memory503 to effectuate the functional components. As one of ordinarily skill in the art will appreciate, the one ormore processing components501 may include a video processor, modem processor, DSP, graphics processing unit (GPU), and other processing components.

Thetransceiver component505 includes one or more transceiver chains, which may be used for communicating with external devices via wireless networks. Each of the one or more transceiver chains may represent a transceiver associated with a particular communication scheme. For example, each transceiver may correspond to protocols that are specific to local area networks, cellular networks (e.g., a CDMA network, a GPRS network, a UMTS networks), and other types of communication networks.

Referring toFIG.6 there is shown a flowchart representing anexample method600 of amerchant325 supplying data, including inventory data, to theserver processing system310 for storage in thedata store330.

In particular,step605 themethod600 includes themerchant325 operating themerchant device320 to transfer registration details to theserver processing system310. In particular, the registration details can include the location of the merchant's premises. In one form, themerchant device320 is configured by theapplication508 to request a current location using thelocation receiver510 which is presented to themerchant325 via thedisplay502 requesting confirmation via aninput device507. In the event that the merchant is located at a different location to the business premises of themerchant325, themerchant325 can interact with theapplication508 via theinput device507 to provide a different location of themerchant325. Once the correct details are supplied, themerchant325 can interact with theapplication508 requesting transfer of the registration details to theserver processing system310 for storage in thedata store330. Thedata store330 is generally provided in the form of a central database. In response to receiving the registration details, theserver processing system310 can be configured to create a new entry in thecentral database330.

Atstep610, themethod600 includes themerchant325 selecting, using themerchant device320 executing theapplication508, one or more preferences including a proximity of an inventory network for themerchant325. In particular, the proximity can be defined as a distance such as a radius from the merchant's location, wherein one or moreother merchants325 which are located within the proximity are part of the merchant inventory network that can be used to facilitate provision of a requested good which themerchant325 may not currently stock for one reason or another. In one form, theapplication508 can suggest a default proximity, such as 1 kilometer. In the event the merchant is happy with the default proximity, theserver processing system310 stores in the merchant's entry in the central database the default proximity.

However, in some instances, the default proximity may not be appropriate. For example, the default proximity may not encompass a suitable number of other merchants which are part of the inventory system managed by theserver processing system310. In particular, theserver processing system310 may conduct a search of thecentral database330 to determine any merchant entries which are located within the default proximity and transfer data plotting the other identified merchants on a map interface for themerchant325 to review. The map interface map present a circle representing the inventory network proximity centred about the merchant's location with other merchants which are located within the proximity which are also registered with the inventory system being highlighted by an icon or marker within the circle on the map. In the event that themerchant325 would like to adjust the proximity, themerchant325 can interact with the map interface via the one ormore user controls507 such as a touch screen to graphically adjust the size of the proximity.

For example, themerchant325 may select a portion of the circle and drag the circle inwards toward the merchant location to contract the radial distance defining the proximity or drag the circle outwards away from the merchant location to expand the radial distance defining the proximity. Upon the proximity being adjusted by the user, the adjusted proximity is transferred back to theserver processing system310 to determine the one or moreother merchants325 which are located in the adjusted proximity which is transferred back to themerchant device310 for presentation in the map interface to themerchant325. The proximity can be adjusted a number of times until the merchant is satisfied with the defined proximity. It will be appreciated that other preferences may also be defined by the merchant.

Atstep615, the preference data including the defined proximity is transferred to theserver processing system310 for storage in the merchant's entry in thecentral database330.

Atstep620, themethod600 includes themerchant325 scanning a barcode of a good using thecamera module512 of themerchant device320. In particular, theapplication508 may present an image capturing interface to capture an image of the barcode of the good. Themerchant325 can select a button of the image capturing interface to capture an image of the barcode. Alternatively, theapplication508 can continually analyse an image/video feed provided by thecamera module512 to determine if the barcode of the good is orientated appropriately for the barcode to be analysed correctly, wherein upon the detection of the correct orientation of the barcode, theapplication508 automatically captures an image of the barcode using thecamera module512. Theapplication508 then automatically performs image analysis or character recognition to determine an identifier, such as a Unique Product Code (UPC), EAN/UCC-13 code, or the like which is represented by the barcode of the good.

In the event that the barcode is not captured correctly, themerchant325 may be requested to try and capture the barcode again using thecamera module512 of themerchant device320. However, in the event that the identifier is determined by the analysis performed by themerchant device320, themerchant device320 can transfer a request to theserver processing system310 operating a barcode lookup service or to another processing system operating a barcode lookup service to determine details of the scanned good. Details of the scanned good can then be communicated back to themerchant device320 for formatting and presentation to themerchant325 within an interface of theapplication508. Themerchant325 can then check the returned details to confirm that the details of the good are correct. If the details are correct themerchant325 can provide feedback to continue to step625. If the details are incorrect, themerchant325 can interact with theapplication508 to correct the details using theinput device507 and then proceed to step625.

Atstep625, themethod600 includes themerchant325 providing price data in relation to the scanned good. In particular, the merchant is requested to provide a merchant selling price which is the cost that the merchant is willing to sell the good to another merchant, the cost price of the good and the retail price.

Atstep630, themethod600 includes the merchant inputting, using theinput device507 of themerchant device320, an inventory amount for the good. For example, instead of scanning every instance of a good, themerchant325 can input an inventory amount indicative of the number of instances of the good that is in stock.

Atstep635, themethod600 includes themerchant device320 transferring inventory data indicative of the scanned good, the inventory amount and the price data, to theserver processing system310 for storage in thecentral database310, and also for processing at the availability engine.

Atstep640, themethod600 includes themerchant325 indicating whether one or more further goods need to be added to the inventory data for the merchant. In the event that one or more further goods need to be scanned, themethod600 proceeds back to step620 to repeatsteps620 to640 until all goods have been scanned and stored in thecentral database330 by theserver processing system310. In the event that no further goods need to be scanned, themethod600 ends.

Referring toFIG.7 there is shown a flowchart representing an example method700 of themerchant325A requesting provision of a requested good by anothermerchant325B.

In particular, atstep705, the method700 includes a customer visiting the premises of amerchant325A. Atstep710, the merchant inputs into the merchant device a good requested by the customer.

Atstep715, the method700 includes determining, using theapplication508, whether themerchant325 has the requested good in stock. In one form, themerchant device325 maintains a local copy inmemory503 of the merchant's inventory data such themerchant device325 can conduct a search for the request good via the local copy of the merchant's inventory data. However, in other instances, data indicative of the good (i.e. a product name) is transferred to theserver processing system310 to search the inventory data of the merchant via the availability engine. Results of either search are presented via thedisplay502 of themerchant device320.

In the event that themerchant325 stocks the requested good, the method700 proceeds to step720 to accept payment from the customer and to provide the good to the customer or to deliver the good to a customer defined location.

In the event of an unsuccessful determination to step715, the method700 proceeds to step725 which includes themerchant device320 transferring an inventory network search request to theserver processing system310. In particular, in response to a negative determination atstep715, the method700 may automatically proceed to step725. However, in other arrangements, themerchant325 may be requested to confirm via the interface of theapplication508 whether an inventory network search request is to be performed in relation to the requested good.

Atstep730, the method700 includes theserver processing system310 determining whether one or more other merchants within the defined proximity stock the request good. In particular, theserver processing system310 determines the one or more other merchants which are located within the proximity. The one or more other merchants which are part of the merchant's inventory network can already be stored in thecentral database330 for themerchant325, and thus the server processing system retrieves from thecentral database330 data indicative of the one or more other merchants. Once the one or more other merchants of the merchant's inventory network are determined, theserver processing system310 searches the inventory data for the one or more other merchants to determine if any of the other merchants stock the requested good.

Atstep735, the method700 includes theserver processing system310 transferring search result data to themerchant device320. The search result data may be indicative of any other merchant which stocks the requested good based on the inventory data stored in thecentral database330, the inventory amount of the request good stocked by each other merchant, the merchant selling price of the requested good, and the distance between each other merchant and the merchant's location.

Atstep740, the method700 includes themerchant device320 displaying the search result data. In one form, at least some of the search results are presented within a map interface. In particular, markers may be presented within a map showing the merchant's inventory network proximity and a marker representing each other merchant located within the proximity which stocks the requested good. Each marker on the interface can include the name of the other merchant, the merchant sale price, the inventory amount of the requested good, and a distance from the merchant's premises. Alternatively, only a portion of this data is presented by each marker until highlighted. For example, the preference data for the merchant may define that the merchant selling price is to be presented by each marker on the map. Upon selection of one of the markers from the map interface, the other information provided by the server processing system for the selected other merchant is presented to the merchant. Additionally or alternatively, the interface presenting the map interface can also include a tabular list with the other merchants which are sorted according to one or more criteria defined within preference settings of the merchant. For example, the merchant may want the other merchants sorted according to merchant selling price. Alternatively, the merchant may want the other merchants sorted according to distance from the merchant. Alternatively, the merchant may define a rule which sorts the other merchants according to a weighted combination of merchant selling price and distance. Alternatively, the merchant may define a rule which sorts the other merchants according to delivery costs of each merchant.

Atstep745, the method700 includes themerchant325 selecting one of the other merchants presented within the search results interface to provide the requested good to the customer. In particular, upon selecting one of the markers from the map interface, a button may be presented to the merchant allowing the merchant to send a request to the selected merchant to facilitate the provision of the requested good to the customer. Additionally, themerchant325 can interact with the application interface to indicate whether the requested good is to be collected by the customer from the premises of the selected other merchant, delivered by the selected other merchant to the customer at the merchant's premises, or delivered to a location specified by the customer.

Atstep750, the method700 includes themerchant device320 transferring the selected other merchant to theserver processing system310. Additionally, the request can be indicative of whether the requested good is to be collected by the customer from the premises of the selected other merchant, delivered by the selected other merchant to the customer at the merchant's premises, or delivered to a location specified by the customer.

Atstep755, the method700 includes theserver processing system310 transferring a request to the other merchant device of the selected other merchant and records in the data store a merchant to merchant sale. In particular, the merchant is charged according to the merchant price defined by the selected other merchant for the requested good. The request is indicative of the requested good and whether the requested good is to be collected by the customer from the premises of the selected other merchant, delivered by the selected other merchant to the customer at the merchant's premises, or delivered to a location specified by the customer.

Atstep760, the method700 includes themerchant325 accepting payment from the customer. The amount that is charged may be the other merchant's retail price which is retrieved from thecentral database330 and transferred to themerchant device320 for arranging payment. However, it will be appreciated that a default profit margin may be charged by the merchant.

Atstep765, the method700 includes the selected other merchant facilitating the provision of the requested good to the customer. For example, the requested good may be collected by the customer from the premises of the selected other merchant, delivered by the selected other merchant to the customer at the merchant's premises, or delivered to a location specified by the customer.

It will be appreciated that is somecircumstances steps760 and765 can be swapped as payment to the merchant may only be performed upon receiving the requested good.

It will be appreciated that the customer may require a particular amount of the good. As such, the search request may only return one or more other merchants which have the requested amount in stock. Alternatively, themerchant325 can select multiple other merchants to provide portions of the requested amount of the requested good.

Referring toFIG.8 there is shown a flowchart representing amethod800 of aserver processing system310 performing bulk settlement of merchant to merchant sales over a predefined period of time. In a preferred embodiment, the predefined period of time is a day.

In particular, atstep810, themethod800 includes theserver processing system310 determining, after the predefined period of time and for each merchant, an amount payable or receivable from each other merchant within proximity based on merchant to merchant sales. For example, a merchant may have purchased $100 of goods from a first merchant, sold $150 of goods to the first merchant, purchased $500 of goods from a second merchant, sold $200 of goods to the second merchant, purchased $200 of goods from a third merchant, and sold $50 of goods to the third merchant. It will be appreciated that the amounts purchased and sold preferably include multiple transactions, wherein only a bulk settlement for the plurality of transactions can be performed for efficiency purposes. The server processing system determines an amount payable or receivable for the merchant in relation to the first, second and third merchants. In this particular example, the amounts are $50 receivable from the first merchant (i.e. $150−100), $300 payable to the second merchant (i.e. $200−$500), and $150 receivable from the third merchant ($200−$50).

At step820, themethod800 includes theserver processing system310 determining a net amount payable or receivable for the merchant based on the amounts payable or receivable for the other merchants. Continuing with the above example, the merchant is required to pay $100 ($50−$300+$150=−$100) in total to the other merchants.

At step820, themethod800 includes theserver processing system310 facilitating transfer of funds based on the net amount determined for the merchant. Continuing with the example, theserver processing system310 can facilitate debiting the merchant's account for $100, such as a credit card or the like, with the net amount. The amount charged may also include a fee charged by the administrator of theserver processing system310. It will be appreciated that this process is advantageous as only a single administrative fee is charged in relation to the net amount payable or receivable rather than an administrative fee being charged for processing each merchant to merchant sale.

Theserver processing system310 can be configured to receive, from at least some of the merchant devices, sales data. In particular, the sales data includes merchant to merchant sales. In addition, when a merchant sells a good that is in stock, the merchant can interact with theapplication508 executing on themerchant device320 to indicate to theserver processing system310 that a sale has occurred. In response to receiving sales data, theserver processing system310 updates the inventory data of the relevant merchants according to the sales data.

The sales data that is received by theserver processing system310 can be stored in thedata store330 for at least some of the merchants. Theserver processing system310 can be configured to receive, from one of themerchant devices320, a request for anonymous sales data for the one or more merchants located within the proximity of the respective merchant location. In response, theserver processing system310 generates, using the sales data stored in the data store and the proximity of the requesting merchant, anonymous sales data. Theserver processing system310 then transfers the anonymous sales data to therespective merchant device320 of the requestingmerchant325.

It will be appreciated that over time as a merchant receives new inventory, steps620 to640 can be repeatedly executed in order to add new products to the inventory data of the merchant or t update inventory amounts for existing products in the inventory data.

It will be appreciated that themerchants325 are independent merchants.

Throughout this specification and claims which follow, unless the context requires otherwise, the word “comprise”, and variations such as “comprises” or “comprising”, will be understood to imply the inclusion of a stated integer or group of integers or steps but not the exclusion of any other integer or group of integers.

Persons skilled in the art will appreciate that numerous variations and modifications will become apparent. All such variations and modifications which become apparent to persons skilled in the art, should be considered to fall within the spirit and scope that the invention broadly appearing before described.

Claims (15)

The invention claimed is:

1. A method for identifying inventory from distinct merchants from a first merchant device, the method including:

sending, from the first merchant device to a server system, inventory data and a first merchant location to be stored in a data store;

sending, from the first merchant device during an in-person sale transaction with a customer at the first merchant location, data indicative of a requested good that is not immediately deliverable at the first merchant location;

receiving, from the server system, data for plotting a map interface at the first merchant device;

rendering a graphical map interface on the first merchant device based on the received data, the interface showing one or more merchants locations relative to the first merchant location, wherein the one or more merchant locations have the requested good immediately deliverable and are located within a proximity of the first merchant location;

detecting a user selection via the graphical map interface of a second merchant location;

sending, from the first merchant device, the selection of the second merchant location to facilitate provisioning of the requested good;

sending, to a second merchant device, a request to facilitate provision of the requested good to the customer; and

transferring funds from the first merchant to the second merchant for facilitating provisioning of the requested good, wherein the requested good are sold to the customer at a retail price set by the second merchant.

2. The method ofclaim 1, further comprising:

receiving a merchant sale price for the requested good at the second merchant location, wherein the customer of the first merchant location is charged the merchant sale price of the second merchant location for the facilitating the provision of the requested good to the customer.

3. The method ofclaim 1, further comprising:

sending price data for goods at the first merchant location to the server system; and

sending updated inventory data for the first merchant location to the server system.

4. The method ofclaim 1, further comprising:

sending sales data for sales of goods to the server system; and

sending, to the server system, a request for anonymous sales data for the one or more merchants located within a proximity of the first merchant location;

generating, using the sales data stored in the data store and the proximity of the requesting merchant, anonymous sales data; and

receiving, from the server system, the anonymous sales data associated the one or more merchants within the proximity of the first merchant location.

5. The method ofclaim 1, wherein the first merchant location and the second merchant location are associated with different merchants.

6. A first merchant device comprising:

a memory device;

a communication transceiver; and

a processor coupled to the memory device and the communication transceiver, the processor configured to

send, from the first merchant device to a server system, inventory data and a first merchant location to be stored in a data store;

send, from the first merchant device during an in-person sale transaction with a customer at the first merchant location, data indicative of a requested good that is not immediately deliverable at the first merchant location;

receive, from the server system, data for plotting a map interface at the first merchant device;

render a graphical map interface on the first merchant device based on the received data, the interface showing one or more merchants locations relative to the first merchant location, wherein the one or more merchant locations have the requested good immediately deliverable and are located within a proximity of the first merchant location;

detect a user selection via the graphical map interface of a second merchant location;

send, from the first merchant device, the selection of the second merchant location to facilitate provisioning of the requested good;

send, to a second merchant device, a request to facilitate provision of the requested good to the customer; and

transfer funds from the first merchant to the second merchant for facilitating provisioning of the requested good, wherein the requested good are sold to the customer at a retail price set by the second merchant.

7. The first merchant device ofclaim 6, wherein the processor is further configured to:

receive a merchant sale price for the requested good at the second merchant location, wherein the customer of the first merchant location is charged the merchant sale price of the second merchant location for the facilitating the provision of the requested good to the customer.

8. The first merchant device ofclaim 6, wherein the processor is further configured to:

send price data for goods at the first merchant location to the server system; and

send updated inventory data for the first merchant location to the server system.

9. The first merchant device ofclaim 6, wherein the processor is further configured to:

send sales data for sales of goods to the server system; and

send, to the server system, a request for anonymous sales data for the one or more merchants located within a proximity of the first merchant location;

generate, using the sales data stored in the data store and the proximity of the requesting merchant, anonymous sales data; and

receive, from the server system, the anonymous sales data associated the one or more merchants within the proximity of the first merchant location.

10. The first merchant device ofclaim 6, wherein the first merchant location and the second merchant location are associated with different merchants.

11. A non-transitory computer storage medium including executable instructions which, when executed by one or more processors, causes the processor to:

send, from a first merchant device to a server system, inventory data and a first merchant location to be stored in a data store;

send, from the first merchant device during an in-person sale transaction with a customer at the first merchant location, data indicative of a requested good that is not immediately deliverable at the first merchant location;

receive, from the server system, data for plotting a map interface at the first merchant device;

render a graphical map interface on the first merchant device based on the received data, the interface showing one or more merchants locations relative to the first merchant location, wherein the one or more merchant locations have the requested good immediately deliverable and are located within a proximity of the first merchant location;

detecting a user selection via the graphical map interface of a second merchant location;

send, from the first merchant device, the selection of the second merchant location to facilitate provisioning of the requested good;

send, to a second merchant device, a request to facilitate provision of the requested good to the customer; and

transfer funds from the first merchant to the second merchant for facilitating provisioning of the requested good, wherein the requested good are sold to the customer at a retail price set by the second merchant.

12. The storage medium ofclaim 11, further comprising executable instructions to cause the processor to:

receiving a merchant sale price for the requested good at the second merchant location, wherein the customer of the first merchant location is charged the merchant sale price of the second merchant location for the facilitating the provision of the requested good to the customer.

13. The storage medium ofclaim 11, further comprising instructions to cause the processor to:

send price data for goods at the first merchant location to the server system; and

send updated inventory data for the first merchant location to the server system.

14. The storage medium ofclaim 11, further comprising executable instructions to cause the processor to:

send sales data for sales of goods to the server system; and

send, to the server system, a request for anonymous sales data for the one or more merchants located within a proximity of the first merchant location;

generate, using the sales data stored in the data store and the proximity of the requesting merchant, anonymous sales data; and

receive, from the server system, the anonymous sales data associated the one or more merchants within the proximity of the first merchant location.

15. The storage medium ofclaim 11, wherein the first merchant location and the second merchant location are associated with different merchants.

Images