WO2018004445A1

WO2018004445A1 - Method and system for purchasing a product

Info

Publication number: WO2018004445A1
Application number: PCT/SE2017/050733
Authority: WO
Inventors: Bror Anders MÅNSSON; Ann-Cathrine LISKA; Mats Forsberg; Fredrik LEMMEL
Original assignee: Urb-It & Associates Ab
Priority date: 2016-07-01
Filing date: 2017-06-30
Publication date: 2018-01-04
Also published as: SE1650966A1; WO2018004445A8

Abstract

Method for performing a purchase of a physical product from a physical point of sale (120) (POS) offering the product for direct on-site purchase, which method comprises the steps, performed by a central server (110), of a) receiving information regarding a purchasing user (131) and a delivery location; b) receiving product inventory information several POS; c) receiving location information for several mobile delivery agents (151); d) determining an optimal product delivery route, involving a selected delivery agent, a selected POS and the delivery location, and calculating an expected delivery time; e) in case the expected delivery time is not longer than a predetermined maximum delivery time, presenting to the user a purchasing option; f) if the user accepts the option, sending reservation information to the selected POS and delivery information to the selected delivery agent.

Description

Method and system for purchasinfi a product

The present invention relates to a method and a system for purchasing a product.

The rapid development of computer technology and electronic consumer devices during recent years have provided many new ways for sellers and buyers of products and services to interact and to find each other. For instance, online marketing and purchases have increased drastically, now accounting for a significant share of the total market.

At the same time, the said technical development has provided new and more numerous possibilities to take advantage of geographical proximity between seller and buyer, and also allowing more elaborate patterns of decentralization of commerce.

The present invention solves problems in this field, and in particular within the context of, and with respect to, a technical platform for allowing such decentralized commerce using electronic devices for connecting buyers and sellers, using delivery agents for physically delivering products from sellers to buyers, such as within a single, geographically local neighbourhood, such as within a single city or even a particular downtown area.

Hence, problems arise when there are several parallel sales channels for the same stocked products, in particular when one of a set of available sales channels is via delivery by delivery agents of the said type. Such problems, among other things, relate to electronic inventory keeping under dynamic conditions, involving several physical shops and buyers acting in parallel and over time scales that may differ due to geographical locations and distances, as well as availability, of physical shops, products, buyers and delivery agents.

Problems also arise in the context of electronic product order placement under such dynamic conditions. Users want a convenient and simple purchasing process while still being reasonably confident that delivery of an ordered product will in fact take place, which many times may be difficult to offer under uncertainty. The present invention solves the above described problems.

Hence, the invention relates to a method for performing a purchase of a physical product from at least one physical point of sale offering the product for direct on-site purchase, which method comprises the steps a) a central server electronically being provided information regarding a purchasing user, in particular a desired delivery location; b) the central server electronically being provided inventory information regarding present updated physical availability of the product in question from a plurality of physical points of sale; c) the central server electronically being provided location information regarding present respective geographic locations for a plurality of available mobile delivery agents; d) the central server determining an optimal physical product delivery route, involving at least one selected delivery agent, at least a selected one of said points of sale, as well as said delivery location, based upon the said inventory and location information, and calculating an expected delivery time for the optimal route to the de-livery location; e) in case the said expected delivery time is not longer than a predetermined maxi-mum delivery time, the central server causing the user to be presented with an op-tion to purchase the product without having to specify a desired delivery location or a desired delivery time; f) if the user accepts the said option, the central server electronically sending reserva-tion information to the said selected point of sale, as well as delivery information to the said selected delivery agent.

The invention also relates to a system.

In the following, the invention will be described in detail, with reference to exemplifying embodiments of the invention and to the enclosed drawings, wherein:

Figure 1 is an overview of a system according to the present invention;

Figure 2 is a flow chart illustrating a method according to a first aspect of the invention;

Figure 3 is a flow chart illustrating a method according to a second aspect of the invention; and Figures 4a-4d are respective simplified examples of respective states of interactive graphical user interfaces in different stages of a method according to the invention.

Figure 1 illustrates a system 100 according to the invention. A central server 110, which may be a standalone or distributed server, as is conventional as such, is in communication with a plurality of physical points of sale (POS) 122 offering at least one, preferably physical, product for direct on-site purchase. Preferably, and as shown in figure 1, each POS 122, or at least several of said POS 122, are in communication with the central server 110 indirectly, via an ERP (Enterprise Resource Planning) system 122, or similar, which in turn is a part of an internal computerized product management system of a particular retailer 120. In figure 1, the preferred configuration, for at least one, preferably several, of such retailers 120, is shown in which the product management system of the retailer 120 in question further comprises a respective PIM (Product Inventory Management) system 123 as well as an E- com (Electronic Commerce) system 124, or similar.

The communication link between the central sever 110 and the ERP system 121 is used for sending inventory status updates, making product orders and reservations and so forth. The ERP system 121 is responsible for keeping track of product inventory information locally, within the retailer 120 in question. The communication link between the central server 110 and the E-com system 124 is used to initiate and perform an actual product purchasing transaction. The E-com system 124 is responsible for product purchase transactions, preferably including electronic payment.

As shown in figure 1, there are preferably a plurality of retailers 120, several of which have a respective ERP 121, PIM 123 and E-com 124 system, and several of which have a plurality of POS 122. Preferably, a plurality of retailers 120 have ERP 121, PIM 123 and E-com 124 systems as well as a respective plurality of POS 122.

The central server 110 is in communication with, or comprises, a database 111 for storing central product inventory information and other data necessary to perform a method according to the present invention, in the following, it is assumed that data stored or handled in the central server 110 may or may not be allocated to the database 111, why the database 111 is not referred to extensively as such.

The central server 110 is also in communication with a billing agent 160, which may be a bank or other financial institution, using which the central server 110 can order the billing of ordered products. This is conventional as such, and will not be described in further detail herein.

Furthermore, the central server 110 is in communication with a plurality of purchasing users 131, each with a respective mobile electronic device 130. Preferably, such a mobile device 130 is a general-purpose computer unit with a screen display and the possibility to execute computer software programs on or from the computer unit in question. For instance, the device 130 is a conventional smartphone which runs an operating system and a locally installed software application, or uses a web service, to access the corresponding functional- ity, to perform the steps described herein below, in particular in relation to the central server 110. Such electronic devices 130 are themselves well-known in the art, and are not described in further detail herein. Each user 131 device 130 reaches the central server 110 via a suitable electronic interface 112, such as a user API (Application Programming Interface) and/or a GUI (Graphical User Interface), provided by the central server 110 and via which the device 130 and potentially also the user 131 can interact with central server 110 functionality. Preferably, the operator of the central server 110 provides custom software of the said type, using which the device 130 can engage in automatic communication via said interface 112. The central server 110 is also in communication with an operator 141, running a computer 140 of suitable type, for instance running or accessing configuration software functionality provided by the central server 110 and performing configurations over a certain operator interface 114, such as an API and/or a GUI, so as to allow the operator 141 to perform manual configurations of the central server 110 functionality. Moreover, the central server 110 is in communication with a plurality of delivery agents 151, each with an associated mobile electronic device 150, which may be of a type similar to devices 130 and using a particular software functionality arranged to allow automatic communication with the central server 110 over an agent interface 113, such as an API and/or a GUI. The interface 113 may in general be structurally similar to the interface 112.

All communications between the central server 110 and the various entities 121, 124, 130, 140, 150 preferably take place over the internet, in particular in the case of mobile devices 130, 150 over wireless internet such as WiFi, GPRS, 3G, LTE, 5G or similar. It is realized that the user's 131 devices 130 may, in some embodiments, equally advantageously be a conventional stationary or mobile computer, which may then be connected to the internet via a suitable wire. The devices 150 are, however, preferably connected to the central server 110 via a respective wireless connection. The present invention provides the most benefits when being operated using many interacting parties. Hence, it is preferred that there are at least 10, preferably at least 100, more preferably at least 1000, users 131, each with his or her own respective device 130, registered with the central server 110 for use of the system 100. Correspondingly, it is preferred that there are at least 10, preferably at least 100, more preferably at least 1000, delivery agents 151, each with its own respective device 150, registered with the central server 110 for use of the system 100. Preferably, there are at least 10 POS 122, preferably at least 100 POS 122, preferably distributed across a plurality of retailers 120, registered with the central server 110 for participation in the system 100 operation. Advantageously, these high numbers of actors may be active in relation to the system 100 at the same time. Further prefer- ably, there are products of at least 10, preferably at least 100, different product types offered for sale via the system 100.

It is an important aspect of the present invention that the POS 122 are physical points of sale. In other words, at least a plurality of the POS 122 exist as a respective product outlet at a respective physical location, which location is not the same for all connected POS 122. At least a plurality of the POS 122 offer at least one of the said products, offered for sale and delivery via the system 100 and the central server 110, for sale at the physical location in question. In other words, anybody could typically walk into the POS and buy the product in question off the shelf. As such, these POS 122 will also hold a number of such products available, as a form of local product inventory.

