WO2017197468A1

WO2017197468A1 - A method and system for facilitating the delivery of goods

Info

Publication number: WO2017197468A1
Application number: PCT/AU2017/050478
Authority: WO
Inventors: Kevin William Dinn
Original assignee: R K Urban Apps Pty Ltd
Priority date: 2016-05-20
Filing date: 2017-05-22
Publication date: 2017-11-23

Abstract

The invention relates to a method and system for facilitating the delivery of goods to a customer. Client devices, which may be mobile devices such as smart phones, are able to provide information on the location of a goods pick up location, and the cost and identification of the goods. The system delivers this information to one or more "runners" and selects a "runner" to attend at the location, pick up the goods and deliver them to the client at the client's delivery location. A runner selection engine is configured to identify the delivery runner and determine a delivery fee for the identified runner in dependence on data received form the client and from the runner. The runner selection engine is arranged to perform data analytics to determine travel time between a location of the delivery runner and collection location for the pick-up of goods, and also to determine cost.

Description

A METHOD AND SYSTEM FOR FACILITATING THE DELIVERY OF

GOODS

TECHNICAL FIELD This disclosure relates to a method and system for facilitating the delivery of goods to a customer. The method and system are able to obtain and utilise data from multiple sources and process the data to enable a delivery runner to obtain and deliver selected goods to the customer.

BACKGROUND ART

Traditional delivery services involve courier companies that facilitate the pick-up of goods from a vendor and delivery of those goods to a customer. Courier companies are often slow, selective in the type of goods they will deliver, use only employees or contractors for the company and co-ordinate the delivery of goods themselves. This can lead to the delivery service being expensive and the customers being unsatisfied with the service.

It is to be understood that, if any prior art is referred to herein, such reference does not constitute an admission that the prior art forms a part of the common general knowledge in the art, in Australia or any other country.

SUMMARY

Disclosed herein is a purchase and delivery of goods interface system implemented using computer processing and memory resources accessible via a data network. The system may comprise at least one client interface configured to receive client data relating to at least one delivery location and at least one goods selection retrieved from a client, a plurality of runner interfaces, each runner interface being configured to receive runner data relating to a location of a delivery runner, and a runner selection engine configured to identify a delivery runner and determine a delivery fee for the identified runner in dependence on the client data and runner data. In at least one embodiment, the plurality of runner interfaces may be each configured to receive a delivery offer from the runner selection engine, the delivery offer relating to the client data and the established delivery fee, and the at least one client interface is configured to receive the determined delivery fee from the runner selection engine for review and selection by the client. In at least one embodiment, the runner selection engine comprises a time determination module configured to receive the client data and the runner data, and perform data analytics to determine a travel time between the location of one of the plurality of delivery runners, a collection location for the selected goods and the delivery location. In at least one embodiment, the time determination module may be configured to identify a plurality of optimised travel routes, each optimised travel route being between the location of one of the plurality of delivery runners, the collection location for the selected goods and the delivery location.

In at least one embodiment, the runner selection engine may further comprise a delivery fee module, the delivery fee module being configured to determine the delivery fee in dependence on the plurality of optimised travel routes.

In at least one embodiment, the runner selection engine may further comprise a client and runner interaction module configured to communicate delivery and order information between the at least one client interface and at least one of the plurality of runner interfaces in dependence on the delivery fee, the client data and the runner data. In at least one embodiment, the system may further comprise a data type module configured to analyse the client data and runner data to characterise the data as being of a variable or fixed data type.

In at least one embodiment, the system may further comprise a location selection module, wherein the location selection module is configured to retrieve the characterised data from the data type module and select at least one collection location in dependence on the characterised data.

In at least one embodiment, the system may further comprise a multi- delivery module configured to retrieve runner data, access a mapping database, calculate a delivery delay and approve multi-deliveries for identified delivery runners in dependence on the calculated delivery delay.

In at least one embodiment, the system may further comprise a purchase module configured to securely facilitate purchase of the goods by the identified delivery runner. In at least one embodiment, the purchase module is configured to determine a purchasing code and communicate the purchasing code to the runner interface of the identified runner to facilitate purchase of the selected goods.

Also disclosed herein is a method of facilitating the delivery of goods. The method may comprise the steps of: accessing one or more data sources to obtain client input data and runner input data, the client input data relating to at least one delivery location and at least one goods selection, and the runner input data relating to a location of a plurality of delivery runners, processing the client input data and runner input data, the processing comprising, analysing the client input data with the runner input data to identify at least one of the plurality delivery runners, and establishing a delivery fee for the identified runner to facilitate the delivery of the at least one goods selection. In at least one embodiment, the method may further comprise outputting instructions to the identified delivery runner to facilitate the purchase and delivery of the at least one goods selection.

In at least one embodiment, the method may further comprise determining a travel time between the location of one of the plurality of delivery runners, a collection location for the selected goods and the delivery location.

In at least one embodiment, the method may further comprise identifying a plurality of optimised travel routes, each optimised travel route being between the location of one of the plurality of delivery runners, the collection location for the selected goods and the delivery location.

In at least one embodiment, the method may further comprise establishing the delivery fee in dependence on the plurality of optimised travel routes.

In at least one embodiment, the method may further comprise analysing the client input data and runner input data to characterise the data as being of a variable or fixed data type .

In at least one embodiment, the method may further comprise selecting at least one collection location in dependence on the characterised data.

In at least one embodiment, the method may further comprise calculating a delivery delay in dependence on the client input data and runner input data to facilitate an approval process of multi-deliveries for identified delivery runners.