The products being available at the POS 122 in this manner are hence not, or at least not exclusively, available from a central warehouse or similar, but are actually physically present in the POS 122 itself, for pickup by a delivery agent 151 or direct purchase by a customer physically entering the POS 122 making such an immediate purchase.

At least a plurality of the retailers 120, and preferably also individual POS 122, are further connected to or themselves operating an electronic outlet, in the sense that a user can enter a virtual store, such as via the internet, offering a product range overlapping with the range of products offered via the system 100 and the central server 110, purchase such products online and have them delivered using conventional surface mail or the corresponding delivery systems, not using the delivery agents 151 and preferably in way which is completely separated from the system 100 and the central server 110.

Such physical, immediate purchases, and preferably also such electronic outlet purchases, then use the same inventory of products as is used by the system 100 and the central server 110 and being offered to the users 131 for delivery by agents 151, so that a purchase using another sales channel than using the central server 110 and delivery agents 151 will affect the available stock of products that are in fact available for purchase via the central server 110 and delivery agents 151.

Hence, the products being purchased using a method according to the present invention are not only available via the purchasing channel offered by the said method, but are also available to potential purchasing parties using at least one other purchasing channel, operating in parallel to the channel offered by the present system 100 and the central server 110. The central server 110 as described herein is configured with a suitable computer software product so as to, in communication with the retailers 120, the users 131 and the agents 151, provide a high standard experience for a purchasing user 131 even in the uncertain environment caused by additional available, parallel purchasing channels of the said types that exploit the same inventory levels of said products.

It is understood that both the users 131 and the delivery agents 151 are physical, human being actors. The delivery agents 151 will typically be passive, in relation to the system 100, until instructed to perform a delivery. Such a delivery will be assigned to a particular agent 151 by the central server, when so is required, via interface 113 and a suitable user interface on the agent's 151 device 150, on the initiative of the central server 110. Preferably, such assignment is pushed to the device 150 of the agent 151 in question, by the central server 110. At this instance, the summoned agent 151 can typically accept or reject the delivery assignment, also using said user interface, such as an interactive GUI operable on a screen display of the respective device 150 in question. The device 150 will also preferably supply to the central server 110 continuously or intermittently updated information regarding the current position and trajectory of the respective agent 151, both before and during an ac- cepted assignment. All these functions are preferably achieved by a computer software product executed by or from the device 150 in question, which (as is the case with the corresponding software product executed by or from device 130) may be provided by the central server 110 operator. Each user 131 may browse product availability, place orders and manage delivery details using his or her device 130, using the interface 112 and for instance an interactive GUI operable on a screen display of the device 130 in question, functionality which is preferably performed by a respective piece of computer software of the above described type, executable by or from the device 130 in question. Ordered products are delivered, by at least one delivery agent 151, to a particular delivery location, as is described herein. This is achieved by the central server 110 building and maintaining updated aggregated product inventory information, based upon individual product or product type inventory information provided by individual ERP systems 121 and/or individual POS 122. This aggregated product inventory information allows the central server 110 to reliably offer, in the manner described below, product purchases and deliveries on the local scale, such as within a single city or downtown area. However, it also allows the presentation, via user interface 112 (which may comprise or expose a web site the offered user experience of which is similar to a conventional online web store), an aggregated view of products for sale from several different POS 122, and for delivery using delivery agents 151, where the product availability information is reliable even in case the products are not available from a centralized warehouse or similar, but are only available from POS 122 of the above described type. In particular, this is the case when using automatic offsetting of actual inventory levels as described below. It is noted that this is possible, using the present invention, also in the preferred case in which the same products are offered for ordering and delivery via at least one additional purchase channel, such as for delivery by conventional surface mail or for self-pickup.

Normally, offering these different types of purchasing channels in a way which is perceived as reliable by the user would put a great burden on each POS 122 or retailer 120. Using the present invention, an individual POS 122 or retailer 120 can sign up to the central server 110, so as to be provided with an electronically kept POS/retailer account therewith, and hence become part of a network offering such sales channels automatically, without the POS 122 or retailer 120 having to do more than minimal configurations or additions to existing local inventory systems, and with essentially no or only minimal manual handling of the purchasing procedure.

In particular, figure 2 is a flow chart illustrating a first aspect of a method according to the present invention for performing a purchase of a physical product from at least one physical point of sale offering the product for direct on-site purchase. As illustrated in figure 2, the method according to this first aspect comprises the following steps.

In a first step, the method is initiated.

In a subsequent step, the central server 110 is provided, electronically, with inventory information regarding present updated physical availability of at least one particular product, or product type, at (and preferably from) a plurality of respective physical POS 122. As described above, the availability in question is physical availability in at least one, preferably a plurality, of respective physical points of sale 122.

In a step which may be performed in any order in relation to the inventory information provision step, the central server 110 is provided, electronically, with location information regarding present respective geographic locations for a plurality of available mobile delivery agents 151. This information is preferably provided directly by the respective devices 150.

The inventory and location information provision may preferably be achieved automatically, between retailers 120 and/or POS 122; devices 150; and the central server 110. Given the inventory and location information, the central server 110 then determines an optimal physical product delivery route. Herein, such optimal delivery routes are of fundamental importance, and, as the expression is used herein, an "optimal delivery route" is a planned trajectory of one or more delivery agents picking up and delivering one or more physical products from one or more physical points of sale 122 and delivering the said prod- uct or products to a particular delivery location, which trajectory is an at least locally optimal trajectory under a set of predetermined boundary conditions and given a particular utility function using at least total delivery time, from the time of order, as a variable to be minimized. Such boundary conditions may be, for instance, that certain methods of transportation, such as non-public transport cars or taxis, are not to be used; that particular types of products (see below) should be delivered within a particular respective maximum time period; or that the total delivery time cannot exceed a particular maximum value. Numerous examples of this will be given below. Performing multiple pickups on a route and ending up on a delivery location is in general a NP (Non Complete polynomial) complete problem, similar to the travelling salesman problem. However, there are a few points that differ. Firstly, there is the inclusion restriction, that a final destination must be visited after visiting all intermediate destinations. Second ly, several options may exist for one intermediate destination, one of which has to be included in the resulting optimal route. This is a further specialization of that problem.

For a small number of pickup locations, exhaustive methods can be utilized. For more complex routes, a more elaborate algorithm has to be used. Examples of suitable methods are described in the articles "Algorithm for Route Planning with Multiple Intermediate Destina- tions", SICE Journal of Control, Measurement, and System Integration, Vol. 4 (2011) No. 5 P 353-360; "A personal tourism navigation system to support traveling multiple destinations with time restrictions", Advanced Information Networking and Applications, 2004, AINA 2004, 18th International Conference (Volume:2); and "A Personal Navigation System with Functions to Compose Tour Schedules Based on Multiple Conflicting Criteria", IPSJ Digital Courier 1:528-536 · January 2005.

These algorithms use different techniques and supporting algorithms, such as the "A*" search algorithm, Dijkstra's algorithm, RaslD-D, Genetic Algorithm with fitness value to candidate solutions based on preferences, to estimate and suggest best-effort routes and com- bined delivery times.

The present invention can also incorporate, into the calculation of optimal routes, additional cost factors such as per-pickup location delays, travel expense costs and so forth. Such costs may, for instance, be treated as parameters that need to fulfil predetermined boundary conditions or be converted into one common parameter dimension such as time or money before affecting the algorithm. In general, it is preferred that the optimal route is determined according to the following. First, an optimal travelling time between the origin (of at least one delivery agent 151), intermediate destination(s) and a final destination (delivery location) is determined. Then, the order of intermediate destinations, if several, is determined, with the aim of minimizing the total travelling time from the origin to the delivery location. Then, the final route from the origin to the delivery location via intermediate destination(s) is determined, using the results of the previous steps.

Thus, the optimal route determined by the central server 110 involves at least one selected delivery agent 151, at least a selected one of said POS 122, as well as a particular delivery location. It is realized that the optimal delivery route is determined without any a priori knowledge of what POS 122 and what agents 151 to use, the selection of POS 122 and agents 151 is part of the determination of the optimal route. The optimal route is further calculated based upon the said inventory and location information provided to the central server 110. Once the optimal route has been determined, an expected delivery time is calculated for the optimal route to the said delivery location.

It is preferred that the optimal route may comprise, or actually comprises, at least two different POS 122. It is also preferred that the optimal route may comprise, or actually comprises, at least two different delivery agents 151.

Once the expected delivery time has been calculated, the central server 110 electronically presents updated information regarding the expected product delivery time to a purchasing user 131, and the user 131 is allowed to, electronically and preferably using the above described GUI on the device 130, order the product.

The ordering of the product may also preferably take place via the GUI on the device 130, such as by selecting one or several products and pressing a "purchase" button in the GUI. This will result in ordering information being provided to the central server 110 from the device 130. It is preferred that the information received by the central server 110 beforehand is sufficient for the central server 110 to effectuate the order immediately, without requiring any additional information or confirmation from the user 131. Hence, the information available to the central server 110 after the said initial information receipt at least comprises information identifying the desired delivery location and identifying a billing channel, but preferably also comprises information identifying the purchasing user 131.

Once the order has been received by the central server 110, the central server 110 elec- tronically sends reservation information to the said selected at least one POS 122, as well as delivery information to the said at least one selected delivery agent 151.

The reservation information may preferably enter directly into the respective ERP system 121 of the retailer 120, directly affecting the inventory information used internally in the retailer 120 in question, and in particular for each POS 122 of the retailer 120; or it may be presented directly to retailer 120 and/or a POS 122 as a message for the staff personnel in the affected POS 122 to take into consideration the reservation of the ordered product when serving customers physically entering the POS 122 or ordering online via parallel channels or other systems.

The delivery information is preferably automatically presented as a push notice on the device 150 of the selected delivery agent 151, whereupon the delivery agent 151, via the interface 113 can choose to accept the delivery assignment indicated and detailed in said push notice.

If there for some reason is not possible to reserve the product at the POS 122 and/or if the delivery agent 151 does not accept the delivery assignment within a certain predetermined time period (which is preferably 1 minute or less), the optimal delivery route is immediately and automatically redetermined by the central server 110 under such updated precondi- tions, and the method iterates until a confirmed delivery route is achieved, involving required valid reservations and acceptances. This is preferably performed in a way which does not at all involve the purchasing user 131, who hence preferably is not provided with any information about such iterations, and in particular does not have to provide any information to this process.

It is in general preferred that delivery assignment requests are sent to more delivery agents 151 than what is necessary for performing the delivery, and that the delivery agent(s) 151 to actually perform the delivery is or are selected as the or those first responding to the assignment request. A subset of all available agents 151 are preferably selected, by the central server 110, for receiving assignment requests, based upon a predetermined suitability criterion, such as a ranking system implemented by the central server 110, as described below. If none, or too few for performing the delivery, of the agents 151 respond, a new iteration is preferably performed, sending assignment requests to another or supplementary subset of agents 151.

Then, the physical delivery is initiated, in other words the delivery agent 151 starts off to the POS 122 devised by the central server 110 for pickup of a physical product devised by the central server 110 according to the optimal route, and then brings said product to the delivery location also devised by the central server 110 according to the optimal route. If there are several products and/or POS 122 involved, the delivery agent 151 simply follows the route trajectory devised by the central server 110, corresponding to the optimal route. The route is preferably supplied via interface 113 and presented in a suitable format, such as in an interactive graphical map, on a screen display of the device 150 of the agent 151 in question. As described above, the route may also involve several agents 151 working in parallel, in the corresponding manner.

During the delivery of the product, in other words during the execution by the delivery agent(s) of the devised optimal delivery route, the central server 110 is electronically provided with updated inventory and location information. This information provision may take place in the same principle way as the first updated inventory and location information provided as described above, such as on the initiative of the central server 110 and/or by regular or push notifications by connected POS 122 and/or agent 151 devices 150. According to this first aspect of the invention, before the product(s) in question has or have been delivered to the delivery location, and preferably during the performance of the selected agent(s) of the optimal route, the central server 110 automatically redetermines the optimal product delivery route so as to achieve an updated optimal product delivery route under the prerequisites carried by the updated information in question. This updated optimal route is preferably determined based upon said updated inventory and/or location information. If at least one selected delivery agent 151 or at least one selected point of sale 122 has changed, the central server 110 again sends, electronically, reservation information to the at least one selected POS 122 according to the updated optimal route which has a different role to play in the updated optimal route as compared to the previously determined optimal route. Correspondingly, any delivery agent(s) 151 that has or have been assigned altered roles as a result of the redetermination of the optimal route is or are sent delivery information from the central server 110. If an agent 151 is recruited for the first time with respect to the delivery of the product in question in the redetermined optimal route, the agent 151 in question is preferably sent an option to accept or not to accept the delivery assignment, as described above. In case the agent 151 is unable to accept the delivery, the central server 110 preferably again redetermines the optimal route under prerequisite that that particular agent 151 is unavailable. This may be performed iteratively, until a confirmed optimal delivery route has been accomplished.

Such updating of the optimal delivery route is hence performed on the fly, taking into consideration instantaneously varying conditions for the delivery of one or several products, in a way that optimises the product delivery time and hence provides a high standard user experience. The user 131, on the other hand, needs not be bothered with the workings of the central server 110, since the delivery process may be performed completely by the central server 110 in collaboration with the retailers 120 and/or POS 122, and the delivery agent(s) 151, without providing any detailed information to the user 131. Preferably, the central server 110 thereafter keeps obtaining updated inventory and location information, and again redetermines the optimal delivery route whenever there is reason to do so. Once the product(s) has or have been delivered to the delivery location, the central server 110 is notified, for instance by an acknowledgement made by the purchasing user 131 via the user's device 130 and sent to the central server 110, and/or by the delivery agent's 151 device 150 automatically sending its current position to the central server 110 that in turn verifies that the location is indeed at or sufficiently near the delivery location in question.

It is important to note that such redeterminations of the optimal route take place on the fly, after the actual physical delivery from the POS 122 to the delivery location has been initiated, preferably as the movement of the product in question is actually ongoing, or at least while the at least one selected delivery agent 151 has started his or her journey to the pickup location. Preferably, this takes place via an intimate communication between the agent's device 150 and the central server 110, as described above, in which the device 150 preferably shares not only its current location, such as using a GPS sensor in the device 150, but also optional additional information, as described below. Preferably, the at least one POS 122 further communicates, in a push type of communication, any inventory changes locally at the POS 122 to the central server, preferably as soon as any such inventory changes occur, such as another customer entering the POS 122 and buying a product of the same type as the one to be delivered. The same or other POS 122 may also send information to the central server 110, for instance that a shipment has arrived with products of the said type, making different POS 122 available as pickup locations for such products.

It is preferred that updated inventory and/or location information is provided to the central server 110 at least every 10 minutes, preferably at least every minute, and that the redetermination is performed as soon as such updated information provides basis for an optimal route which is more suitable than the previously determined optimal route, counting the negative effects of having to change POS 122 and/or agents 151. Such negative effects are preferably quantified by the central server based upon predetermined quantification rules, and a first optimal route is considered "better" than another optimal route, by the central server 110, in case the total delivery time, after adjustment using such quantified negative effects, is shorter. Hence, an "adjusted" expected delivery time is calculated in a way which is congruent with the above described ways of adjusting the expected delivery time using cost factors such as per-pickup location delays and travel expense costs.

Figure 3 illustrates a flowchart of a second aspect of the present invention, relating to the actual act of the purchasing user 131 ordering the product(s) delivered as described herein. It is realized that the first aspect described above, relating to the delivery as such and its dynamic implications, and the said second aspect are completely compatible. Hence, everything which is said in relation to the first aspect is directly useful in the second aspect, as applicable, and vice versa.

In this second aspect, the method starts in a first step.

In a subsequent step, which may be performed in connection to the ordering of the product or beforehand, the central server 110 is provided, electronically, with information regarding a purchasing user 131. Such information may comprise any personal information regarding the purchasing user 131, such as name and home address; credit card information or other information identifying a valid payment channel of the user 131; personal interests and tastes; browsing history; and/or any information which may be used to provide the user 131 with an efficient and/or pleasant product ordering experience.

According to this second aspect of the invention, the information in particular comprises a desired delivery location. Such a desired delivery location may be explicitly given by the purchasing user 131, such as by providing an address or selecting the current location of the device 130, as measured using a GPS sensor of the device 130 (preferably in direct connection to the ordering of the product, so that delivery takes place to the current location of the user) or similar. It may also be automatically inferred, by the central server 110 or software executed by or from the device 130, based upon previous purchases with associated delivery locations; knowledge of the user's 131 normal daily trajectory between home and work (as measured by the said GPS sensor of the device 130 and reported to the central server 110 by the above described software), by the user defining particular desired delivery locations for different predetermined periodically occurring and/or future time periods; or in any other way. One preferred example is that the user selects a particular object, such as a particular vehicle, and that the desired delivery location is always to that particular vehicle. Then, the central server 110 queries the current location of the vehicle in question, for instance using open interfaces to the vehicle or a web page providing such information, after being granted such access by the user 131, and selects the acquired location as the desired delivery location.