In at least one embodiment, the method may further comprise determining a purchasing code and communicating the purchasing code to the identified runner to facilitate purchase of the selected goods.

Also disclosed herein is a method for arranging a delivery service, the method being implemented using computer processing and memory resources accessible via a data network. The method may comprise the steps of retrieving, at a client processing device, a request for the delivery service, the request including at least one delivery location data point and at least one goods selection, selecting a delivery runner to perform the delivery service in dependence on the retrieved request, and transmitting, to a delivery runner processing device, the at least one delivery location data point and the at least one goods selection. Also disclosed herein is a device for facilitating the purchase and delivery of goods, comprising a processor, memory and an operating system for supporting computer processes, and a client interface process generating a client interface arranged to receive client data relating to at least one delivery location and at least one goods selection, the device being for use with the system discussed above.

In an embodiment the device may be a portable hand held device, such as a tablet or smartphone. In an embodiment, programming may be provided in the form of a software application supported on the device. In an alternative embodiment, the client interface may be implemented by a remote computing system, providing the client interface to the device over the internet. It may be in the form of a "web app" for example.

Also disclosed herein is a device for facilitating purchase and delivery of goods, comprising a processor, a memory and an operating system for supporting computer processes, a runner interface process for generating a runner interface, each runner interface being configured to receive runner data relating to a location of a delivery runner, the device being for use with the system discussed above.

In an embodiment, the device may be a portable hand held device, such as a tablet or smart phone. In an embodiment, the runner process may be in the form of a software application supported by the device. In an alternative embodiment, the runner interface may be provided to the device from a remote system. It may be in the form of a "web app" for example.

Also disclosed herein is a computer program, comprising instructions to control a computer to implement a system as discussed above or devices as discussed above. Also disclosed is computer readable medium, providing a computer program as discussed above.

Also disclosed is a data signal, comprising a computer program as discussed above.

BRIEF DESCRIPTION OF THE DRAWINGS

Embodiments will now be described by way of example only, with reference to the accompanying drawings in which

Fig. 1 illustrates a delivery of goods interface system in accordance with one embodiment of the present invention;

Fig. 2 is an example block diagram of a computing system which may be utilised in implementation of an embodiment of the present invention;

Fig. 3 illustrates a block diagram of a runner selection engine in accordance with one embodiment of the present invention; Fig. 4 is an illustration of a map showing the location of multiple runners, collection points and a single delivery point;

Fig. 5 is an illustration of the map of Fig. 4, including routes between the runners, collection points and delivery point;

Fig. 6 illustrates a block diagram of a vendor selection modulein accordance with one embodiment of the present invention;

Fig. 7 illustrates a block diagram of a multi -delivery module in accordance with one embodiment of the present invention;

Fig. 8 is another illustration of a map showing the location of multiple runners, collection points and delivery points; Fig. 9 shows the map of Fig. 8, including an optimised root for one of the runners;

Fig. 10 shows the map of Fig. 8, including another optimised root for one of the runners; Fig. 11 shows the map of Fig. 8, including another optimised root for one of the runners to perform a multi -delivery; and

Fig. 12 illustrates a block diagram of a purchasing module in accordance with one embodiment of the present invention; DETAILED DESCRIPTION

In the following detailed description, reference is made to accompanying drawings which form a part of the detailed description. The illustrative embodiments described in the detailed description, depicted in the drawings and defined in the claims, are not intended to be limiting. Other embodiments may be utilised and other changes may be made without departing from the spirit or scope of the subject matter presented. It will be readily understood that the aspects of the present disclosure, as generally described herein and illustrated in the drawings can be arranged, substituted, combined, separated and designed in a wide variety of different configurations, all of which are contemplated in this disclosure.

There is a trend towards replacing services that were traditionally provided by businesses, to services being provided by individuals with the necessary resources and skills directly to the client. This mode of operation of a business is sometimes referred to as being part of the "sharing economy". The disintermediation of the traditional business can be achieved through an online service ("the service") which is accessed through an application (referred to as "the app") run on a fixed (e.g. PC, TV, etc.) or mobile (smartphone, tablet, etc.) processing device and/or a web site that accesses the same background infrastructure.

An app can provide a direct connection between the supply side (the individuals with the resources and/or the skills needed) and the demand side (the clients requiring the service). This allows the two parties to be matched to resolve the client's issue in a simple and efficient manner. An app may also provide the facility to bill for the provision of the service.

Disclosed herein is a system and method that facilitates a shared economy style of delivery service. Referring firstly to Fig. 1, a delivery of goods interface system 100 implemented using computer processing 102 and memory 104 resources accessible by client systems 106 via a data network 108 is shown. The system includes at least one client interface, in the form of a client processing device 1 10 (e.g. a PC, tablet, smartphone etc.) that enables the client (e.g. a purchasing customer such as an individual or business) to access the network 108. Each client interface 1 10 is configured to receive client data 1 1 1. The client data 1 11 may be in the form of a goods selection (e.g. a purchase, such as an item of clothing) and a delivery location (e.g. a street address). In one form, a customer is able to input client data into the client processing device 1 10 (e.g. by entering information into a website or app). The input client data may be transferred to the system memory 104 and reviewed by a data type engine to determine if the data is of a fixed or variable type. For example, if a customer specifies a goods type (e.g. a coffee), a specific pick-up location (e.g. a coffee shop) and a delivery location (e.g. a street address), the data type engine may characterise this data as fixed data. However, if a client does not provide a specific pick-up location, the data type engine may set the missing data type as variable data. This will be described in more detail in relation to Fig. 7.