An important aspect here is that the desired delivery location is provided by the purchasing user 131 before the potential purchasable products are presented to the user 131 in question, or alternatively that information making it possible for the central server 110 to automatically determine the desired delivery location is provided to the central server 110 be- forehand by the user 131, so that it is not necessary for the user 131 to actually provide neither a desired delivery location nor such information in connection to the actual ordering of the product. It is particularly preferred that the user 131 needs not specify a desired delivery location in connection to the actual purchase, but that the central server 110 has been provided sufficient information beforehand so as to determine the desired delivery location automatically based upon such information. This makes it possible for the user 131 to simply select an available product, as described below, not having to provide any other information in order to have the purchased product payed and delivered in a convenient manner. In particular, it is preferred that the desired delivery location is automatically selected based upon the current location of the user 131, which is detected by and communicated to the central server 110 from the user 131 device 130. Alternatively, the central server 110 keeps information regarding at least one geographical location frequented by the user, and/or at least one previously used delivery location for the user, and wherein the central server 110 allows the user to select the desired delivery location based upon said information. After having received such information, the central server 110 is provided, electronically, with inventory information regarding present updated physical availability of the product in question from a plurality of physical points of sale, as well as location information regarding present respective geographic locations for a plurality of available mobile delivery agents. These steps may be similar to the above described corresponding information provision steps.

In a way which also may be similar to what has been described above, the central server 110 thereafter determines an optimal physical product delivery route, involving at least one selected delivery agent, at least a selected one of said points of sale, as well as the said desired delivery location, based upon the said inventory and location information, and calculates an expected delivery time for the optimal route to the desired delivery location.

Thereafter, the central server 110 determines whether or not the expected delivery time for the at least one product is longer than a corresponding predetermined maximum delivery time, which may be defined beforehand for a particular type of product and/or the purchasing user 131 and/or the time of day and/or in dependence of a currently prevailing supply/demand situation with respect to the current product type(s). If the expected delivery time is not longer than said maximum delivery time, the central server 110 automatically causes the purchasing user 131 to be presented with an option to purchase the product without having to specify a desired delivery location or a desired delivery time. The option may be presented in the above described interactive GUI on a screen display of the device 130, and may comprise information regarding the calculated expected delivery time. Hence, the central server 110 may present the option itself, or alternatively and preferably, causes the device 130 to present the said option.

Here, it is important that no such purchasing option is presented to the user 131 regarding a particular product in case the product in question is not expected to be delivered within the said predetermined maximum time period. This may be true for individual products, or for types of products, depending on at what aggregation level the determination is performed. It is preferred that all POS 122 at which the product in question is sold are taken into consideration for determining the optimal delivery route and the corresponding expected delivery time.

Since the central server 110 has knowledge of all information, including the desired delivery location, necessary for calculating an expected delivery time before presenting the user with a selection of products, the presented selection as such will be of high quality in terms of delivery availability and timeliness, with no need to perform any additional acknowledgement or information provision steps vis-a-vis the user 130. As mentioned, the predetermined maximum delivery time may be dynamically determined, but it is preferred that it is at the most 2 hours, more preferably at the most 1 hour, at least for some product types.

In practice, the user 131 will typically be presented with different options with respect to different products or product types, depending upon geographic product and agent 151 availability as well as upon possibly different maximum delivery times for different product types. Hence, a virtual store may be presented with different products, in which only products that can be delivered with expected delivery times that are shorter than the predetermined maximum time period are available for purchase; or such a virtual storefront may be constructed on the fly, only presenting products available for such short expected delivery times. As such, the virtual store front may preferably dynamically change appearance in reaction to updated product availabilities, since the central server 110 preferably is repeatedly provided with inventory and location information, and repeatedly redetermines the optimal delivery route and corresponding expected delivery times, as illustrated in figure 3. This is preferably performed at least for a particular predetermined selection of available products in the connected POS 122. Hence, the virtual store front may be a dynamically updated portal, that is updated in near realtime in reaction to the movements of available delivery agents 151 and the current inventory of each of the connected POS 122. Then, if the user accepts the said option, for instance by clicking on a "purchase" button in said virtual storefront, the central server 110 sends, electronically, reservation information to the said selected point of sale, as well as delivery information to the said selected delivery agent, in a way corresponding to what has been said above.

Hence, in case the information sent to the agent(s) 151 and the POS 122 is acknowledged in the positive, as described above, the delivery of the product is initiated. From this point, the dynamically updated delivery process described in relation to figure 2 may be used.

During the delivery, the optimal route may hence be modified. In case the delivery according to such a modified optimal delivery route causes at least one product to be delivered in a total delivery time exceeding the predetermined maximum one (such as after an automatic splitting of a delivery into two or more separate deliveries), it is preferred that a notification is sent to the purchasing user 131, such as to the device 130 for presentation in said interactive GUI, providing the user 131 at least with information regarding the expected delay, and preferably also providing an option for the user 131 to opt out of the part of the delivery bound to be delayed.

As mentioned above, it is preferred that the purchased product is offered for sale by said at least one POS 122, in addition to direct on-site purchase and purchase with delivery via said mobile delivery agents 151, also via an e-commerce web site with conventional surface mail delivery. This is a context in which the present invention is particularly advantageous, since such additional sales channels bring about a complex inventory situation, which is difficult to keep track of on the local POS 122 level. Since the central server 110 has access to an aggregated, dynamically updated view on the inventory situation, in combination with a dynamically updated view on the agents' 151 current locations, it can offer a far more precise and useful view of current product availability to purchasing users 131.

However, it is preferred that both the central server 110 and the respective physical points of sale 122 keep updated inventory information regarding product availability at the respective POS 122. For instance, each POS 122 may keep its existing inventory tracking software or database, simply providing a bridge to the central server 110 for querying and reporting current inventory status and changes. This provides a particularly low barrier of entry to the individual POS 122. In this case, it is preferred that the central server 110 keeps a set of inventory information which is a mirror of the information kept by the respective physical points of sale 122. In order to obtain the said aggregated inventory view, the central server 110 in this case queries or subscribes to inventory information from each connected POS 122.

The central server 110 may be arranged to interact with, or comprise, a piece of inventory tracking software, which may for instance be provided to individual POS 122 as a SAAS (Software As A Service). In this case, the information integration between the central server 110 and the POS 122 regarding local POS 122 inventory is easy to accomplish, and the POS's 122 perspective of the current inventory situation at the POS 122 in question may still be considered the master, while the aggregated inventory view kept by the central server 110 is the copy. It is preferred that the central server 110 queries at least one respective physical point of sale 122, preferably all connected POS 122, regarding updated inventory status at the POS 122 in question in connection to determining the said optimal delivery route in various situations as described above. According to a preferred embodiment, the central server 110 provides at least one, preferably all connected, POS 122 with a possibility to provide information regarding future availability of a product for pickup at the respective POS 122. Such provision may take place via the ERP system 121, via a dedicated web interface usable by local POS 122 staff for directly providing information to the central server 110, or in any other suitable manner. Such in- formation may comprise normal scheduled product availability, such as normal opening hours; deviating opening hours; staff availability during opening or even closing hours for expediting agent 151 pickups; any special events leading to deviating product availability; future planned shipments of more products to be received; and expected sell-outs of particular product types. Then, such information received by the central server 110 is used by the central server 110 when determining the said optimal delivery route. This will provide a more reliable delivery to the user 131, while still not putting unreasonable burden on individual POS 122 staff.

In particular, it is preferred that the optimal delivery route is calculated based upon a fore- cast, as calculated or received by the central server 110, of at least one future value selected from the group consisting of physical point of sale 122 opening hours and/or staffing; expected local traffic situation; expected geographic delivery agent 151 availability and/or trajectory; aggregated supply of the product in question; and aggregated demand for the product in question. Such aggregation is preferably performed across a plurality of POS 122.

Regarding the traffic situation, it is preferred that the central system 110 receives such current and forecast information from a third party, and integrates this information with agent 151 location and expected trajectory information, which integrated information is used to calculated the expected delivery time of the delivery route considered by the central server 110.

Regarding the aggregated supply/demand for the product in question, it is preferred that the central server 110 automatically calculates this on product type level, based upon historic and current data on aggregated product purchases and POS 122 inventory. It is pre- ferred that the central server 110 automatically analyses this data statistically, and determines any periodically changing systematic patterns regarding yearly, monthly, weekly and/or daily supply and/or demand, and takes such patterns into consideration when calculating an expected aggregate supply and/or demand based upon a projection of the available aggregated historic and current information. For instance, if the supply of a product is higher than normal while the demand is at a normal level, or in case an expected shipment into one of the centrally located, large POS 122 is expected soon, the central server 110 may automatically detect and exploit this fact when determining the optimal delivery route, and as a result present an expected delivery time which is shorter than what would otherwise have been the case. This achieves a service which can dynamically and automatically adapt to the locally shifting conditions in for instance a downtown area. More particularly, the central server 110 preferably calculates, preferably periodically or dynamically in reaction to information update availability, a present and/or expected future aggregated supply of the product in question, as well as an aggregated present and/or expected future demand for the product in question, based upon information received from the physical points of sale 122. Then, the central server 110, before the optimal delivery route is determined, dynamically offsets its own aggregated inventory information and/or a predetermined time during which the product is reserved at the selected physical point of sale 122, based upon the calculated aggregate supply and demand. For example, the central server 110 may, as a part of the determination of the optimal route, adjust down aggregated inventory levels regarding a particular product type in the wake of an expected sale via customers entering particular POS 122, and then use the adjusted aggregated inventory level for determining the optimal route. This way, the central server 110 may actively and proactively manage the aggregated inventory so as to achieve a stable delivery of particular product types in the longer term. Correspondingly, the expected inventory level at individual POS 122 may be adjusted, which may lead to a particular optimal route using a different POS 122.