The system also includes a plurality of runner interfaces, in the form of runner processing devices 1 12. In the detailed embodiments, the runner processing devices 1 12 are in the form of mobile processing devices, such as a personal tablet or smartphone, that includes an internet connection and GPS capability. Importantly, each runner processing device 1 12 is configured to receive runner data 1 13. The runner data 1 13 includes the location of a delivery runner 1 16. As such, the system is able to monitor the location of each delivery runner by receiving data from each runner processing device 112 that is connected to the network 108.

The system includes a runner selection engine 114 that is configured to analyse the client data 1 1 1 and runner data 1 13 in order to both identify delivery runners and establish a delivery fee for the identified runners. The disclosed system thereby allows for delivery runners to maximise their earnings for a certain amount of effort and/or time, minimise the time and complexity of the delivery experience for the purchasing customer and minimise the amount of information required to be conveyed between the delivery runner, purchasing customer and vendor to ensure the correct items are collected and delivered. The purchasing client (e.g. an individual customer, business, etc.) is able to use their processing device 1 10 to access the system 100 and specify what they want to purchase (e.g. the product / goods) and the delivery location. In at least one embodiment, the client can also specify where they want the goods to be collected from (e.g. a specific vendor). In some forms, the client can also specify a collection time. The delivery runner (e.g. person, automated vehicle, etc.) is also able to access the system via an app on their personal processing device 1 12 and be provided with real time information 1 17 about available delivery tasks. In another form, the delivery runner may be in the form of an automated vehicle. The system is able to provide sufficient information for the runner to assess the task for such things as the type of items to collect, the time it will take, the locations for pick-up and delivery and their potential earnings. With this information, delivery runners can decide whether they will perform the delivery.

If the runner decides to accept the delivery, the system can provide real time information for some / all parties (i.e. the client, runner and vendor) to track the progress of the delivery as well as optionally communicate to clarify any issues that may be encountered throughout the purchase and delivery process.

Fig.2 is an example block diagram of a generic computing system which may be utilised in implementation of the present invention. For example, it may be utilised in the embodiment of Figure 1. The illustrated computing system comprises a computer 201 which includes a processor 202 and memory 203. The processor 202 is arranged to process programme instructions and data in a known manner. Memory 203 is arranged to store programme instructions and data also in a known manner. Processor 202 may constitute one or more processing means, such as integrated circuit processors. The memory 203 may comprise any known memory architecture and may include hard disk, IC memory (ROM, PROM, RAM, etc.), floppy disks and other types of additional memory such as CD ROM, and any other type of memory.

A BUS 204 is provided for communication between the processor 202 and memory 203 and also communication with external components. In this case the external components include a user interface 205. The user interface 205 includes a visual display unit 206 for displaying information to a user. The VDU 206 may display information in graphical format or any other format depending upon the programme instructions being processed by processor 202.

The user interface 205 also includes user input means 207 which in this example include a keyboard 208 (which in this example may be a standard QWERTY keyboard) and a mouse 209. The mouse 209 may be used to manipulate a graphical user interface (GUI) if a GUI is provided by software running on the computer. A network connection 210 is also provided for connecting to a network which may include a communication network 210 and other computers/computing systems.

The computing system of Fig. 2 may be implemented by any known type of computing hardware such as, for example, a PC, by a number of networked PCs if required to implement a system of this embodiment, by a "mainframe architecture" including a remote computer and user workstations connected to the remote computer, by a client-server architecture, including a client computer accessing a server computer over a network, or by any other computing architecture. Parts of the system or the entirety of the system may be housed in the

"cloud". This embodiment of the present invention is implemented by appropriate software providing instructions for operation of the computing system hardware to implement the apparatus of the embodiment and implement the method of the embodiment. Part of the system or the entire computer system may be portable, and may be implemented, for example, by a laptop or tablet computer, smartphone or other portable device.

The computing system is provided with an operating system and various computer processes to implement functionality. The computer processes may be implemented as separate modules, which may share common foundations such as routines and sub-routines. The computer processes may be implemented in any suitable way and are not limited to separate modules. Any software/hardware architecture that implements the functionality may be utilised. The computing system may be implemented as a server computing system, or utilising computer resources in the cloud, or any other computer resources. In this embodiment, the host system (e.g. 102 in Fig. 1) is implemented utilising cloud resources.

The runner selection engine 114 will now be described in further detail with respect to Figs 3 to 6. As shown in Fig. 3, the runner selection engine 1 14 includes a spatial search module 1 18, a time determination module 120, a delivery fee module 122 and a runner & client interaction module 124. Referring now to Fig. 3, the spatial search module 1 18 will be described in further detail.

Fig. 4 details a scenario where the client has input two goods selections from two different collection locations (i.e. two specific vendors) into their personal processing device 110. For example, this order may include a coffee from a specific cafe ("Collection 1" 128) and a bottle of milk from a specific grocery shop ("Collection 2" 130). The spatial search module 1 18 is configured to determine the number of runners that are located within a close proximity of the two collection points and the set delivery point 132. The spatial search module 1 18 initially calculates a region 126 (x,y) that bounds the two collection points 128, 130 and the delivery point 130. Following this, the centre point of this region 126 is determined and a spatial search is performed to determine the nearest available runners to the centre point of the region. As will be evident to the skilled addressee, there are a number of methods to perform the step of determining the nearest available runner. One method is to set a radius (e.g. 3 kilometres) for a runner region 135 that surrounds the collection / delivery point region 126. Runners located within this region can then be identified (e.g. in Fig. 3, runners 134, 136 & 138 are located within region 135 and runners 140, 142 & 144 are located outside the region 134). In another embodiment, a pre-determined number of 'nearby runners' (e.g. "3 nearby runners") is set and the spatial module compares the locations (e.g. GPS co-ordinates of each active runners processing device 1 12) of all the runners connected to the system to the collection points and delivery points to identify nearby runners.

Referring now to Fig. 5, the time module 120 will be described in further detail. The time module 120 is configured to calculate an estimate delivery time for each of the runners 134, 136 & 138 identified by the spatial search module 120. In order to calculate the time estimate for the pick-up and delivery of the items at collections points 128, 130 and delivery to 132, the time module carries out the following steps. For each of the nearby identified runners 134, 136, 138, the duration of the trip for each runner is calculated from their current location through each permutation of the collection locations 128, 130 to the delivery location 132. As will be evident to the skilled addressee, there are a number of ways in which this step can be performed and will depend on many variables. In the simplest form, the timer module 120 calculates the minimum distance that each runner is required to travel to both collection points 128, 130 and the delivery location 132 from their current position. The timer module may then applies a weighted time factor for the total distance travelled (for example, 10 minutes per kilometre travelled) to determine the total time required for each runner. In another form, the system 100 is able to access an online mapping service such as google maps (see Fig. 1, 134) to estimate the travel time for each runner. This step can be iterative for each pickup and delivery permutation for each runner (i.e. the timer module inputs each permutation into the mapping service and then selects the minimum required time to perform the pickup and delivery for each of the identified runners 134, 136, 138). In another form, the system can also receive an input from each runner as to their individual mode of transport and then run similar permutations using an online mapping service to compare the time requirements of each runner. For example, runner 134 may select that their individual mode of transport for time calculation purposes be an automobile, whereas runner 136 may select that their individual mode of transport for time calculation purposes as bicycle. This may then impact the travel time for each runner. If a mapping service is used by the timer module, the minimum time required and route determined for each identified runner may selectively be saved to the database (see Fig. 1, 104) for use by the runner & client interaction module 124.

The timer module may also be configured to determine likely delays for each collection 128, 130 and delivery point 132. In a simple form, the timer module can apply a predetermined time factor to each activity. For example, the system may apply a "time per location" and "time per item" factor to each activity. These values can be pre-set (e.g. "time per collection location" = 5 minutes, "time per item collected at the collection location" = 0.5 minutes, "time per delivery location" = 5 minutes). In another form, the timer module is able to apply other factors such as "time of day", "day of week", "the particular location" (e.g. a particular shopping centre may have an unusual lack of parking facilities, thus adding to the time required at that location) and "the type of item being collected" (e.g. collecting coffees may take longer per item than collecting groceries). These factors can be stored on a system database (see Fig. 1, 104) and applied as required by the timer module to determine the total time required to perform the collections and delivery for each runner.

In the detailed form, the system is able to collect data over time (e.g. on the database 104) by tracking every delivery performed using the system. In this way, the timer module 120 can be configured to be dynamic, in that it is able to adapt over time in dependence on the stored data for each collection location, delivery location and specific runner such that it is able to more accurately calculate the required delivery time for each runner. The algorithm may include the following factors that can be weighted if required:

- the collection time history for the specified collection location at a particular time of day and day of week;

- the collection time history for the particular item, possibly both in the location specified as well as that item type in general; - the delivery time history for the specified delivery location at a particular time of day and day of week;

- the delivery time history for the particular item, possibly both in the location specified as well as that item type in general;

- the time history for each runner for any one of the collection locations, the delivery location and the specific item type (e.g. experienced runners in the system may be much faster at collecting particular items and navigating collection / delivery venues than less experienced runners).

In one form, the minimum time determined for each runner 134, 136, 138 is averaged and then that single time figure is transmitted to the delivery fee module 122. In another form, the minimum time determined for each runner 134, 136, 138 is transmitted to the delivery fee module 122. The delivery fee module 122 is configured to determine the delivery fee for either the averaged time value or for each identified runner in dependence on the time calculations performed by the timer module 120. In one form, the delivery fee module 122 may apply a $/time factor to the collection / delivery times determined by the timer module 120 to establish a delivery fee. In other form, the delivery fee module 122 may apply both a $/time factor and a transport cost factor, in dependence on the identified runners selected mode of transport (e.g. to take into account petrol costs, public transport costs, etc.). The delivery fee module is then able to output either of the following information types to the runner & client interaction module 124:- - single delivery fee in dependence on the averaged time calculated for each identified runner (i.e. the average delivery fee calculated for runners 134, 136, 138); or

- multiple delivery fees in dependence on the averaged time calculated for each identified runner (i.e. a delivery fee for runner 134, a delivery fee for runner 136 and a delivery fee for runner 138).