In a particularly preferred embodiment, the inventory information received by the central server 110 from at least one POS 122 comprises information regarding sales by the POS 122 in question via at least one other channel than via the central server 110, such as via an e- commerce web site with conventional surface mail delivery as described above.

Regarding the determination of the optimal delivery route, it may in some embodiments be a single optimal route performed by a single selected delivery agent 151. However, more than one delivery agents 151 may be used, in parallel or even in series, and in particular one single product order may be handled in more than one delivery routes. As used herein, the term "optimal delivery route" is intended to cover also such a combination of several delivery routes.

Hence, in a preferred embodiment the central server 110, as a part of the determination of the optimal route, investigates the possibility of using several delivery routes, preferably performed with a time overlap, in an effort to decrease the total delivery time. Preferably, the use of multiple delivery routes is associated with a cost factor of the above described type, taking into consideration the drawback of the user 131 having to potentially interact with several delivery agents 151 and the fact that two or more delivery agents 151 are un- available for other delivery assignments during the delivery of the product in question. Thus, if such a shorter expected delivery time results, or in particular in case a determined optimal delivery route involving only one delivery agent is expected to result in a total delivery time which exceeds a certain threshold, such as the above described maximum delivery time, it is preferred that the central server 110 determines the optimal delivery route as a route comprising two sub routes, which are or may be performed in parallel by different delivery agents 151.

As mentioned above, the order placed by the user 131 may be for one or more products. In case ordered products are to be picked up at different POS 122 (for instance, if they are not sold in one and the same POS 122), the optimal route must be determined with at least two POS 122 as intermediate stops. In this case, the determination of the optimal delivery route may preferably comprise the following sub steps:

Firstly, a first optimal delivery route is calculated, as a preliminary optimal delivery route.

Secondly, a particular one of the available delivery agents 151 is selected, based upon proximity of the delivery agent in question to the calculated first route.

Thirdly, a second optimal delivery route is calculated, based upon location information re- garding the selected delivery agent 151. It is realized that this second optimal delivery route may be different from the first delivery route, both in the sense that it may involve visiting the involved POS 122 in a different order than according to the first route, but it may also be so that the central server 110 determines the second optimal route from scratch, based upon the preconditions that the selected delivery agent 151 is to be used, in which case other POS 122 may be selected for the second optimal delivery route than for the first one. At any rate, the second optimal delivery route is then used as the determined optimal delivery route as described above. This provides a particularly simple way of quickly determining an optimal route which is sufficiently good, taking into consideration that there will typically not be enough time to try all possible routes and selecting the quickest one. In partic- ular, the preferred case is that the second route is always determined using the selected delivery agent 151 and the same POS 122 as according to the first route, but wherein the POS 122 may be ordered differently in the second route.

The above described setup with the central server 110 in communication with the different interested parties 122, 131, 151, providing a dynamically updated aggregated status view, allows further advantageous applications.

One such application is to allow for different maximum delivery times depending on the product type. For instance, a product in the form of an ice cream or a cup of coffee may be associated with a maximum allowed delivery time of 30 minutes, while a pair of shoes may be associated with a maximum allowed delivery time of 2 hours. Furthermore, different types of products may be associated with maximum delivery durations, in other words a maximum time between pickup of a delivery agent 151 and delivery to the delivery location. For instance, an ice cream may have a maximum delivery duration of 10 minutes, meaning that a delivery agent 151 likely would have to pickup the ice cream as the last stop on an optimal delivery route in order to meet this delivery duration criterion.

Preferably, the central server 110 defines such a maximum delivery duration for at least one product type, and applies such maximum delivery durations as boundary conditions when determining the optimal delivery route. Hence, the optimal delivery route is preferably determined based upon the type of product, whereby different such types are associated with different thresholds regarding delivery durations, as applicable. In particular, in case the delivery comprises at least two products of different product types, the optimal delivery route is determined further based upon different delivery duration thresholds, if any, asso- ciated with the different product types. Herein, a "product type" means any meaningful classification of products which may be imposed by the central server 110, such as via configuration over interface 114.

Furthermore, the central server 110 may accept information, via interface 113 and preferably after information supply via the above described interactive GUI on the device 150 screen display, regarding future planned availability and location of individual delivery agents 151. For instance, each delivery agent 151 may be able to, using the said GUI, specify a personal availability schedule, comprising a default schedule which may be modified by temporary schedule amendments, and/or a planned future trajectory to be partaken by the agent 151 in question. Also, the software executed by or from the device 150 may track its geographic position and automatically detect motion patterns of the delivery agent 151, based upon statistical analysis of position changes over time; or make projected forecasts of the future position of the agent 151 in question. Furthermore, the central server 110 may take into consideration delivery assignments that have already, or have not yet, been notified to the agent 151 in question, implying that the agent 151 will travel to a particular delivery location in the near future.

Then, it is preferred that the central server 110 determines the optimal delivery route, and in particular what delivery agent(s) 151 is or are to participate in the delivery of the product in question, based further on such a future planned availability and/or trajectory and/or a historic trajectory of individual delivery agents 151. This way, the central server 110 may make powerful use of its overview of the total geographic distribution and movements of all available delivery agents 151.

As described above, in some embodiments, a total aggregated supply of available products may be presented to the purchasing user 131. In this case, it is preferred that such presentation is made available in one single digital interface view, such as on a screen display of the user's 131 device 130. Further preferably, such view does not disclose at what POS 122 each respective product is available. Moreover, it is in this case preferred that an expected or maximum delivery time is specified for each product type, rather than for each individual product. In particular, it is preferred that the user 131 in this case never has to, and preferably is unable to, specify the POS 122 from which an ordered product is to be delivered. This provides a particularly convenient user experience, made possible by the detachment between POS 122 and user 131 provided by the central server 110.

As also has been described above, the central server 110 sends a reservation information for ordered product(s) to be delivered, to the POS 122 in question. It is preferred that such reservation is valid only for a specific time period, which may be predetermined. However, the specific time period in question is preferably determined by the central server 110 dynamically, and in particular based upon the determined optimal delivery route. For instance, the specific time may be the actual expected time that the agent 151 pickup will occur plus a time margin of, for instance maximum 5 or 10 minutes. Preferably, the specific time may also be determined based upon prevailing aggregate demand/supply of the product in question, as well as possibly local inventory of the product in question in the selected POS 122. For instance, if the demand for a particular product type currently massively outweighs the supply for that product, a retailer 120 may end up with the majority of its product stock being reserved pending pickup, either in the form of self-pickup by products ordered via external sales channels or pending agent 151 pickup. This type of situation can be offset by the central server 110 balancing the supply against the demand by giving priority to in-store sales. Such priority may be achieved indirectly by limiting the possible reservation time used before agent 151 pickup, in turn constituting a boundary condition when determining optimal delivery routes as explained above - if a delivery route implies that a particular product must be reserved for a time which is longer than the maximum allowed time at the moment, such delivery route is not allowed. Correspondingly, when current demand is larger than current supply, allowed reservation times may be prolonged for a particular product type.

If the product is not picked up from the POS 122 within the specific time period, it preferably automatically becomes available for purchase by other users. If this happens, the central server 110 preferably redetermines the optimal delivery route as described above, using the updated inventory information. This way, a particular product may be available for direct over-the-counter purchases, or be reserved for another specific time period. According to a preferred embodiment, the central server 110, during the delivery of the product(s), provides an updated expected delivery time to the purchasing user 131 via the said GUI provided on the screen display of the user's 131 device 130. This way, the user may follow the ongoing delivery and can plan his or her activities up until the delivery time.

In one preferred embodiment, in case the user 131 has initially indicated that deliveries are to be made to the current location of the user 131, the user 131 may move during the delivery, in which case the device 130 reports this to the central server 110 that uses the updated location of the user 131 as an input (an updated desired delivery location) in the redetermination of the optimal delivery route described above. This way, a user may for instance order a cup of coffee which is then delivered to the user, even if the user is on the move. All this is achieved by a simple press of a button in a GUI on the user's 131 device 130, without requiring any more interaction or input on the part of the user 131 in question.

In yet another preferred embodiment, the user, during the delivery of the product(s) and via the said GUI provided on the screen display of the user's 131 device 130, is provided the choice of modifying the determined optimal delivery route, which optimal delivery route is then automatically redetermined by the central server in reaction to the modification. For instance, the user 131 may be presented with a number of alternative routes that are all locally optimal and that all provide delivery within the maximum delivery time, from which number of alternative routes the user may select one which is desired by the user 131. For instance, in case the delivery location may be updated by the user 131 as described above, the user may select a route which is more convenient for delivery to a delivery location which the user 131 knows to be current in a while.

Also, such a modification of the optimal route may comprise a choice regarding what POS 122 to pick up the product from.