The runner & client interaction module 124 (see Fig. 3) is configured to relay information between the client and the runner in dependence on the calculations performed by the delivery fee module 122. In the embodiment where a single averaged delivery fee is calculated by the delivery fee module 122, this fee can be communicated to runners 134, 136, 138 as a job offer. For example, an app run on the individual processing device of runner 134 would notify runner 134 of a delivery opportunity (e.g. provide the runner with the delivery point, collections points, goods selections & delivery fee). Runner 134 is then able to choose to "accept" or "reject" the offer by inputting information into the app run on their personal processing device. This information is then transmitted back to the runner & client interaction module 124 in real time. To accelerate the approval process, the offer may be sent to each identified runner at the same time for acceptance. When the runner & client interaction module 124 receives an "offer accepted" input from a runner, the runner & client interaction module 124 may send the delivery fee to the client to confirm acceptance (e.g. the app run on the client's mobile processing device may notify the client that a delivery offer has been accepted, along with the accepted delivery fee). Following client approval, final instructions may be communicated to the runner that accepted the offer to perform the delivery. In another embodiment, the runner & client interaction module 124 may send the calculated average delivery fee to the client for acceptance before communicating the offer to the identified runner. In the embodiment where a delivery fee is not averaged for each runner, runners may receive different offers (i.e. the delivery fee calculated for that specific runner). In another embodiment, the client may be shown a graphical display of the identified runners, along with their calculated delivery fee. This graphical display may be dynamic, in that the client can see the movements of the identified runners along with their constantly changing delivery fee. To assist the client, further information may be included for each runner (e.g. reviews of that runner) to assist the client to choose a particular runner. The graphical display can also include vendors for the specified purchase items such that the client is able to change their collection points and dynamically see the change in delivery fee (e.g. the client can choose a vendor that is close to an idle runner to reduce the delivery fee).

With delivery of items, it is possible that the client will opt not to specify one or more of the collection locations. For example, the client may identify items they want collected and those items are sufficiently generic to be available from multiple locations, for example simple consumer goods like milk from a grocery store. In this situation, the process of estimating the time and cost of a delivery may be more complex. In one embodiment, the runner selection engine can apply an approximation rather than an accurate estimate (e.g. a set time or distance to allow the delivery fee to be calculated). In another form, as initially described with reference to Fig. 1, the system may include a data type module (see Fig. 3, 142) to determine if the data is of a fixed or variable type. Where a client does not provide a specific pick-up location, the data type module may characterise the missing data type as variable data. Both the variable (e.g. the collection location) & fixed data (e.g. the delivery address and specified item) can then be sent to a location selection module(see Fig. 3, 140, also known as "vendor selection module")) before being sent to the runner selection engine 1 14.

The vendor selection module will now be described in further detail with reference to Figs. 3 & 7. In one embodiment, the vendor selection module 140 is able to select a vendor (i.e. collection location) in dependence on the variable and fixed data such that the system is able to direct a runner to a specific vendor. In this embodiment, the vendor selection module 142 can either be run before the runner selection engine 1 14 (see Fig. 3, arrow 144) or in conjunction with the runner selection engine 1 14 (see Fig. 3, arrow 146). At step 148, the vendor selection module 142 accesses either an internal database (see Fig. 1, memory 104) or external database (see Fig. 1, database 134) that details vendor options. At step 150, the identified vendor options are reduced to those that match the set delivery address. In one embodiment, the vendor selection module 142 identifies the nearest vendors (e.g. vendors that stock the category of the selected goods) to the delivery location. In this embodiment, the vendor selection module 142 may limit the number of vendors to less than the maximum ('η') if there are less than that number within a reasonable distance of the delivery location. By applying a similar method to that outlined previously for the time determination module, the vendor selection module 142 is configured to calculate the travel time of a hypothetical delivery via each one of the pick-up locations and then calculate the average travel times to determine a cost and time estimate for the client. At step 152, a specific vendor is selected. This is a useful step to perform if the vendor selection module 142 is run prior to identifying delivery runners (i.e. the vendor selection module 142 can select the closest vendor to the delivery address to reduce delivery time and cost).

When the vendor selection module 140 is run in conjunction with the runner selection engine (i.e. Fig. 3, arrow 146), the vendor selection module 142 is configured to select numerous vendor options that are within close proximity to each runner and the delivery address such that the travel time and delivery fee can be reduced. In one embodiment, the client and runner interaction module 124 is configured to allow clients to change the vendor location during the runner selection process (see Fig. 3, arrow 154). In this embodiment, the change of vendor by the client may then prompt the runner selection engine to again identify runners and establish a new delivery fee if required. In the detailed embodiments, the client and runner interaction module 124 can be configured to direct identified runners to a specific vendor selected by the vendor selection module 142. Additionally, the client and runner interaction module 124 can be configured to direct identified runners to follow an optimised route (e.g. that established by the time determination module 120) to advantageously provide the client with an accurate estimate of time and cost up front.

It is desirable for the system to allow a single runner to perform multiple deliveries on the same trip. The benefits of this may include greater earnings per hour for the runner and greater earnings per hour for the provider of the service due to the larger number of deliveries performed per hour. Also, in many situations, the client may have their delivery performed sooner than if each delivery is performed by runners sequentially one at a time. However, there are several possible undesirable consequences of this approach unless the allocation of multiple deliveries to runners is performed intelligently. For example, if the locations of the collection(s) and delivery of each of the simultaneous deliveries vary significantly, the time for one or both of the deliveries may end up being significantly more than if a runner had performed it in isolation. Also, if a single runner takes on many deliveries it may result in reducing the number of deliveries for other runners in the area who may be idle while a single runner performs many deliveries.

In order to avoid the issues above, in at least one embodiment, the system includes a multi-delivery module 156 (see Figs. 3 & 7) that is able to run in conjunction with the runner selection engine 114. In this embodiment, the spatial search module 1 18 identifies both 'idle' runners (i.e. runners that are not performing a delivery) and 'active' runners (i.e. runners that are performing a delivery). In this way, the delivery offer can be communicated to both active and idle delivery runners. When an active runner accepts an additional delivery job offer, the multi-delivery module initially performs the step of determining the workload 158 of the active runner. The workload can be established by checking that the active runner is not exceeding a pre-determined maximum number of simultaneous deliveries, and/or by checking that the runner is not exceeding a predetermined maximum number of deliveries that can performed per-time period (e.g. per hour). If the runner meets the pre-determined workload requirements, the multi -deli very module 156 then determines the delay associated with approving the delivery offer 160.

The multi-delivery module 156 operates in conjunction with the runner selection engine 1 14 to determine delays for both the 'new' client (i.e. the client that requests a delivery that is accepted by an active runner) and the 'existing' client (i.e. the client that has previously engaged the active runner). In at least one embodiment, the multi-delivery module 156 checks that the new delivery is "on the way" of the currently accepted delivery(s) for the active runner and hence will not result in a lengthy delay of the new or previously accepted deliveries. To determine the delay, the multi-delivery module 156 communicates the active runners location, new delivery location and new collection location to the runner selection engine such that the time determination module 120 is able to establish a revised estimate for the delivery time of previously accepted deliveries (i.e. the deliveries for the 'existing client') when the additional delivery location and collection point is included for the new client. The revised estimate is then processed at step 162 by the multi -delivery module to determine whether the calculated delay for the existing client exceeds a pre-determined maximum time or time percentage (referred to here as 'maximum additional time'). In one embodiment, if the calculated delay falls within the threshold maximum additional time, the multi-delivery module 156 may assign an 'approved' or 'denied' notification to the active runners request and send this information to the runner & client interaction module (see Fig. 3, 124) for further processing (i.e. to be transmitted to the active runner and/or client).

In another embodiment, the multi -delivery module 156 performs an additional step 164 to determine if 'idle' runners, or soon to be 'idle' runners (i.e. active runners that have almost completed a task) in the system could more efficiently perform the delivery. To perform this step, the multi -delivery module 156 consults the runner selection engine 114 to determine delivery time / fee estimates for identified 'idle' runners. This information is then communicated to the multi-delivery module to compare the idle and active runner delivery times such that the pre-determined 'maximum additional time' threshold can be varied. For example, if it is established that available idle runners are able to perform the new delivery more quickly and cheaply than if the active runner is approved to perform a multi-delivery, the predetermined thresholds initially applied by the multi -deli very module 156 can be reduced such that those limits are more restrictive. Alternatively, the predetermined thresholds initially applied by the multi -deli very module 156 may be increased and hence made less restrictive if there are few or no other available idle runners.

The multi -delivery module 156 may also apply a rating or priority aspect to runners. This may result in specific runners having the predetermined thresholds initially applied by the multi-delivery module 156 to be either less restrictive or more restrictive than normal. There aspects may include such things as:

- The longevity of service of the runner, (e.g. more experienced runners will have less restrictions); - The class of the runner (e.g. a professional courier may have less restrictions);

- The rating of the runner (e.g. a runner with a better history may have less restrictions); - Any other criteria that may reflect the runner's enhanced ability to perform multiple deliveries;

- Commercial factors such as a runner that accepts a lower rate of payment may have less restrictions

In dependence on the calculations performed by the multi-delivery module, active runners may be confirmed or rejected when they accept an additional delivery. An example of the use of the multi-delivery functionality will be detailed below in relation to Figs. 8 to 1 1. Fig. 8 shows a map with three identified runners 302, 304, 306, two delivery locations 312, 314 and a collection location 308, 310 for the respective delivery requests 312, 314. In this example, runner 302 accepts both delivery requests. The runner selection engine 1 14 determines the route, time and delivery fee for the first delivery request (i.e. the route from runner 302 location to the collection point 308 and then to the delivery point 312 - shown as route 316 in Fig. 9). The determined travel time for runner 302 to perform the first delivery request is 13.39 minutes. When the runner attempts to accept the second delivery request, the system initially calculates the time to perform the second delivery request (i.e. the route from runner 302 location to the collection point 310 and then to the delivery point 314 - shown as route 318 in Fig. 10). The determined travel time for runner 302 to perform the second delivery request is 10. 12 minutes. The system then determines the route, time and delivery fee for both requests if performed simultaneously. The combined route is shown as route 320 in Fig. 10. For this example, the table below shows the change in delivery time for each route:

Assuming that the system includes a predetermined delay threshold that a multi-delivery must not increase the delivery time for any client by 20% or more, the above two deliveries would be acceptable to be performed simultaneously. As such, the system would allow runner 302 to accept the second delivery request.

In at least one embodiment, the disclosed system includes purchasing capability to minimise out-of-pocket expenses for runners when items need purchasing. Deliveries may require purchase of an item by the runner on behalf of the client. In this situation, the runner has to carry out the purchase of the item but will have to be reimbursed for the purchase. The simplest method of supporting this is for the runner to purchase the goods from their own funds or on their own credit or debit card facility and the reimbursement be electronically transferred to the runner by the system. However, as it is often not possible to reimburse the amount to the runner's account immediately, the runner can accumulate a large outstanding credit which they have to cover from their own funds until the reimbursement is processed. If this amount exceeds their financial resources, it may limit the number or the nature of the deliveries that the runner can perform.