The online order and purchase of a particular basket of product(s) comprises a number of checks, in order to guarantee maximum likelihood of product availability during delivery. Hence, during a product listing step, the local stock levels of the product(s) in question is preferably checked, via the E-com system 124. Then, during a product basket checkout step, the order is preferably verified, including the pickup location, the delivery location, the delivery time and the stock keeping unit list and quantity. This verification is preferably performed internally in the central server 110, against the aggregated view kept therein. Then, in an order creation step, the order is preferably created using the information verified in the said checkout step. However, the selected POS 122 may be determined at a later stage, or even changed during delivery, as described above.

The central server's 110 view of inventory levels at individual POS 122, which is used to build the said aggregated inventory view kept by the central server 110, may comprise a number of different activities, as outlined in the following.

Inventory data may be directly uploaded to the central server 110, such as via interface 114, for instance in the form of data formatted in a predetermined way readable to the central server 110. In this case, the data directly affects the recorded product stock levels in the central server 110.

The central server 110 may directly query individual POS 122 or retailers 120 regarding current inventory levels, which query may be posed to the E-com system 124. This step can also be regarded as an inventory information synchronization between the retailer 120 and the central server 110, and can be performed periodically or according to a push scheme.

The E-com system 124 may also be responsible for the verification and initiation of an order of a particular product to be part of a delivery to a user 131. In this case, the E-com system 124 validates a particular order for a particular product carried by the retailer 120 in question based on local product availability and delivery details. If validation is successful, the order is created based upon the same details, however preferably after payment has been verified by the central server 110 to the retailer 120. Thereafter, the central server 110 may create the order and communicate it to the ERP system 121, reflecting the order details verified by the E-com system 124, comprising product or product type identities, quantities and pickup location. Once the order has been created, the inventory stock levels of the POS 122 in question are updated accordingly.

In response thereto, the central server 110 may synchronize the stock levels, possibly with offsets as described above, with the ERP system 121 for all pickup POS 122 and products involved in the delivery. In addition thereto, the central server 110 may periodically, such as at least once every day, query the ERP system 121 for an updated inventory regarding a particular product or product type in combination with a particular POS 122.

Furthermore, the central server 110 may query the PIM system 123, such as via the ERP system 121, for product metadata, such as product imagery, descriptions and data, for use when presenting product information to the user 131 as described above.

This way, the central server 110 is able to add the aggregated functionality described herein without requiring any major modifications to existing infrastructure of the connected retail- ers 120.

Example #1 - Stock depletion on sales channel for a purchase with immediate delivery

Precondition: The user 131 has provided the required delivery and payment details

• The user 131 confirms the order on the aggregated marketplace provided by the centra l server 110 via an interactive GUI on the device 130 by selecting "Confirm order" no device 130.

• The central server 110 verifies and creates the order in relation to the retailer 120. · The retailer 120 performs stock validation against the central server 110 for the specific order. • The central server 110 checks the channel-specific (here, immediate delivery) stock inventory level for the provided products and selected pickup location(s) 122.

• The product may exist in the selected pickup location 122, but not for the specified channel, in which case the request fails.

· The central server 110 temporarily reserves capacity for the ordered products.

• The central server 110 creates an order in the ERP system 121.

• The ERP system 121 ensures that no standard delivery dispatch takes place.

• The central server 110 finalises and depletes the stock levels for the ordered products with the confirmed remaining quantity from the ERP system 121.

· The central server 110 causes the delivery to be dispatched to the delivery agents 151, for instance using an order fulfilment system which is a part of the central server 110.

• The marketplace confirms to the user 131 that the order has been placed and that delivery is dispatched. Example #2 - Stock synchronisation on in-store purchase

• A user 131 pays for particular products in the POS 122, and leaves with the products.

• The POS 122 places an order in the ERP system 121.

• The ERP system 121 sends the updated stock inventory regarding the particular products to the central server 110, with reference to the POS 122 in question and the physical store sales channel. This is only done for products which have been marked as being available for immediate delivery using the central server 110 and agents 151.

• The central server 110 updates its view of the stock inventory for the products/POS 122/sales channel combination.

· The central server 110 periodically synchronizes its view on the stock inventory with the ERP system 121 of the retailer 120 in question to ensure that both systems are up-to- date.

• The ERP system 121 is considered data master, as the physical POS 122 warehouse/shelf stock level is periodically revised through stock-taking. • The synchronisation deals with scenarios where the sales channel specific levels have drifted from the actual levels, for instance after in-store POS 122 purchases for products which have manually been collected from the POS 122 in-store warehouse.

Example #3 - Balancinfi sales channel stock inventory

• The inventory administrator 141 logs in to the central server 110.

• The inventory administrator 141 finds the business unit (that is POS 122), product type or concrete product he or she wishes to re-balance.

• The inventory administrator 141 enters the percentage, or absolute numbers for individual product(s), of stock to be reserved to the different sales channels available, namely POS 122 in-store; online with self-pickup; and online with immediate delivery using the central server 110 and agent(s) 151.

• The central server 110 rebalances its view on stock inventory levels according to the given parameters and context, for instance entire product type or category, or individual products. The total number of products will remain the same, but balanced over different sales channels.

In the following, a number of particular details will be described in closer detail, regarding the provision to the user 131 of a reliable, accurate and immediate delivery.

Specifically regarding store opening hours and staff availability information available to the central server 110, these metrics are preferably offset and/or adjusted, as described above, before being used to display which products are available for immediate delivery to the user 131 in said GUI on the device 130. For instance, delivery may be offered outside POS 122 regular opening hours, such as due to extraordinary availability of the staff.

If the POS 122 is currently closed, or if there is no staff available to perform the picking and packing, a "deliver at this specific time" option preferably becomes available to the client in said GUI, at least in case available date/time options are provided to the central server 110 from the POS 122 or retailer 120 in question. If, on the other hand, the POS 122 is open and/or staff is available (such as outside of normal opening hours), immediate delivery is available and shown to the user 131 as described above.

As described above, the availability of staff in a particular POS 122 may be determined by the central server 110 based upon a predetermined schedule provided by the POS 122 or retailer 120 in question, which schedule may be overridden to reflect extraordinary events, as they occur in real-time. Such overrides are preferably mirrored, using push communication to the central server 110 and on to the device 130, in real-time to the user 131 at the digital store front.

Specifically regarding over fulfilment scheduling, scheduling of the order fulfilment process such as picking and packing is preferably performed on a per-POS 122 basis. As with staff availability, the time required to prepare an order for pickup is preferably predetermined but may be overridden in real-time by the staff, for instance to compensate for rush hours where fulfilment times may be prolonged.

Specifically regarding the agent(s) 151, they signal availability and position information to the central server 110 via their respective device 150, as described above. Specifically, the current location, velocity and direction of the agent 151 in question is preferably periodically transmitted to the central server 110 and used therein for optimal route determining.

This data is aggregated from multiple potential agents 151, and preferably allows real-time updates to the delivery capabilities with respect to a particular order. As a consequence, this allows accurate real-time feedback to be provided to the user 131 as well as involved agents 151 regarding current route updates and similar.

In many situations, several agents 151 may be present in the local area, each being sufficiently well-suited to perform a particular delivery. In such cases, a number of potential agents 151 may receive a respective notification with an offer to perform the delivery, and the actual selection of delivery agent is achieved through first-come acknowledgement by the agents 151 in question. According to a particularly preferred embodiment, agents 151 are ranked using a ranking score which is calculated by the central server 110, based upon at least geographical proximity to the optimal delivery route, and in particular to a pickup location, but potentially also based upon other factors, such as previously performed number of deliveries; average historic user 131 rating; fee requested by agent 151; current agent 151 velocity, direction and/or means of transportation; current agent 151 density in the local area of a particular scored agent 151; and delivery location in relationship to a planned near-time pickup location in a different delivery route. The latter allows the exploitation of possible subsequent and bi-directional deliveries by one and the same agent 151. The ranking of the delivery agents 151 are preferably updated as soon as new information becomes available to the central server 110.

Then, a notification describing the delivery assignment may be sent to all agents 151 with sufficiently high ranking for the particular delivery, and the delivery assignment is allocated to the or those (in case several agents are required due to optimal route splitting as described above) agents 151 first to respond to the notification.

Specifically regarding pickup location ranking and selection, a user 131 performing a purchase using the above described aggregated digital storefront, using the central server 110 and agent(s) 151, and requesting immediate delivery, is not directly concerned with the specifics of where the product(s) are delivered from.

In particular, the pickup location(s) is or are selected based on a number of parameters related not only to the order itself, but also the availability of suitable agents.

On ordering a single product, this is simplified to the product itself, without having to consider multiple pickup locations and sufficient stock levels for several products. However, if however multiple products are ordered, a more complex process is preferably applied. If the products are available at the same POS 122, the process may start by examining the option to have all products delivered from the same physical POS 122. This process preferably assumes that it is possible to find a suitable delivery agent 151. Secondly, it is preferably assumed that it is more efficient to have a less suitable delivery agent 151, for instance presently located further away, pickup multiple products from the same POS 122, rather than a more suitable agent 151 pickup from multiple locations.