In at least one embodiment, it is possible for the items to be purchased directly from the funds of the service or the client. In this form, the transaction is carried out by the runner in-store and the funds do not come from the runner's personal account. In this form, the purchasing system: -

- Uses existing in-store infrastructure (i.e. does not require additional equipment or processes by the store for the purposes of the transactions);

- Is carried out electronically and does not require any distribution of physical items to the runner (e.g. does not require distribution of credit cards to the runners);

Is secure. Despite the fact that the runner is initiating a financial transaction on the behalf of clients, they are restricted to only be able to access the applicable funds for that transaction and no more. Many smartphones now have Near Field Communication (NFC) support which allows short range 2-way electronic communications with compatible devices. A common usage of this technology is "tap and go" payments where a compatible credit or debit card is pressed against a compatible payments terminal and the payment details are securely transmitted and processed. The NFC capability of the smartphone can be used for the same process whereby software in the smartphone emulates the signal that a credit/debit card would send and hence, to the payments terminal, the smartphone can be treated as a compatible card. In this way a payment can be made by just tapping the smartphone to the terminal. Current implementations of the above (e.g. ApplePay & GooglePay) require the smartphone user to provide details of their own card(s) with authentication to ensure that they do indeed own that card. From that point on the smartphone can emulate payments for that card.

For the purposes of the disclosed delivery system, the usage of the tap payments for the runner of the service is not a sufficient option as it still requires the funds to come out of the runner's personal financial resources.