If none of the available POS 122 pickup locations have all the products in stock, a multi-store pickup is preferably initiated and treated similarly to having multiple merchants in the same order, see below.

In deciding the final pickup POS 122, a ranking of the available POS 122 is preferably applied, calculated by the central server 110 based upon at least one parameter selected among the group of parameters comprising pre-selected POS 122 by the retailer 120 in question to handle all immediate delivery orders; specialized POS 122 selected by the retailer 120 to handle specific order types, such as gifts; POS 122 opening hours and staff availability (see above); geographical proximity to the current delivery location; and order history of the user 131 in a particular POS 122. Hence, the merchant preferably has the possibility to instruct the central server 110 to treat different POS 122 differently, which information in that case will automatically be used by the central server 110 when calculating the optimal delivery route.

If multiple products are ordered, that need to be picked up from multiple POS 122, an even more complex process may be applied. As with multiple products from the same POS 122, it is preferably first assumed that it is possible to find a suitable delivery agent 151 regardless of the location of the pickup locations. In order to determine the final pickup locations, a number of steps are performed. The primary goal is to find the minimum cost route for the delivery agent 151 to pickup all products and have them delivered to the delivery location. The "cost" in question is preferably defined and determined by the central server 110 based on a number of parameters, one of which preferably is the calculated estimated travel time between the different locations, including the current location of the delivery agent 151 in question and the delivery location. Added to this is preferably a predetermined assumed per-pickup-location duration, to account for the time spent to pickup the products.

Additional parameters that may be used comprise estimated travel time, including transit; real-time public transport scheduling, hop-count and traffic delays; and delivery agent 151 transport method (for example, car may be prioritized for longer distance deliveries which would result in multi-hop public transport).

The "cost" in question is preferably calculated, by the central server 110, for all combinations of potential merchant pickup locations and the delivery location. When the lowest- cost delivery route has been selected, the agent 151 ranking preferably takes place as described above. The addition here is that the distance is calculated from all pickup locations in the current delivery route, using only the shortest distance as it is considered to be the first stop for the delivery agent 151.

Example #3 - Purchase of products from multiple merchants

Precondition: The user 131 is identified by the central server 110, via the device 130, and a payment method has been identified for the user 131 in question.

• The user 131 visits the aggregated marketplace provided electronically by the central server 110, via said GUI on the device 130.

• The user 131 adds a number of products from different merchants to the shopping cart, such as a shirt and a box of chocolates.

• The user 131 selects the option to finalise the purchase.

• The marketplace prompts the user 131 to enter a desired delivery address/location, whereupon the user 131 enters his or her current address and selects continue; or alternatively the central server 110 already has sufficient information for determining the desired delivery location automatically, as described above. • The central server 110 calculates the optimal delivery route and associated estimated time of delivery, and returns this information to the marketplace.

• The marketplace presents an order finalisation screen to the user 131, including the estimated time of delivery to the delivery location.

· The user 131 confirms the order via said GUI.

• The central server 110 dispatches the order to the selected POS 122 and the subset of selected delivery agents 151.

• The marketplace presents an order confirmation screen to the user 131. In the following, a number of particular details will be described in closer detail, regarding the provision to the user 131 of a possibility to initiate an order, with associated automatic delivery, with a minimal interaction with the central server 110 at the time of ordering.

Hence, since the following information may preferably be available to the central server 110 at the time of ordering by a particular user 131, using the above described mechanisms, it is possible for the system 100 to achieve highly reliable yet flexible and customizable online transactions, that can be ordered by a user 131 in a very convenient and simple manner and with immediate deliveries: · Product information: metadata provided by the carrying retailers 120 or POS 122.

• Product availability: real-time updated information provided from retailers 120 or POS 122.

• Delivery agent 151 availability: real-time updated information provided by devices 150.

• Payment details: Previously gathered information from the user 131.

· Delivery details: Previously gathered information from the user 131, or based upon previous user 131 behaviour or orders.

How all these factors become available to the central server 110 has been extensively described and exemplified above. In particular, personal user data, such as payment infor- mation, may be stored as a part of a personal, password-protected user profile by the central server 110. Example #5 - Simple purchase with immediate delivery

Precondition: User 131 has performed a prior purchase using the central server 110 and agent(s) 151.

• The user 131 visits the aggregated store front as described above, using the GUI on device 130.

• The user 131 locates the wanted product.

· The central server 110 / GUI on device 130 presents the product description and a button labelled "Get it now".

• The user 131 selects the "Get it now"-button in the GUI.

• The central server / GUI prompts the user 131 to identify him- or herself, whereupon the user 131 enters her credentials, such as a user name - password combination. Alterna- tively, the user 131 is already identified as the owner of the device 130, which identification may be performed by the software application providing the said GUI on the device 130, for instance using a login when the user 131 installs or initiates the execution of the said software application. This possession of the device 130 by the user 131 corresponds to a something-you-have authentication factor.

· The central server 110 automatically determines the desired delivery location based upon available information, as described above, and a payment method is automatically identified based upon the identified user 131. One of several available payment methods may be automatically selected, for instance based upon total payment amount. The central server 110 also determines the optimal route and calculates the expected time of delivery, as described above.

• The central server 110 provides the expected delivery time to the user 131, which is presented in said GUI and possibly updated in real-time during the execution of the delivery by the agent(s) 151, based on delivery agent 151 position and velocity.

• The user 131 may also select a different desired delivery location within a particular ini- tial time period, such as within 120 seconds of placing the order, upon which an order update is performed and the optimal delivery route is redetermined as described above. • The central server 110 dispatches the order to the selected POS 122 and the set of selected delivery agents 151.

Specifically regarding covering relatively long distance deliveries in an urban area, this may become a challenge as both travel and transit times increase, as well as the delivery time variance as a result of delays.

This is particularly true if multiple pickups have to be performed along the optimal route.

Hence, if the central server 110 determines that, according to predetermined parameter criteria, the cost of doing multi-pickup becomes too large, in other words that the resulting expected delivery time becomes longer than the above-described maximum delivery time, the delivery is preferably automatically partitioned between multiple delivery agents 151, and hence split up into multiple sub delivery routes.

The algorithm for selecting the delivery agent 151 preferably takes this into consideration, for deliveries spanning over further distances, by ranking delivery agents 151 that are currently located geographically close to at least one of the current pickup POS 122 locations, as well as having access to high-speed transportation (such as a car), higher than what is the case for deliveries only spanning shorter distances. In addition to this, possibilities to match a planned return delivery, for such cases, lead to relatively higher ranking of such agents 151. For instance, a particular agent 151 may be able to perform returns from a particular suburban area back to the city centre, in which case such agents 151 are ranked higher than other agents 151 for deliveries from the city centre to such suburbs. Information forming the basis of such ranking may, for instance, be residence address of individual agents 151 or given planned trajectories of such individual agents 151 in the near future. Also, recency of last delivery is used as a ranking parameter to emphasize this. Such considerations will typically decrease the occurrence of long distance one-way journeys for the delivery agents 151, which over time may cause dissatisfaction with the agents 151 and decreased efficiency. Figure 4a illustrates a state of the above-discussed interactive GUI on the display of the user 131 device 130 before a purchase of the present type. The user 131 has logged in to the central server 110, via the device 130, and the device 130 has read (via a GPS sensor) and reported to the central server 110 the current location ("Storgatan 1") of the device 130, and hence also the user 131. The user 131 has previously provided payment details, in particular the necessary details regarding a particular credit card ("Visa **** **** **** 1234") to be used when purchasing products using the system 100. The user 131 has furthermore configured his account so that delivery is to be provided with the present location of the user 131. By pressing "Change user details", these details, and others, can be modified. By pressing "Logout", the user logs out from the service. The central server 110 has received product availability information from connected POS 120, and also available agent 151 lo- cation(s). Products (flowers, a tie and a sundae, respectively) that are all available from POS 120 in sufficient proximity to both at least one available agent 151 and the desired delivery location ("Storgatan 1") are presented in the GUI, using product images and prices provided by the respective retailer 120 in question as described above. When the user 131 presses a button "Get it now", the corresponding product is ordered, using the data shown in the GUI.

In figure 4b, the user 131 has pressed the button "Get it now" below the sundae. The central server 110 has then provided the above discussed delivery information to both a selected agent 151 and a selected POS 120, which information has been acknowledged by both these parties. The central server 110 calculates the expected delivery time to 24 minutes, which is less than the predetermined maximum delivery time, which in this case and for the product type "sundaes" is set to 30 minutes. The GUI on the device 130 also optionally displays billing information. By pressing the "View delivery details" button, the user 131 may, for instance, view a map showing the current location of the agent 151. By pressing "Change delivery location", the desired delivery location can be changed, triggering a redetermination action by the central server 110, which in turn could result in a no-delivery, or at least a delivery delay, depending on POS 120 and agent 151 availability.

Figure 4c illustrates the state of the above-discussed interactive GUI on device 150 at the moment when the delivery assignment notification arrives to the corresponding agent 151. If the agent 151 does not press "Accept" within a predetermined time period (here exemplified by a period of maximum 30 seconds), the delivery assignment is not accepted by the agent 151 in question. This could result in another agent 151 performing the delivery, or a no-delivery situation. In the GUI, details regarding the delivery assignment are also disclosed, and by pressing the "View map" button, the agent 151 can see a map showing the optimal delivery route, as provided by the central server 110.

In figure 4d, the delivery agent 151 has pressed "Accept", and the delivery assignment is ongoing. By pressing "View map", the agent 151 can see the current progress along the optimal delivery route in a map. If there is a problem, such as public transport unavailability, the button "Report problem" can be pressed. If the agent 151 needs to abort the assignment, the "Abort" button can be pressed. Both of these actions will typically trigger a central server 110 redetermination of the optimal delivery route.

Above, preferred embodiments have been described. However, it is apparent to the skilled person that many modifications can be made to the disclosed embodiments without departing from the basic idea of the invention.

For instance, in figure 1 a particular type of retailer 120 product management system is shown, for illustrative purposes. It is realized that other setups are also possible, providing the same basic functionality which the central server 110 relies upon as described above.

In general, all described exemplifying embodiments are freely combinable, as applicable.

Hence, the invention is not limited to the described embodiments, but can be varied within the scope of the enclosed claims.

Claims

C L A I M S

1. Method for performing a purchase of a physical product from at least one physical point of sale (120) offering the product for direct on-site purchase, which method comprises the steps

a) a central server (110) electronically being provided information regarding a purchasing user (131), in particular a desired delivery location;

b) the central server (110) electronically being provided inventory information regarding present updated physical availability of the product in question from a plurality of physical points of sale (120);

c) the central server (110) electronically being provided, from mobile electronic devices

(150) associated with respective available mobile delivery agents (151), location information regarding present respective geographic locations for a plurality of such available mobile delivery agents (151);

d) the central server (110) determining an optimal physical product delivery route, involving at least one selected delivery agent (151), at least a selected one of said points of sale (120), as well as said delivery location, based upon the said inventory and location information, and calculating an expected delivery time for the optimal route to the delivery location;

e) the central server (110) determining whether the said expected delivery time is longer than a predetermined maximum delivery time, and, in case it is not longer, the central server (110) automatically causing, via electronic communication, the user (131) to be presented with an option to purchase the product without having to specify a desired delivery location or a desired delivery time;

f) the user (131) accepting the said option, the central server (110) electronically receiving said accept and electronically sending reservation information to the said selected point of sale (120), as well as delivery information to the said selected delivery agent

(151) .

2. Method according to claim 1, wherein the product is offered for sale, in addition to direct on-site purchase and purchase with delivery via said mobile delivery agents (151), also via an e-commerce web site with conventional surface mail delivery.

3. Method according to claim 1 or 2, wherein both the central server (110) and the respective physical points of sale (120) keep inventory information regarding product availability at the respective physical points of sale (120).

4. Method according to claim 3, wherein the central server (110) inventory information is a mirror of the information kept by the respective physical points of sale (120).

5. Method according to claim 4, wherein the central server (110) queries at least one respective physical point of sale (120) in connection to determining the said optimal delivery route.

6. Method according to any one of the preceding claims, wherein the central server (110) receives, from the respective physical points of sale (120), information regarding future availability of the product for pickup at the respective physical point of sale (120), and in that this information is used when determining the said optimal delivery route.

7. Method according to any one of the preceding claims, wherein the optimal delivery route is calculated based upon a forecast, as calculated or received by the central server (110), of at least one future value selected from the group consisting of physical point of sale (120) opening hours and/or staffing; expected local traffic situation; expected geographic delivery agent (151) availability and/or trajectory; aggregated supply of the product; and aggregated demand for the product.

8. Method according to any one of the preceding claims, wherein the central server (110) calculates a present and/or expected future aggregated supply of the product and an aggregated present and/or expected future demand for the product, based upon information received from the said physical points of sale (120), and wherein the central server (110) dynamically offsets inventory information and/or a predetermined time during which the product is reserved at the selected physical point of sale (120), based upon the calculated aggregate supply and demand before determining the said optimal delivery route.

9. Method according to claim 8, wherein the said information received from the respec- tive physical points of sale (120) comprises information regarding sales via at least one other channel than via the central server (110), such as via an e-commerce web site with conventional surface mail delivery.

10. Method according to any one of the preceding claims, wherein the user (131) inter- acts with the central server (110) using a portable electronic user device (130), and wherein the desired delivery location is automatically selected based upon the current location of the user (130), which is detected by and communicated to the central server (110) from the user device (130).

11. Method according to any one of claims 1-9, wherein the central server (110) keeps information regarding at least one geographical location frequented by the user (131), and/or at least one previously used delivery location for the user (131), and wherein the central server (110) allows the user (131) to select the desired delivery location based upon said information.

12. Method according to any one of the preceding claims, wherein the central server (110) determines the optimal delivery route as a route comprising two sub routes, which are or may be performed in parallel by different delivery agents (151), in case a determined optimal delivery route involving only one delivery agent (151) is expected to result in a total delivery time which exceeds a certain threshold.

13. Method according to any one of the preceding claims, wherein the determination of an optimal delivery route involving at least two physical points of sale (120) comprises the sub steps of calculating a first optimal delivery route; selecting a particular one of said plu- rality of delivery agents (151) based upon proximity of the delivery agent (151) in question to the first route; calculating a second optimal delivery route based upon location information regarding the selected delivery agent (151); and using the second optimal delivery route as the determined optimal delivery route.

14. Method according to any one of the preceding claims, wherein the optimal delivery route is further determined based upon the type of the product, whereby different such types are associated with different thresholds regarding delivery durations.

15. Method according to claim 14, wherein the delivery comprises at least two products of different product types, and in that the optimal delivery route is determined further based upon different delivery duration thresholds associated with said different product types.

16. Method according to any one of the preceding claims, wherein the central server (110) determines the optimal delivery route, and in particular what delivery agent (151) or delivery agents that are to participate in the delivery of the product, based further on a future planned trajectory and/or a historic trajectory of individual delivery agents (151).

17. Method according to claim 16, wherein at least one of said plurality of delivery agents (151) is associated with a portable electronic device (150), which presents a graphical user interface via which the delivery agent (151) can provide information regarding a future planned trajectory and/or availability.

18. Method according to any one of the preceding claims, wherein a total aggregated supply is presented to the user (131) in one single interface view, such as on a screen display of a portable electronic device (130) of the user (131), not disclosing at what physical point of sale (120) each respective product is available, and with an estimated delivery time specified for each product type rather than for each individual product.

19. Method according to claim 18, wherein the user (131) does not specify the physical point of sale (120) from which the product is to be delivered.

20. Method according to any one of the preceding claims, wherein the reservation of the product is valid for a specific time period, which time period is determined by the central server (110) based upon the determined optimal delivery route, and if the product is not picked up from the physical point of sale (120) within the said time period it automatically becomes available for purchase by other users.

21. Method according to any one of the preceding claims, wherein the central server (110), during the delivery of the product, provides an updated expected delivery time to the user (131) via a graphical user interface provided on a screen display of a portable electronic device (130) of the user (131).

22. Method according to any one of the preceding claims, wherein the user (131), during the delivery of the product and via a graphical user interface provided on a screen display of a portable electronic device (130) of the user (131), is provided the choice of modifying the determined optimal delivery route, which optimal delivery route is then redetermined by the central server (110) in reaction to the modification.

23. Method according to claim 22, wherein such a modification comprises what physical point of sale (120) to pick up the product from.

24. System (100) for performing a purchase of a physical product from at least one physical point of sale (120) offering the product for direct on-site purchase, which system (100) comprises a central server (110) arranged to electronically be provided information regarding a purchasing user (131), in particular a desired delivery location, which central server (110) is further arranged to electronically be provided inventory information regarding present updated physical availability of the product in question from a plurality of physical points of sale (120), which central server (110) is further arranged to electronically be provided, from mobile electronic devices (150) associated with respective available mobile delivery agents (151), location information regarding present respective geographic locations for a plurality of such available mobile delivery agents (151), which central server (110) is further arranged to determine an optimal physical product delivery route, involving at least one selected delivery agent (151), at least a selected one of said points of sale (120), as well as said delivery location, based upon the said inventory and location information, and to calculate an expected delivery time for the optimal route to the delivery location, which central server (110) is further arranged to determine whether the said expected delivery time is longer than a predetermined maximum delivery time and, in case it is not longer, automatically cause, via electronic communication, the user (131) to be presented with an option to purchase the product without having to specify a desired delivery location or a desired delivery time, which central server (110) is further arranged to electronically receive an accept from the user and, if the user (131) accepts the said option, electronically send reservation information to the said selected point of sale (120), as well as delivery information to the said selected delivery agent (151).