Disclosed herein is a payment system whereby additional capability is built into the delivery system such that it uses the same software techniques of the traditional tap and go services (i.e. where a smartphone is configured to emulate a credit card tap and go payment), but instead of presenting the credentials of the runner's credit/debit card, the payment system is configured to present the credentials of a designated account of the service. Thus a runner's payment to a vendor is transferred directly from the account of the delivery service (i.e. not from the runner's personal funds). In another form, the payment system may take the form of a dynamically topped up gift card. There are many gift cards or store cards which can be used like cash in store to make purchases. These generally identify themselves with a code which is scanned at the point of sale (POS). This is then looked up in the back end POS system to confirm the balance remaining and if it is sufficient then the purchase is completed. The amount is then deducted from the remaining balance of the card. This type of card could be used to carry out payments for item purchases by the runner to avoid the funds having to be withdrawn from their personal funds. A gift card does not have to be a physical card, the essence of the right to use the funds of the card is possession of the unique code for the card. This code is generally conveyed through a bar-code image that the POS terminal scans to read. In the disclosed payment system, the code may not be presented via a physical card. Instead, the code is presented on the display of the runner's personal processing device (e.g. smartphone screen). Thus a display of the gift card's bar-code on the display of a smartphone is sufficient to allow the purchase to be funded and completed. This bar code is linked to a gift card balance that is dynamically topped up at the time of purchase.

The payment system is in the form of a payment module 400 (see Fig. 12) that is processed by the system during collection of the goods by the runner. The payment system is configured to receive input data 402 from the runner. For example, the runner may either manually enter the cost of each item into the payment module via their smartphone display, or take a photo / scan the price tag which is then processed by the payment module to determine the item price. Once the last item is collected (or the last item is scanned), the pricing module 400 prepares a gift card 404 with the required amount necessary to pay for the items. At step 406, the payment module transmits the barcode to the screen of the smartphone. Presentation of this barcode allows for the runner to purchase the goods (e.g. the POS operator may scan the code on screen of the runner's smartphone). The POS system 408 then confirms that the gift card funds are sufficient to complete the purchase and if so allow the purchase to be finalised. Alternatively the runner may be supplied with a physical card with a bar code, magnetic stripe or the like to identify it to the POS system. This would be instead of presenting a bar code on the screen of a runner's personal smartphone. In all other ways the logic would be the same as set out above. For the disclosed payment systems, the runner is provided with funds of the service to facilitate the purchase of goods. Thus, it may be possible for runners to conduct fraudulent purchases outside of the scope of paying for the items for a valid delivery. Thus the payment system may be limited to only being available to the runner for genuine purchases relating to a delivery. The following measures can be put in place to ensure that purchases are not fraudulent. Initially, the runner may be able to activate the payment module on the smartphone through the app at the point of the payment processing in the app (e.g. at the time of purchase of the goods). At that point the payment module can ensure the security of the transaction through the following mechanisms:

Confirm that the runner is in the process of a delivery and at the physical location where a payment is being made if the collection location was specified by the client (i.e. the runner has arrived at a specified collection location);

- If the collection location was not specified by the client or the system, confirm that the runner is physically be at a compatible collection location (this can be confirmed through the smartphone's GPS system and the systems database of locations); and

Confirm that the amount being paid match the cost of the items collected, or if this information is not known, it should still be within the realms of expected cost for the type of items being collected (i.e. consult the system database and confirm that the items are within a pre-determined percentage of the expected item cost).

If any of the criteria above are not met, the transaction may be blocked with possibly a validation phase where the runner is asked to confirm the need for the transaction and the amount involved before the transaction is allowed to proceed.

In the above embodiments the client and runner interfaces may be implemented as applications on mobile runner and client devices (eg Smartphones, Tablets etc). The invention is not limited to this. In embodiments, the client and runner interfaces may be generated as web applications for remote access by runner and client devices. The architectures may be implemented, such as server/client, or main frame and terminal, to implement the functionality described. The runner and client devices could be any device. For example, client devices could be PCs and are not limited to mobile devices.

In the claims which follow and in the preceding description of the invention, except where the context requires otherwise due to express language or necessary implication, the word "comprise" or variations such as "comprises" or "comprising" is used in an inclusive sense, i.e. to specify the presence of the stated features but not to preclude the presence or addition of further features in various embodiments of the invention.

Claims

1. A purchase and delivery of goods interface system implemented using computer processing and memory resources accessible via a data network, the system comprising:

at least one client interface configured to receive client data relating to at least one delivery location and at least one goods selection retrieved from a client; a plurality of runner interfaces, each runner interface being configured to receive runner data relating to a location of a delivery runner; and

a runner selection engine configured to identify a delivery runner and determine a delivery fee for the identified runner in dependence on the client data and runner data.

2. The system of claim 1 wherein

the plurality of runner interfaces are each configured to receive a delivery offer from the runner selection engine, the delivery offer relating to the client data and the established delivery fee; and

the at least one client interface is configured to receive the determined delivery fee from the runner selection engine for review and selection by the client.

3. The system of claim 1 or 2, wherein the runner selection engine comprises:

a time determination module configured to receive the client data and the runner data, and perform data analytics to determine a travel time between the location of one of the plurality of delivery runners, a collection location for the selected goods and the delivery location.

4. The system of claim 3, wherein the time determination module is configured to identify a plurality of optimised travel routes, each optimised travel route being between the location of one of the plurality of delivery runners, the collection location for the selected goods and the delivery location.

5. The system of claim 4, wherein the runner selection engine further comprises a delivery fee module, the delivery fee module being configured to determine the delivery fee in dependence on the plurality of optimised travel routes.

6. The system according to any one of the preceding claims, wherein the runner selection engine further comprises a client and runner interaction module configured to communicate delivery and order information between the at least one client interface and at least one of the plurality of runner interfaces in dependence on the delivery fee, the client data and the runner data.

7. The system according to any one of the preceding claims, further comprising a data type module configured to analyse the client data and runner data to characterise the data as being of a variable or fixed data type.

8. The system according to claim 7, further comprising a location selection module, wherein the vendor selection module is configured to retrieve the characterised data from the data type module and select at least one collection location in dependence on the characterised data.

9. The system according to any one of the preceding claims, further comprising a multi-delivery module configured to retrieve runner data, access a mapping database, calculate a delivery delay and approve multi-deliveries for identified delivery runners in dependence on the calculated delivery delay.

10. The system according to any one of the preceding claims, further comprising a purchase module configured to securely facilitate purchase of the goods by the identified delivery runner.

11. The system according to any one of the preceding claims, wherein the purchase module is configured to determine a purchasing code and communicate the purchasing code to the runner interface of the identified runner to facilitate purchase of the selected goods.

12. A method of facilitating the delivery of goods, comprising the steps of:

accessing one or more data sources to obtain client input data and runner input data;

the client input data relating to at least one delivery location and at least one goods selection, and

the runner input data relating to a location of a plurality of delivery runners;

processing the client input data and runner input data, the processing comprising;

analysing the client input data with the runner input data to identify and at least one of the plurality delivery runners; and

establishing a delivery fee for the identified runner to facilitate the delivery of the at least one goods selection.

13. A method according to claim 12, further comprising

outputting instructions to the identified delivery runner to facilitate the purchase and delivery of the at least one goods selection.

14. A method of claim 12 or 13, further comprising

determining a travel time between the location of one of the plurality of delivery runners, a collection location for the selected goods and the delivery location.

15. The method of claim 14, further comprising identifying a plurality of optimised travel routes, each optimised travel route being between the location of one of the plurality of delivery runners, the collection location for the selected goods and the delivery location.

16. The method of claim 15, further comprising establishing the delivery fee in dependence on the plurality of optimised travel routes.

17. The method according to any one of claims 12 to 16, further comprising analysing the client input data and runner input data to characterise the data as being of a variable or fixed data type.

18. The method of claim 17, further comprising selecting at least one collection location in dependence on the characterised data.

19. The method according to any one of claims 12 to 18, further comprising calculating a delivery delay in dependence on the client input data and runner input data to facilitate an approval process of multi-deliveries for identified delivery runners.

20. The method according to any one of claims 12 to 19, further comprising determining a purchasing code and communicating the purchasing code to the identified runner to facilitate purchase of the selected goods.

21. A method for arranging a delivery service, the method being implemented using computer processing and memory resources accessible via a data network, the method comprising the steps of:

retrieving, at a client processing device, a request for the delivery service, the request including at least one delivery location data point and at least one goods selection;

selecting a delivery runner to perform the delivery service in dependence on the retrieved request; and

transmitting, to a delivery runner processing device, the at least one delivery location data point and the at least one goods selection.

22. A device for facilitating purchase and delivery of goods, comprising a processor, memory and an operating system supporting computer processes, an interface process arranged to provide a client interface arranged to receive client data relating to at least one delivery location and at least one goods selection, the device being for use with the system of any one of claims 1 to 11.

23. A device for facilitating purchase and delivery of goods, comprising a processor, memory and operating system supporting computer processes, a runner process arranged to provide a runner interface, being arranged to receive runner data relating to a location of a delivery runner, the device being for use with the system of any one of claims 1 to 11.

24. A computer program, comprising instructions for controlling a computer to implement a system in accordance with any one of claims 1 to 11 or a device in accordance with claim 22 or claim 23.

25. A computer readable medium, providing a computer program in accordance with claim 24.

26. A data signal, comprising a computer program in accordance with claim 24.