WO2025208173A1

WO2025208173A1 - Method and system for identifying a courier to deliver goods

Info

Publication number: WO2025208173A1
Application number: PCT/AU2025/050311
Authority: WO
Inventors: Gail Macleod
Original assignee: Atomiq Technologies Pty Ltd
Current assignee: Atomiq Technologies Pty Ltd
Priority date: 2024-04-02
Filing date: 2025-04-02
Publication date: 2025-10-09
Anticipated expiration: 2026-10-02

Abstract

A method for identifying a courier to deliver goods, the method being performed by a server and comprising: receiving from a user, via a user device, a delivery request for delivery of goods to a purchaser, the delivery request including at least one of courier data, retailer data and/or transaction data; extracting the data included in the request and processing the extracted data to identify delivery related particulars; processing the delivery related particulars and determining a courier score associated with the delivery request; and outputting a delivery assignment to the courier based on the courier score.

Description

METHOD AND SYSTEM FOR IDENTIFYING A COURIER TO DELIVER GOODS

TECHNICAL FIELD

The present invention relates to a method and system for identifying a courier to deliver goods. More specifically, the invention relates to a method and system for identifying a suitable courier to deliver goods sold, or being sold, from a retailer to a purchaser, the courier being identified based on data associated with the courier and a transaction completed between the retailer and the purchaser.

BACKGROUND

The popularity of electronic commerce/e-commerce, a term used to describe the activity of electronically buying or selling products on online services or over the internet, has drastically grown in recent times. This industry has especially seen a tremendous amount of growth since the onset of the COVID pandemic in late 2019. Due to the substantial growth in e-commerce demand, various retailers, small and large, have had to adapt accordingly and offer online purchasing/selling to their users, such as purchasers or sellers.

This e-commerce market demand increase has caused the demand in another industry, being the courier/transport industry, to also surge. The reason therefor being that trends indicate most users purchasing goods and/or services online, also prefer to receive those goods/services at their doorstep. Accordingly, in order to keep up with the demand and adhere to the needs of purchasers, in particular, there has also been an increase in courier services being added to seller’s value offerings. In some cases these courier services are maintained/provided by a separate department within the same entity as the entity selling the goods (typically for larger retailers) or, in other cases, the courier services may be provided/maintained by an independent third party that simply facilitates the transport of the purchased goods from point A, such as a seller location, to point B, such as a purchaser location. A common problem which is faced by retailers using third party courier services is that often the onus falls on the retailer to manage the courier. This includes, for example, booking a courier with a vehicle of sufficient size, selecting delivery and/or pickup dates, paying courier fees, etc. This carries further problems associated therewith as the retailers often face difficulties in finding suitable couriers at affordable prices, especially during peak demand times when there may be surcharges applicable, delays in delivery times, etc. which needs to be communicated to purchasers.

In some cases, particularly with smaller retailers, or individual sellers, the retailers need to personally go to a physical courier services branch to deliver items that need to be couriered or forced to pay an extra fee for delivery of the items at their own premises. This may, in some instances, be an obstacle as the relevant retailer may not have a vehicle with the desired capacity to transport bulk orders from their premises to a courier, or the couriers may refuse the bulk orders if they are unavailable to accommodate large volumes. In other cases, the couriers may only have large vehicle/transport fleets available and the retailer has to cover costs for rental or use of a large vehicle for even a small shipment.

A further problem which is also often faced by retailers is that couriers charge excessive fees for deliveries located outside of the city centre. For example, it is common for couriers to charge high courier fees for delivery in remote areas or areas located in the city outskirts. This is mainly due to fleet availability, operation costs and volume of orders in the outskirts.

Accordingly, the applicant considers there to be scope for improvement.

The preceding discussion of the background to the invention is intended only to facilitate an understanding of the present invention. Any references to methods, apparatus or documents of the prior art are not to be taken as constituting any evidence or admission that they formed, or form part of the common general knowledge. SUMMARY OF INVENTION

In accordance with an aspect of the invention there is provided a method for identifying a courier to deliver goods, the method being performed by a server and comprising: receiving from a user, via a user device, a delivery request for delivery of goods to a purchaser, the delivery request including at least one of courier data, retailer data and/or transaction data; extracting the data included in the request and processing the extracted data to identify delivery related particulars; processing the delivery related particulars and determining a courier score associated with the delivery request; and outputting a delivery assignment to the courier based on the courier score.

The user device may be one of a retailer device or a courier device. If the user device is a retailer device, the delivery request may include retailer data and transaction data. If the user device is a courier device, the delivery request may include courier data.

The data included in the delivery request may be encrypted. Processing the extracted data may include processing the extracted data while the data remains in the encrypted.

Processing the delivery related particulars may include processing the delivery related particulars to identify one or more of a delivery location; a retailer location; courier carrying capacity requirements; and latest delivery date.

Determining the courier score may include determining one or more courier subcategory scores and using the sub-category scores to determine the courier score. Each sub-category score may represent a factor of the delivery score. Preferably, the sub-category scores are based on location data associated with one or more of the courier data, the transaction data or the retailer data, and a courier capacity associated with the courier. Determining the courier score may further include comparing data included in the delivery related particulars with data associated with a courier record. Preferably, the data included in the delivery related particulars may be compared with data associated with one or more courier records.

The method may include receiving a delivery assignment acceptance request in response to a courier accepting the output delivery assignment and, updating a courier record associated with the courier.

Updating the courier record associated with the courier may include updating a courier carrying capacity at least for a date range associated with the delivery assignment.

If the courier does not accept the delivery assignment request, the method may include outputting the delivery assignment request to one or more additional couriers. Each of the one or more additional couriers may be associated with a courier record in a courier database.

The courier data may at least include, for each courier: courier vehicle carrying capacity; courier location data; and courier availability. The courier location data may include one or more of: a courier route destination; a courier route starting location; a date at which the courier will be at the courier starting location and/or the courier route destination. The courier data may be associated with one or more courier records stored in a courier database.

The retailer data may at least include, for one or more retailers: a retailer identifier and retailer location data. Each retailer may be associated with a retailer record, which is associated with the retailer data and stored in a retailer database.

The transaction data may at least include, for one or more transactions: a purchaser location, preferably a delivery location, a purchaser identifier, and a size associated with the goods to be delivered. The retailer data and the transaction data may be associated with each other. The retailer data and the transaction data of a particular transaction may be associated with the same retailer record. Alternatively, the transaction data of a particular transaction may be associated with the transaction record stored in a transaction database.

In accordance with a further aspect of the invention there is provided a system for identifying a courier to deliver goods, the system comprising: a memory for storing computer-readable program code and a processor for executing the computer-readable program code; a delivery request receiving component for receiving from a user, via a user device, a delivery request for delivery of goods to a purchaser, the delivery request including at least one of courier data, retailer data and/or transaction data; a data extracting component for extracting the data included in the delivery request and processing the extracted data to identify delivery related particulars; a courier score determining component for processing the delivery related particulars and determining a courier score associated with the delivery request; and a delivery assignment outputting component for outputting a delivery assignment to the courier based on the courier score.

In accordance with another aspect of the invention there is provided a computer program product for identifying a courier to deliver goods, the computer program product comprising a computer-readable medium having stored computer- readable program code for performing the steps of: receiving from a user, via a user device, a delivery request for delivery of goods to a purchaser, the delivery request including at least one of courier data, retailer data and/or transaction data; extracting the data included in the request and processing the extracted data to identify delivery related particulars; processing the delivery related particulars and determining a courier score associated with the delivery request; and outputting a delivery assignment to the courier based on the courier score. Further features provide for the computer-readable medium to be a non-transitory computer-readable medium and for the computer-readable program code to be executable by a processing circuit.

BRIEF DESCRIPTION OF THE DRAWINGS

Preferred features, embodiments and variations of the invention may be discerned from the following Detailed Description which provides sufficient information for those skilled in the art to perform the invention. The Detailed Description is not to be regarded as limiting the scope of the preceding Summary of the Invention in any way. The Detailed Description will make reference to a number of drawings as follows:

Figure 1 is a schematic diagram which illustrates an example embodiment of a system for identifying a courier to deliver goods according to aspects of the present disclosure;

Figure 2 is a swim-lane flow diagram which illustrates an example method for identifying a courier to deliver goods according to aspects of the present disclosure;

Figure 3 is a flow diagram which illustrates an example method of assigning a delivery to a courier in response to a delivery request according to aspects of the present disclosure;

Figure 4 is a block diagram which illustrates exemplary components of a server in a system for identifying a courier to deliver goods according to aspects of the present disclosure;

Figure 5 is a block diagram which illustrates exemplary components of a retailer device in a system for identifying a courier to deliver goods according to aspects of the present disclosure; and Figure 6 is a block diagram which illustrates exemplary components of a courier device in a system for identifying a courier to deliver goods according to aspects of the present disclosure.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

A method and system for identifying a courier to deliver goods sold, or being sold, from a retailer to a purchaser, is disclosed. Steps of the method may be performed by a server of a service provider platform having access to one or more databases storing information of the retailer, a completed transaction, and the courier. The databases may be updated in real-time or at predetermined intervals so as to keep the data current and up to date.

The steps of identifying a courier to deliver goods from a retailer to a purchaser may include: receiving an instruction to process data including one or more of: retailer data; transaction data; and/or courier data. The instruction may be generated and transmitted to the server in response to the retailer indicating that a transaction with a purchaser has been completed, or, in some embodiments, the instruction may automatically be generated and transmitted to the server in response to a transaction between the retailer and the purchaser being completed. A transaction may, for example, be considered complete once a purchaser has completed payment of the transaction. The instruction may be configured to include transaction related data or, alternatively, the instruction may include a pointer to transaction related data stored in a database and which is accessible to the server. The instruction may preferably be in the form of a delivery request. In some embodiments, a request may be received from a courier wanting to perform a delivery.

Once the request has been received by the server, the server may proceed to access and process the relevant data so as to identify a suitable courier, from a list of couriers, to offer a delivery assignment to, for at least one transaction. As briefly mentioned above, the data to be processed may include at least one of retailer data, transaction data, and/or courier data. In some embodiments, the server may proceed to access and process the relevant data to determine if any suitable deliveries are available for a courier requesting a delivery instruction/assignment.

The retailer data may be associated with the retailer selling the goods and may include data provided by the retailer via a retailer user interface provided by a software application. In some embodiments, the retailer data may be provided during a registration process or in response to a prompt received by the retailer and stored, at least temporarily, in a retailer database (or a memory of the server). The data may include at least one or both of a retailer name or identifier and retailer location information. The server may have access to and, in some embodiments, maintain the retailer database.

The courier data may be associated with a courier using the service. A courier may, for example, be required to register to offer courier services. During registration the courier may be required to provide courier data including: a name and surname of the courier; vehicle details; driver license details; consent to a background check; contact details; courier status; courier location data (discussed in more details below) and the like. The courier data may be stored in a courier database (which may be linked to the retailer database) and which is also accessible by the server. The courier location data may be updated at any time by the courier or by the server. The server may, for example, update the courier location data automatically based on a recently completed trip of the courier.

The courier location data may include a courier trip history, including information on previous trips/assignments completed by a particular courier, and upcoming trip information, including information on a planned, upcoming trip. The courier may, for example, upload a planned trip via a user interface and request an assignment within a particular radius/detour distance of the planned trip. The courier location data will be described in more detail below.

Turning to the transaction data - the transaction data may include information relating to the goods being purchased and the person/entity purchasing the data (the “purchaser”). The database may be configured to store the transaction data in a transaction database. The transaction database may, preferably, be linked to the retailer database so as to provide a clear link between a particular retailer and a particular transaction. The purchaser information stored in the transaction database may be limited to only pre-approved details so as to ensure the safety of the purchaser and the safeguarding of the purchaser’s information. For example, the only information of the purchaser of importance to the courier may be the delivery location and the name of the person/persons to collect the goods purchased on behalf of the purchaser. Accordingly, there is no need for the server (or courier) to have access to any additional information of the purchaser. The type of transaction and how it is completed between the retailer and the purchaser may therefore be irrelevant for the purposes of this disclosure. However, it should be appreciated that the disclosed system may be configured to integrate with any such system. Accordingly, the transaction database may include any purchaser information as is required by the overall system and should not be limited to the information I data disclosed herein. Additionally, the information relating to the goods being sold/purchased may include properties, such as quantity, weight, dimensions, material properties (which may be used to determine if the goods should not be exposed to heat/sunlight for too long), breakability, etc.

Processing the data to identify a courier may include determining, for each of the couriers in the database, if the courier has a vehicle capable of carrying a required load and if the courier is available for a trip within a specific date range. If more than one couriers meet the above criteria, the number of potentially available couriers may be limited by processing the courier location information to determine if the available couriers are within a certain distance/radius from a location where the goods need to be delivered. Alternatively, if no couriers are currently available, the system may determine which courier may be open to accepting an assignment based on the trip history of the courier.

It should be appreciated that the best courier for a particular assignment may be determined in pre-determined intervals. For example, a courier check may be carried out once a day, so that one or more orders may be pooled or sent with the single courier if two or more delivery locations are within a certain radius of each other and within the planned courier route. The courier database therefore also needs to store planned courier routes, which may, for example, be uploaded by a courier prior to the courier wanting to take the trip. The courier trip may, for example, include a start location, intermediate locations, an end location and a date range. The planned courier routes may, for example, be based on personal trips that the courier plan on taking from one destination to another at a particular date. This would enable the courier to complete an assignment, while on a trip to run another errand or go on holiday, for example.

Once a list of acceptable couriers has been determined based on the courier vehicle capacity and location data, a preferred courier may be selected based on a courier score. The courier score may be determined by the server and be based on various parameters, such as a courier customer rating, trip history (location and quantity), vehicle type, and the like. In order to ensure that different couriers are included in the system and get offered opportunities, a higher parameter value may, for example, be afforded to a trip history indicating that a courier completed their last offer a week ago compared to a courier that completed an order the previous day. In other words, the score may be configured to include a load sharing factor to ensure that couriers are afforded equal opportunity and not just impacted by a customer rating. In other words, a courier having a 4.2 customer rating and a last trip completion day of 14 days ago may have a higher courier score than, for example, a courier having a 4.5 courier rating with a last trip completion day of less than 24 hours. The scoring system will be disclosed in more detail below.

Once the preferred courier has been identified, the method may include offering a delivery assignment to the identified courier via a notification/prompt. The delivery assignment notification/prompt may include a time limit within which the courier needs to either accept or reject the assignment. Should the time limit be exceeded or the relevant courier reject the assignment, the assignment may be pushed to another courier, preferably the courier having the second highest courier score. This may be repeated until a courier accepts the assignment. In some embodiments, if, for example, none of the top 3 couriers accept the assignment, the assignment may be made available to all the couriers and the first courier to accept the assignment may be approved for said assignment.

The retailer may receive a notification indicating that the assignment has been accepted by a courier. The notification may include a date, and optionally time range, within which the courier will collect the goods from the retailer, as well as a date, and optionally time range, of when the goods will be delivered to the relevant purchaser. This will enable the retailer to keep the purchaser up to date with the delivery process.

The fees payable to the courier for delivery may be based on the number of goods delivered with a single trip and the distance to be completed by the courier, from the pick-up location (being the retailer location) to the delivery location, so as to incentivise the couriers to accept more delivery assignments. In some cases, such as where express shipping is required, the server may push instructions to couriers based on the courier route history in an effort to find a suitable courier that may be able to complete the delivery within a short time. In order to incentivise the couriers to accept such offers, the fees offered to the couriers for express delivery may be more compared to the fees of standard trips. It should further be appreciated that the fees need to be carried by the purchasers, even via their own reserves or via purchaser funds.

As is suggested by the above, in some embodiments one or more retailers may connect/communicate with the server and a courier may be selected to pool orders/deliveries from two or more different retailers at the same time.

It should be appreciated that the system may accommodate single retailers seeking delivery for single goods/products being sold, single retailers seeking delivery for multiple goods/products being sold and delivered to different purchasers, or in cases where retailers supply/sells goods/products to certain purchasers at regular intervals, the same couriers may be used to facilitate such orders for reliability reasons, or the like. The above description is provided to facilitate an understanding of the invention and how it may practically be implemented.

Example embodiments of the system and method will now be described in detail with reference to the accompanying Figures.

Figure 1 is a schematic diagram which illustrates an exemplary system (100) for identifying a courier to deliver goods by a retailer to a purchaser according to aspects of the present disclosure. Various combinations of the described features and aspects may be used in a given implementation.

The system (100) may include a service provider platform (102), a retailer device (104) and a courier device (106). In some embodiments, the system may include a purchaser device (not shown), which is discussed in more detail below.

The service provider platform (102), retailer device (104) and courier device (106) may be in data communication with each other via an appropriate communication network (108), such as the Internet or any other suitable public communication network. The retailer device (104) may be in the possession and under the control of a retailer (105). Similarly, the courier device (106) may be in the possession and under the control of a courier/driver (107).

It should be appreciated that even though only one retailer device (and retailer) and one courier device (and courier) are shown in the system, a plurality of these devices (and its respective users) may be present in a practical implementation.

The service provider platform (102) may be provided by a third-party service provider that provides logistics services to retailers by linking retailers to suitable couriers to deliver goods sold by the retailers. In some implementations, the functionality of the service provider platform may be incorporated into an e- commerce platform (not shown). The retailer (105) and/or retailer device (104) may be registered to interface with I or use the service provider platform (102) during an enrolment procedure. Likewise, the courier (107) and/or courier device (106) may be registered to interface with / or use the service provider platform (102) during an enrolment procedure. For the purposes of clarity, it should be appreciated that the terms courier and courier device and retailer and retailer device may be used interchangeably, except where the context dictates otherwise. For example, “the courier is registered with the service provider platform during an enrolment procedure” should be interpreted to mean that the courier and/or the courier device is registered with the service provider platform during an enrolment procedure.

As alluded to above, the service provider platform (102) may be configured to interface with the retailer device (104) and courier device (106) (or any other devices, discussed below) via the communication network (108). The communication network (108) may be any network via which data and/or messages may be transmitted to and received from the respective devices (104, 106).

The service provider platform (102) may be provided by any suitable computing device or devices and may for example include a server (110). The server (110) may, for example, be any suitable computing device configured to perform the role of a server such as a server cluster, a distributed server, a cloud-based server, or the like. The server (110) may be maintained by the third-party service provider providing a courier finding (logistics) service to the retailer. The server (110) may be configured to interface with other devices in the network via, for example, an appropriate API.

The service provider platform (102) may have access to and, in some embodiments, maintain a retailer database (112) in which a retailer record (114) associated with the retailer (105) and/or retailer device (104) is stored. The retailer record (114) may include at least one or more of: a retailer identifier associated with, and unique to, the retailer; a retailer name and surname; retailer contract details; and retailer location data. The retailer location data is, preferably, indicative of the location where the retailer stores goods that they trade with. For example, the location data may provide information, such as coordinates, of a warehouse where the retailer stores goods that they trade with. As discussed above, the service provider platform (102) preferably maintains the retailer database (112), however, it should be appreciated that in some embodiments the retailer database may be managed and maintained by an independent third party, such as an e-commerce platform facilitating sales between a retailer (105) and purchasers. In such an embodiment, the third party may simply provide access to the service provider platform (102) to the retailer database (112), or particular records within the retailer database, based on instructions from a retailer (105) to do so. It should be appreciated, for example, that the retailer database comprises a retailer record for each retailer registered to use the service and a particular retailer may only provide access to the retailer record associated with said retailer.

It should be appreciated that, in some embodiments, no retailer database (112) is kept, and retailer information required for the method/s, discussed below, may be stored in a memory of the server (110) for the duration of the method. This may be applicable in cases where, for example, a small/informal retailer has sold a product to a purchaser and wants to use a “once-off” courier service to deliver the product to the purchaser. In such an embodiment information such as a retailer name, contact details and location may temporarily be stored for the purposes of finding a suitable courier.

In addition to the retailer database (112), the service provider platform (102) may have access to and, in some embodiments, maintain a courier database (116) in which a courier record (118) associated with a courier (107) and/or courier device (106) is stored. It should be appreciated that the courier database (116) may include one or more courier records (118) and each of the courier records may be associated with a courier (106) and/or courier device (107) registered with the service provider platform (102), during enrolment. Each courier record (118) may include one or more of: a name and surname of the courier; a courier identifier unique to, and associated with, the courier; courier vehicle details; courier driver license details; indicator to consent to background checks; courier contact details; courier status; courier location data; and courier trip data. The courier vehicle details may, for example include details such as: vehicle make and model; year of manufacture; vehicle type (utility, sport utility, sedan, or the like); canopy (yes/no) and canopy dimensions; or the like. The vehicle details may also include details on the storage dimensions of the vehicle, such as boot space (in litres), the size of the flat bed tray or cargo bed, or the like. These details may be obtained automatically from publicly available datasheets, or, in some cases, the relevant courier may be required to manually provide the details. This would particularly be relevant in cases where the courier has modified the vehicle.

Furthermore, courier location data may include data, not limited to, a current location of the courier and a courier location history. The current location of the courier may be a starting location of the courier provided during enrolment. Normally, this would be the home/base location of the courier. The courier location history may include location data associated with previous trips/assignments performed by the courier and give an indication of areas to which the courier most frequently travels. Additionally, the courier trip data may include information on future planned and/or previous courier trips. This may include data on the quantity of goods transported via a previous trip, a rating provided to the courier for the trip, time elapsed between the collection and delivery of the goods, or the like.

The importance of the data stored in the relevant databases will become more apparent with the discussion on the applicable methods.

In some embodiments, the service provider platform (102) and/or server (110) may be configured to facilitate transactions between the retailer and a purchaser, as discussed above. The service provider platform may therefore be configured to interface and/or integrate with a platform of a financial institution allowing the transfer of funds from the purchaser to the retailer to facilitate a normal e- commerce transaction. For example, the server (110) may be configured to interface with an e-commerce platform and/or financial institution via an appropriate API.

In some embodiments, the service provider platform (102) may also have access to a transaction database (120). The transaction database may, in some embodiments, be maintained by the service provider platform (102). For example, if the service provider platform also includes functionality to facilitate transactions between the purchaser and a retailer, then the server may be configured to maintain the transaction database. However, in some embodiments, particularly where the transacting between the purchaser and the trailer is facilitated by a third-party e-commerce platform, the service provider platform (102) may simply be provided access to the transaction database (120) by the relevant third party. The transaction database (120) may include one or more transaction records (122), with each of the one or more transaction records linked to one or both of a retailer and/or purchaser. For example, the transaction record may include one or more of: data associated with the goods being sold, such as quantity, size, packaging, material properties, etc.; date, time and cost information (typically in a value of currency); a retailer identifier or retailer data (or a pointer to particular record stored in the retailer database); and purchaser data (or a pointer to a particular record stored in a purchaser database maintained by a third party server).

The purchaser data may, for example, include a purchaser identifier; a purchaser name and surname; purchaser location data (being a delivery address), purchaser order history, or the like.

Alternatively, the transaction database and the retailer database may be the same database and the retailer record may be configured to include details on transactions associated with the particular retailer. For example, it should be appreciated that the server need not have any direct link to the purchaser whatsoever and all communications between the purchaser and the retailer may be facilitated by a third-party platform. However, as discussed above, the service provider platform (102) may be configured to be the central point and manage communication between the retailer device, a purchaser device, the courier device and the applicable financial institutions to facilitate communication and other transactions between the relevant parties.

The retailer device (104) and/or courier device (106) (and purchaser device) may be any suitable electronic device with a communication functionality, such as a mobile handset (e.g., a feature phone, a smartphone, tablet computer, etc.), a desktop or laptop computer, a wearable computing device, a smart appliance or other internet-of- things (loT) device or the like. Each of the relevant devices (104, 106) may be uniquely identifiable by way of a device identifier.

In some cases, for example in a cloud computing implementation, software units arranged to manage and/or process data on behalf of the retailer device (104) and/or courier device (106) may be provided remotely. Some or all of the functionality of the devices may be provided by a software application downloadable onto and executable on the relevant device (104, 106). In other words, each of the devices (104, 106) may have a software application resident therein and installed thereon. The software application may be provided for download from a third-party software application repository, by the logistics service provider or a third-party e-commerce service provider, as the case may be. The software application may be created and maintained by the logistics service provider and, in some embodiments, a particular software application resident on a particular device (104, 106) may be linked to a particular retailer record or courier record, which ever the case may be.

The system (100) described above may implement a method for matching a courier to a retailer selling goods. An example embodiment of a method for matching a courier to a retailer selling goods is described in greater detail below. In the method discussed, it is assumed that the transaction between the retailer and purchaser has already been completed. This transaction could have been completed via a third-party e-commerce platform or the logistics service provider platform, or the like.

The steps as shown to be performed by the service provider platform may be executed by the server (110) provided by the service provider platform (102).

As discussed briefly above, the retailer database (112) and the courier database (116) may include data which is provided by respective retailers and couriers during an enrolment procedure. The enrolment procedure may be a standard enrolment procedure, in that the user (being a retailer or courier) may select an option to create a new account and then follow prompts to provide a required user input. For example, a retailer may be required to provide information such as a retailer name (including a business name and/or representative name and surname), retailer contact details, and retailer location data. The retailer location data may, for example, be provided manually or automatically determined by using a global positioning system (GPS) of the retailer device. In some embodiments, a user may be requested to provide access to a software application (provided by the logistics service provider), to access GPS data via a third-party application, such as Google Maps™, via an appropriate API, for example.

In some embodiments the provided information may be verified by consulting publicly available records or requesting consent form the retailer to do so, via the software application. For example, in order to prevent fraudulent retailers from signing up for the system, the retailers may need to be verified by providing a tax file number, proof of address, proof of incorporation, or the like, which may be validated by the logistics service provider. In some embodiments, the software application may be provided consent, by the relevant retailer, to obtain other user identifiers to verify the user identity. This could, for example, include obtaining login details from other applications resident on the retailer device.

It should be appreciated that, for security purposes, all information provided by the relevant retailer (105) or courier (107) during enrolment may be encrypted using one or more encryption standards. In other words, the information provided by a retailer (105) during enrolment may, for example, immediately be encrypted at the retailer device (104), transferred (in the encrypted form) to the service provider platform (102), where it is stored in the retailer database (116). It should be appreciated that, in order to preserve the privacy of the retailer (105) the data may remain encrypted even when being processed by the server (110) (or service provider platform (102)). In other words, homomorphic encryption may be used as it allows computations to be performed on encrypted data without first having to decrypt it. The resulting computations may then be left in an encrypted form which, when decrypted, result in an output that is identical to that produced had the operations been performed on the unencrypted data. The data may, for example, be decrypted at a courier device so that the courier may view the required processed data and accept or reject a delivery assignment offered to them. In this manner, the retailer (105) may, for example, ensure the safeguarding of purchaser information that need to be processed in order to create a delivery request to be presented to a courier (107). In some embodiments, for example, the third-party logistics service provider does not need to know any information of the purchaser, such as the purchaser name and location. As such, in order to safeguard the purchaser, the purchaser name and location may be encrypted at the retailer device (104) and transferred to the service provider platform (102) in an encrypted form. The data may then be stored in the transaction database (120) in encrypted form, accessible by the server (110). The encrypted data may then be accessed, processed and transmitted to the courier in the encrypted form as a delivery assignment. Once received, the delivery assignment may be decrypted by the courier device (106) to display all the necessary information, such as purchaser location and name, to the courier (107). This process is discussed in more detail below.

It should be appreciated that, in some cases, all data being processed by the server may be encrypted data so as to safeguard the data and prevent nefarious third parties from hacking the databases to gain access to the data in unencrypted form. The server therefore does not need to decrypt the data before processing the data. The data may be encrypted at the courier device or the retailer device (which ever the case may be) prior to being transmitted to the server (110). In other words, the data may be end-to-end encrypted. In some embodiments, the data may be encrypted by the server (110) when the data is received. However, it should be appreciated that the data may be transferred to the server via a secured communication network. For example, transport payer security (TLS) protocol may be used to facilitate privacy and data security for communication via the communication network.

The courier (107) may be required to undergo a similar registration process to that of the retailer (105), discussed above. The courier (107) may, for example, be required to provide the following information during registration: proof of identify (including a name and surname); vehicle details; driving licence details; and contact details. As one skilled in the art would appreciate, the courier identification, vehicle details, and driving licence may need to be verified for safety reasons. This may include requesting consent from the courier to conduct background checks or requesting potential couriers to submit verified documentation (and/or background checks) during registration, for example. The courier may need to be approved before that courier is registered and the courier data is captured in a courier record (118) stored in the courier database (116). Couriers may be manually verified, or, in some cases, machine learning algorithms may be put in place to verify a courier.

It should be appreciated that the preceding paragraphs discuss non-limiting enrolment procedures providing context to the workings of the present invention. To this end, in some embodiments, no retailer registration is required. For example, the retailer may simply be an interested seller interested in making use of a courier service offered by the third-party logistics service provider. In such embodiments, the retailer data may simply be temporarily stored in a memory of the server, or a database or record maintained by the third-party logistics service provider. As such, even though the retailer discussed with reference to Figure 2 is a registered retailer, it should be appreciated that a retailer may use the services facilitated by the service provider platform (102) without being registered. In such embodiments the relevant retailer data may be stored (at least temporarily) in a transaction record, which is stored in a transaction database.

A first exemplary method of matching a courier to a retailer selling goods is illustrated in the swim-lane flow diagram of Figure 2, in which respective swimlanes delineate steps, operations or procedures performed by respective entities or devices. The delineation illustrates one example embodiment and in other embodiments other delineations may be applied.

In this exemplary method the courier and retailer are registered with the third- party logistics service provider and the delivery request is received from a retailer device. It should be appreciated that, in some embodiments, the delivery request may be received from a courier device. Such an embodiment is discussed in more detail below. The method may include the retailer device (104), via the software application executing on the retailer device, generating (201) a delivery request I instruction in response to a user input received. Generating (201) a delivery request may include the retailer device collecting (203) transaction data and retailer data and generating a request including the collected data in a preferred format. In a preferred embodiment, generating the delivery request may include encrypting (205) the collected data. The collected transaction data may include information relating to the goods that have been sold to a purchaser, a time stamp, a delivery location associated with the purchaser and purchaser information, such as purchaser identification details. The purchaser identification details may either be a purchaser identification number linked with a purchaser record in a purchaser or transaction database, or, it may simply be a purchaser name and surname associated with the purchaser, and which may be used for delivery purposes. In some embodiments, the transaction data may be collected by accessing a transaction database or a retailer database storing transaction records. The collected retailer data may, for example, be a retailer identifier associated with a retailer record (114) in the retailer database (112). The retailer identifier may, for example, be associated with the retailer device and assigned to the retailer during an enrolment process.

The retailer device (104) may transmit (207) the delivery request to the service provider platform (102).

The service provider platform (102) may receive (209) the delivery request and process (211) the request to identify a courier (107) to facilitate the delivery of the purchased goods. Processing (211) the delivery request may include the service provider platform (102) extracting (213) the data included in the delivery request and processing (215) the data by executing one or more sets of instructions on the data to obtain/identify delivery related particulars. Processing (215) the data may include accessing a retailer record associated with the retailer identifier extracted from the delivery request. The retailer record (114) may be accessed in order to determine the location data associated with the retailer and which may be used as a collection location. The delivery related particulars may, at least temporarily, be stored in a memory of the server (110) for use in further calculations. In the present embodiment, the delivery related particulars may include the following: a purchase completion date and/or a latest delivery date; information on the quantity and size of the sold goods, the pickup location (retailer location); the delivery location; and purchaser particulars.

The purchaser particulars may include purchaser identification details and contact details.

The method may further include processing (217) the delivery related particulars and determining a courier score associated with the delivery request.

Processing (217) the delivery related particulars may include various sub-steps that need to be completed by the service provider platform (102). For example, processing the delivery related particulars may include the service provider platform (102) accessing and processing (219) courier data associated with one or more courier devices (106). Accessing (219) the courier data may include the service provider platform (102) accessing the courier data records stored in the courier database. This may include determining, for each of the one or more couriers having courier records stored in the courier database, whether the courier record indicates that the courier is available for deliveries.

Determining whether a courier is available for a delivery may include determining whether the courier has indicated that they are available by either setting a courier availability status as “active” or, in some embodiments, this may include determining whether the courier has recorded an upcoming trip (albeit another courier trip or a private trip) before a pre-determined date range.

Each retailer may, for example, require deliveries to be completed within a predetermined number of days from the date of sale of the respective goods. The predetermined data may be unique to each retailer and/or transaction depending on the offering from the retailer. For example, the retailer may offer same day delivery, ten-day delivery, or the like. The offered delivery date and how it is determined extend beyond the scope of this invention. However, the number of days in which delivery must be completed may be included in the identified delivery related particulars and may be manually included in the delivery request or determined by accessing the retailer record.

Once it has been established that a courier is available for a delivery (or to accept delivery instructions), a courier score may be determined (221) for said courier. It should be appreciated that in cases where more than one courier is identified as being available, a courier score may be determined for each available courier.

The courier score may be determined (221) by using the courier data and delivery related particulars. The courier score may be an indication of how suitable a particular courier is for a delivery instruction. For example, a high courier score may indicate that a courier is a good match for a particular delivery assignment and vice versa.

In some embodiments, the courier score may be based on the following subcategories: average courier rating (this may be a rating out of five, normally provided by the retailer based on purchaser feedback, for example, after completion of a delivery assignment); location data (including the proximity of the delivery location and courier location data, the proximity of the collection/retailer location and courier location data and courier travel history); courier carrying capacity; courier delivery history; or the like. Each of the subcategories, discussed below, may be awarded a sub-category score which may be based on relevant data elements from the delivery related particulars and may form the base of the courier score. Accordingly, each sub-category-score may represent a factor of the courier score.

Average Courier Rating

The average courier rating may be based the average rating awarded to a courier for completing a delivery assignment. In most cases, the rating is awarded to the courier by the retailer and based on timeliness, appearance and communication from the courier. For example, a courier causing delivery delays or not communicating delays to the retailer (which may communicate the delays to the purchaser) may receive a low courier rating for that particular delivery assignment.

It should be appreciated that, in some cases, the purchaser may also be in data communication with the service provider platform (102) and, in such cases, the purchaser may directly provide a rating to the courier via the service provider platform. Alternatively, the purchaser may indicate a courier rating I delivery rating on a third-party purchaser platform, which may then be submitted to the service provider platform (102) by the retailer. In some embodiments, both the purchaser and retailer ratings may be taken into account in such circumstances.

Location Data

The service provider platform (102) may, for example, be configured to determine whether the delivery location (being the purchaser location) is within a predetermined radius of a planned route stored in the courier record. For example, at any time during the method, a courier may update or set their availability for a delivery assignment. This may include the courier uploading, via a courier device, a planned route (being a courier route or personal route) and dates at which the courier will undertake the planned route. For example, in some cases the courier may indicate that they are travelling from location X to location Y and that they need to make the journey between a specified date range. In other embodiments the courier may add additional stops to the journey which may provide clarity into the most likely roads that the courier will complete during the planned route (which may be established via an internal mapping system or an external mapping system, such as Google Maps™).

Determining the courier score may therefore include mapping the courier route against the retailer location and the delivery location and determining whether at least one of the locations (preferably both) are within a predetermined radius of the planned courier route. This may include determining whether the courier start location is within a predetermined radius of the retailer location, whether the courier end location is within a predetermined radius of the delivery location and/or whether the delivery location and retailer location is within a predetermined radius of any point along the planned route. The better the mapping result (in other words the closer the delivery location aligns with the planned route), the higher the score afforded to the courier.

It should be appreciated that various tools and or third-party software may be utilised to provide mapping services and geo-spatial analysis. Such tools may enable the service provider platform (102) to plot precise courier travel routes (based on location information associated with the transaction), calculate distances and identify optimal paths based on real-time and historical geodata, such as traffic data, expected time of travel data, or the like. For example, the courier may simply submit location data in the form of a start point and an end point (for a planned route), and the additional tools may be used to determine the above data/information.

It should be appreciated that proprietary software may be used for such calculations and determinations, however, such disclosure extends beyond the scope of this invention.

Courier Delivery History

Determining the total courier score may further include calculating the number of trips performed by a particular courier during a period identified by the retailer. The period could be a week, month, year, or any suitable time period. A courier with more trips completed within a certain period may, for example, be awarded a lower score than a courier who has completed less trips during the specified period.

An advantage of such a score keeping system is that the load may be shared across various couriers without one single courier dominating the deliveries based on other factors. In other words, a larger number of couriers may benefit from the system instead of a select few. It should, however, be appreciated that in some embodiments, the score may also be calculated in the inverse manner so as to reward loyalty from couriers.

Courier Carrying Capacity

Determining the courier score may also include calculating or identifying the total size and weight of the goods to be delivered based on the delivery instruction. A retailer may, for example, when requesting delivery be prompted to provide information such as the wight and size requirements for transporting the goods. Generally, this would simply be the dimensions of the box/boxes that the goods are packed in and its respective weight. The total size and weight of the goods may be compared to the total carrying capacity stored in each of the relevant courier records and, again, each of the couriers having sufficient space may be provided a score value based on the available space.

In some embodiments, calculating a capacity sub score may also include determining whether the courier has an enclosed cargo space, such as a UTE with a rear canopy. For example, a courier having enclosed cargo space may be afforded a higher score for safety reasons and because it limits exposure of the sun to the goods to be delivered.

It should be appreciated that each of the categories may have a category score associated therewith and each category score may contribute to the total courier score. The weight afforded to each category score may also be tailored to the preferences of a retailer, the third-party logistics service provider, purchaser or the like. For example, in same cases the retailer may simply require fast delivery for a small package. In such a case, the carrying capacity and/or delivery history may not carry such a large weight to determine a suitable courier.

It should further be appreciated that for some categories a user may receive a zero score. For example, if the courier is not travelling in the direction of the delivery location, or if the courier carrying capacity is less than the capacity required for the goods to be delivered. Accordingly, in a preferred embodiment, for a courier to be considered suitable, or at least capable of completing a delivery, the courier may be required to have a score larger than zero (>0) for each category. If a score of zero is scored for a category, it is an indication that the courier may not be able to complete the delivery assignment, and the courier may be eliminated from contention for a delivery assignment.

Not all categories may necessarily be eligible for a zero-score value. For example, even if the courier location data is not ideal, if the courier is willing to complete a delivery, the courier may be offered the delivery as no real limitations exist. The courier may therefore be afforded a low location-based score, but the courier would not be completely incapable of completing the delivery. Whereas, if the courier does not have sufficient carrying/cargo capacity, the courier would be unable to facilitate delivery of the goods due to physical constraints.

It should further be appreciated that the above are just some examples of data/categories that may be used to determine a courier score, and the courier score may be determined using various sets of data. For example, it should be appreciated that if the retailer sells medicine or cold stuffs, the courier vehicle may be required to be equipped to keep the goods out of direct sunlight. In such an embodiment the fact whether the courier has an enclosed space for carrying the goods and that the space is temperature controlled may be important in determining the courier score.

The service provider platform (102) may therefore include eliminating (223) unsuitable couriers from the list of available couriers, based on the courier score, and determine (225) the most suitable courier for completing a delivery by evaluating the courier scores and identifying the courier that has been awarded the highest courier score. It should be appreciated that, in some embodiments, couriers with a courier score less than a predetermined threshold may also be considered to be “unsuitable” for the delivery, and these couriers may also be eliminated from consideration for a delivery assignment. The criteria for determining a suitable courier may therefore be determined on a case-by-case basis. The service provider platform (102) may generate (227) a courier delivery assignment and transmit (228) the delivery assignment to the relevant courier device (106), identified in the step above. The courier delivery assignment may include information such as the retailer location; retailer name and contact details; latest delivery date; delivery location; and purchaser name and contact details. The delivery assignment may also include a fee offer associated with the delivery. The fee offer may be a monetary value (fiat currency) offered by the retailer (or logistics service provider) the courier in exchange for the courier preforming the delivery. The delivery assignment may also only be valid for a predetermined amount of time, so as to eliminate unnecessary delays in the system.

The courier (107) may, via the courier device (106), receive (229) the delivery assignment and either accept (231) or reject (not shown) the assignment. If accepted, the courier device (106) may generate and transmit (232) an acceptance notification to the service provider platform (102). The service provider platform (102) may receive (233) the acceptance notification and generate and transmit (235) an assignment acceptance notification to the retailer device (103). The retailer (105) may receive (236) the acceptance notification and report (237) the information to a purchaser to inform the purchaser that a courier has accepted an offer to deliver the goods. In some embodiments the assignment acceptance notification may include courier details, such as a courier name and contact details and/or courier vehicle details to enable the purchaser and/or retailer to identify the courier. In further embodiments, the notification may include a link to enable the purchaser to track the order. In such an embodiment, the tracking functionality may be provided by the server provider platform (102) via the one or more location tools discussed above. Reporting the acceptance notification and additional information to the purchaser may include generating the report and providing the purchaser with the tracking link to track the delivery, for example. In some embodiments only the retailer may track the delivery and will manually report to the purchaser when delivery can be expected. In some embodiments, the purchaser platform (or third-party e-commerce platform) may be configured to provide delivery tracking functionalities based on the tracking link provided by the service provider platform (102). If the courier does not accept the notification, a rejection or time-out notification may be transmitted (not shown) to the service provider platform (102).

If a rejection or time-out notification is received, the service provider platform (102) may offer the notification to the next available courier with the second highest score. It should be appreciated that the service provider platform may only offer the delivery assignment to a limited number of available couriers.

If no suitable courier is found from the list of available couriers, or if no suitable courier accepts a courier delivery assignment, the service provider platform (102) may find a suitable courier in another way. This may include service provider platform (102) accessing one or more courier records and processing the courier records to determine if a courier has previously, or within a predetermined period, completed a trip with high similarity to the path/route required for delivery. This may include mapping the location data of the courier’s delivery history to the location data of the present delivery instruction. If the location data shows a high level of similarity (which may be determined similar to how the courier score is determined), the service provider platform may determine a delivery score for said courier and, if the delivery score exceeds a predetermined threshold, push a delivery assignment request to the courier. The courier may either accept or reject the assignment. The assignment may again be rejected by way of an active rejection message sent by the courier device, or by way of time-out.

It should be appreciated that if multiple couriers are identified having trip histories with high similarity, the same steps may be repeated for each of the couriers. In such an embodiment the delivery assignment may be confirmed to the first courier that accepts the assignment. The other couriers may be informed that the assignment has been accepted by another courier, or that the assignment has timed-out.

The above may provide a solution to a situation where no suitable couriers are available or can be found for a delivery instruction. In such a case the service provider platform (102) may be required to access the records to identify one or more suitable couriers and then push the assignment to those couriers. In some embodiments, the service provider platform (102) may enable a courier device (105) to request a delivery assignment from the service provider platform (102). In other words, the courier device (105) may request a delivery assignment, instead of a retailer submitting a delivery request. This may essentially be done by the courier (107) marking themselves as available for a delivery assignment and requesting the service provider platform (102) to find them a delivery assignment. Accordingly, in some embodiments, the service provider platform (102) may store one or more delivery requests for a period of time and make relevant delivery requests available to couriers that request delivery assignments and that has a high enough courier score to qualify for delivery of selected available delivery requests. For example, if a purchaser orders goods, but due to circumstances requests a delay in delivery, the delivery may be allocated to a courier requesting a delivery assignment. In such an embodiment, the courier (107) may need to meet a predetermined courier score threshold for a particular delivery instruction before a deliver assignment may be allocated or offered to the courier.

Such an embodiment is briefly discussed with reference to the flow diagram shown in Figure 3. A courier may (107), via a courier device (106), request a delivery assignment from the service provider platform (102). The request submitted from the courier may include courier data, such as courier location data, courier vehicle data, or the like. The service provider platform (102) may receive the request (301) and extract (303) the courier data from the courier delivery request and process (305) the data to determine delivery related particulars. The delivery related particulars may in this case, for example, include locations that the courier will visit and the dates at which the courier plan on visiting the locations. Additionally, processing the data to determine delivery related particulars may also include the service provider platform (102) accessing one or more stored delivery requests (this could be stored in a retailer database or transaction database) and processing the requests to determine the potential pick-up location (retailer location) for the delivery, the dimensions of the goods to be delivered, and the delivery location (purchaser location). The service provider platform (102) may process (307) the delivery related particulars and determine (309) a courier score using the processed delivery particulars. If the courier score, for example, is greater than a pre-determined threshold for a particular stored delivery request, the courier may output (311) a delivery assignment to the courier, based on the courier score. The courier may choose to accept or reject the delivery assignment. If the courier score does not meet the desired threshold, the same steps may be repeated for another request.

It should be appreciated that the steps of the second example embodiment that share similarities to the first example embodiment, discussed with reference to Figure 2, may include similar features and/or data to be processed. The steps are not repeated in detail for the sake of concision. It should, however, be appreciated that the method in which the subscriber score is determined, for example, may be the same for both embodiments.

In some embodiments, the service provider platform (102) may be configured to receive delivery requests in real time, but to only perform the next steps (such as extracting data from the request and processing the extracted data) at a later time, such as at a pre-determined interval. This may enable the service provider to more easily pool orders to a single courier, as the courier may receive a single delivery assignment for multiple orders, or multiple assignments for different orders at a single time. For example, the service provider platform may process delivery requests once a day so that one or more orders, sharing similarities, may be pooled. Accordingly, the service provider platform (102) may be configured to compare one or more delivery requests with one another and, if the delivery requests share similarities, such as the same retailer location and delivery locations within a pre-determined acceptable radius of each other, the delivery requests may be pooled (or combined) into a single delivery assignment and the courier score may be determined taking the plurality of delivery requests into account.

It should further be appreciated that the assignment offer I delivery assignment provided to a courier may include a monetary compensation value representing a courier I delivery fee. The monetary compensation value may be unique for each delivery request and determined using a number of factors. For example, the monetary compensation value may be based on at least one of the distance between the retailer location and the delivery location, the dimensions and weight of the goods sold, the required delivery dates, the number of available couriers, or the like. Deliveries that specify an imminent delivery date may, for example, include a higher compensation value than deliveries specifying an extended future delivery date. Similarly, the offered compensation value may increase if a lower number of couriers are available for a particular delivery. Accordingly, in some embodiments, the retailer may agree for a base delivery rate (generally approved by the purchaser or included in the purchase price of the goods) to be increased by a factor (which may be determined on a case-by-case basis) depending on the availability of couriers meeting a suitable courier threshold score.

The monetary compensation may be paid to the courier into a bank account associated with the courier device, a mobile wallet associated with the software application executing on the courier device, or the like. In some embodiments the monetary compensation may be paid to the courier directly from an account of the retailer at a third-party financial institution into an account of the courier at a third-party financial institution. In other embodiments, payments may be facilitated through the software application provided and maintained by the service provider platform (102). This may be done by the service provider platform providing verified/validated payment instructions to the relevant third- party financial services providers, or by a digital wallet system provided and maintained by the logistics service provider.

In other words, the compensation value may represent an amount payable by the retailer to the courier in return for services offered by the courier, and the amount may be determined by the service provider platform. In some embodiments, the methods discussed above may include the service provider platform transmitting a potential delivery assignment to the retailer for approval of a courier I delivery fee before a final delivery assignment I offer is sent to one or more couriers. This may include the servicer provider platform transmitting the offer to the retailer and processing the offer (for transmission to the courier) in response to the courier approving the offer. In some embodiments the offer may include one or more compensation values and each of the compensation values may be based on a determined subscriber score. For example, the offer transmitted to the retailer may include the courier score of the top 3 couriers available, and the retailer may select a preferred compensation value. A higher courier score may be associated with a higher compensation value. The offer may then be made available to the courier based on the retailer selection. If the courier rejects the offer, the above steps may be repeated.

It should be appreciated that a compensation value may determined in a number of different ways and based on a number of different factors, and should not be limited to the embodiments discussed above. It should further be appreciated that the logistics service provider may receive 10% of courier fees as a service provider fee, for example. In such an embodiment, the remaining 90% thereof may be the value offered to a courier for delivery.

Accordingly, the service provider platform may communicate to the retailer that a courier fee of A$10 is payable for a delivery request. If the retailer accepts the request, the final offer I assignment presented to the courier may indicate a delivery compensation of A$9. The remaining A$1 may be reserved for the logistics service provider. Alternatively, in some embodiments, one or both of the courier and retailer may have an agreement with the logistics service provider to pay subscription fees for making use of the services offered. The subscription fees may be based on various factors, such as subscription length, limits on delivery requests, or the like.

It should further be appreciated that a single courier may be offered (and accept) two or more delivery assignments. For example, a single courier may receive the highest courier score associated with a first delivery request and accept a delivery assignment for that delivery request. The same courier may, at a later time (and before completing the first delivery request), receive the highest courier score associated with a second delivery request and accept a delivery assignment for that delivery request too. It should therefore be appreciated that an aspect of the present invention includes updating the courier score regularly (in real time, or at pre-determined intervals). For example, if a courier accepts a delivery assignment, the available courier capacity changes (as the capacity decreases based on the required capacity for the first delivery request). The change in courier capacity would affect the courier score, based on the above criteria, but the courier may still be a good match for a second delivery request. In fact, it should be appreciated that in some cases it is preferred that a single courier performs multiple delivery assignments in a single courier trip, as it could lower the cost of the retailer while increasing the revenue of the courier. Additionally, the carbon footprint is reduced as only one courier completes a delivery route as opposed to two couriers completing similar delivery routes, for example. As such, in some embodiments, identifying that a courier has accepted an assignment offer associated with a first delivery request, during the steps of calculating a courier score for a second delivery request, may increase the courier score associated with the second request. In other words, “order pooling” may be another category which may be used to determine a courier score.

It is of utmost importance that the courier score gets updated regularly so as to prevent a single courier accepting multiple delivery assignments without having the capacity to carry all the goods associated with the delivery assignments. The courier score may be updated automatically in response to courier and/or retailer requests or actions. For example, a courier score associated with a courier may be updated in response to the courier updating a courier profile (or courier record) to indicate that the courier drives a new vehicle.

Various components may be provided for implementing the methods described above. Figure 4 is a block diagram which illustrates exemplary components of a server in a system for identifying a courier to deliver goods by a retailer to a purchaser. The system includes a server (110), which may form part of a service provider platform.

The server (110) may include a processor (402) for executing the functions of components described below, which may be provided by hardware or by software units executing on the server (110). The software units may be stored in a memory component (404) and instructions may be provided to the processor (402) to carry out the functionality of the described components. In some cases, for example in a cloud computing implementation, software units arranged to manage and/or process data on behalf of the server (110) may be provided remotely.

The server (110) may include a request receiving component (406) arranged to receive a request for the delivery of goods to a purchaser. The delivery request may include at least one of courier data, retailer data and/or transaction data. Preferably, if the delivery request is received from a retailer device (104) the delivery request includes retailer data and transaction data. If the delivery request is received from a courier device (106), the delivery request preferably includes courier data.

The server (110) may include a data extracting component (408) arranged to extract the data included in the delivery request, from the delivery request. The data extracting component (408) may be configured to extract the data in encrypted form for processing by the server (110) while the data remains in the encrypted form. The processor (402) may be configured to process the extracted data to identify delivery related particulars. The processor (402) may process the delivery related particulars to enable determining of a courier score.

The server (110) may include a courier score determining component (410) arranged to determine a courier score associated with the delivery request. The courier score determining component (410) may be configured to determine a courier score using the delivery related particulars as input data. The courier score may be based on data relating to one or more couriers, one or more retailers and/or one or more transactions. In some embodiments, the courier score determining component (410) may be arranged to determine one or more courier sub-category scores. Each of the sub-courier scores may be a factor of the courier score associated with the delivery request.

The server (110) may further include a delivery assignment outputting component (412) arranged to output a delivery assignment to the courier (107) based on the determined courier score. The outputting component (412) may be configured to output the delivery assignment to the courier (107) via a courier device (106). The outputting component (412) may be configured to generate and output the delivery assignment.

The server (110) may further include an updating component (414) arranged to facilitate updating of one or both of the retailer records and courier records. The retailer records and courier records may be updated based on instructions received from a courier or a retailer. In some embodiments, the records may be updated automatically by the server (110) in response to a delivery being completed.

The system may further include a retailer device (104). Figure 5 is a block diagram which illustrates exemplary components of a retailer device (104) in a system for identifying a courier to deliver goods by a retailer to a purchaser.

The retailer device (104) may include a processor (502) for executing the functions of components described below, which may be provided by hardware or by software units executing on the retailer device. The software units may be stored in a memory component (504) and instructions may be provided to the processor (502) to carry out the functionality of the described components. In some cases, for example in a cloud computing implementation, software units arranged to manage and/or process data on behalf of the retailer device (104) may be provided remotely.

The retailer device (104) may include a software application (505) installed on the device. The software application (505) may be configured to interface with the service provider platform (102) and/or one or more third-party e-commerce platforms. The software application (505) may include a delivery request component (506) for generating a delivery request and transmitting the delivery request to a server computer (110) of the service provider platform (102). The delivery request component (506) may be configured to collect I obtain retailer data and/or transaction data from the third-party e-commerce platform or from the retailer device (104) (preferably the retailer device memory component (504)). The software application (505) may include an encryption component (508) arranged to encrypt the data included in the delivery request, so as to obfuscate the data from the server (110). Similarly, the software application (505) may include a decryption component (510) to decrypt data received from the server (110).

The software application (505) may include an assignment acceptance component (512) arranged to receive a notification from the server (110) that a courier has accepted a delivery assignment.

The retailer device (104) may further include a display (514) for displaying data and/or notifications to a retailer (105). It should be appreciated that the retailer device (104) may include built-in communication means or components to enable communication between the retailer device (104) and other devices and I or entities in the network.

The system may further include a courier device (106). Figure 6 is a block diagram which illustrates exemplary components of a courier device (106) in a system for identifying a courier to deliver goods by a retailer to a purchaser

The courier device (106) may be a device similar to the retailer device (104). The courier device (106) may include a processor (602) for executing the functions of components described below, which may be provided by hardware or by software units executing on the courier device. The software units may be stored in a memory component (604) and instructions may be provided to the processor (602) to carry out the functionality of the described components. In some cases, for example in a cloud computing implementation, software units arranged to manage and/or process data on behalf of the courier device (106) may be provided remotely.

The courier device (106) may include a software application (605) installed on the device. The software application (605) may be configured to interface with the service provider platform (102) and/or one or more third-party mapping service platforms. The software application (605) may include a delivery request component (606) for generating a delivery request and transmitting the delivery request to a server computer (110) of the service provider platform (102). The delivery request component (606) may be configured to collect I obtain courier data from the courier device (106) (preferably the retailer device memory component (604)).

The software application (605) may include an encryption component (608) arranged to encrypt the data included in the delivery request, so as to obfuscate the data from the server (110). Similarly, the software application (605) may include a decryption component (610) to decrypt data received from the server (110).

The software application (605) may include a delivery assignment receiving component (612) arranged to receive a delivery assignment from the server (110). The delivery assignment may be associated with the delivery request. The software application (605) may include a delivery assignment accepting component (614) for accepting the delivery assignment and transmitting an acceptance notification to the server (110).

The courier device (106) may further include a display (614) for displaying data and/or notifications to a courier (107). It should be appreciated that the courier device (106) may include built-in communication means or components to enable communication between the courier device (106) and other devices and I or entities in the network.

The system and method disclosed therefore provides an improved system for allocating deliveries to a courier based on a score associated with a courier. The system and method eliminate the need for a retailer to find a reputable courier with sufficient carrying capacity independently. Accordingly, the onus to research couriers and determine their suitability to complete deliveries shifts from the retailer to the logistics service provider. Similarly, the liability of a courier’s action may also shift to the logistics service provider as opposed to the retailer, which may be a major advantage to the retailer. A further advantage of the disclosed system and method is that it provides an individual travelling for leisure, such as visiting family, with the opportunity to earn an additional income while travelling. Not only does this benefit the individual, but it may also have an environmental impact in that it eliminates the need for an extra vehicle (such as a designated courier) to be on the road. The system and method may be adapted to reward individuals with electric I hybrid vehicles, by for example taking environmental features and sustainability into account when determining the courier score.

The system and method may integrate with one or more third-party services for improved order pooling and/or route optimization for the courier. In order to improve order pooling, the method and system may leverage a combination of real-time data processing, advanced analytics, and machine learning (with all, for example, running on a scalable cloud infrastructure). For example, to enable realtime data processing and analytics, Apache Kafka may be utilized for its high- throughput and fault tolerant streaming capabilities, allowing the platform to efficiently manage real-time data streams from various sources, including courier vehicle locations and delivery requests. In addition, Apache Spark may be used for its powerful in-memory data processing, enabling the service provider platform to perform complex analytics and optimisations on large datasets in real time.

To improve integration with external data real-time traffic data and GPS data may be of crucial significance. To this end, various RESTful APIs may be implemented to integrate with external services like the Google Maps API, ensuring access to up-to-date traffic conditions and geographic information. This may also enable the service provider platform to provide real-time navigation services to the courier once the courier starts with the actual execution of a delivery assignment.

The system and method described herein may further include various pricingbased models in order to facilitate fair and just pricing models to the benefit of both purchasers and couriers making use of the system. The pricing-based models may be configured to manage complex logic associated with dynamic pricing adjustments so as to enable real-time pricing updates based on demand (or order volumes) and external rate updates.

The system and method may further include various route optimization techniques. The route optimization techniques may facilitate accurate price calculations, improved courier score determination and courier navigation. For example, the system and method may include tools for real-time traffic monitoring and perform predictive analytics to detect and anticipate traffic patterns which may be used to facilitate on-time delivery. All these tools may also assist in determining whether a courier indicating a particular departure date will reach the delivery location within the allowed time and may be used to facilitate the purchaser or retailer to keep track of the real anticipated delivery time.

The foregoing description has been presented for the purpose of illustration; it is not intended to be exhaustive or to limit the invention to the precise forms disclosed. Persons skilled in the relevant art can appreciate that many modifications and variations are possible in light of the above disclosure.

Any of the steps, operations, components or processes described herein may be performed or implemented with one or more hardware or software units, alone or in combination with other devices. Components or devices configured or arranged to perform described functions or operations may be so arranged or configured through computer-implemented instructions which implement or carry out the described functions, algorithms, or methods. The computer-implemented instructions may be provided by hardware or software units. In one embodiment, a software unit is implemented with a computer program product comprising a non-transient or non-transitory computer-readable medium containing computer program code, which can be executed by a processor for performing any or all of the steps, operations, or processes described. Software units or functions described in this application may be implemented as computer program code using any suitable computer language such as, for example, Java™, C++, or Perl™ using, for example, conventional or object-oriented techniques. The computer program code may be stored as a series of instructions, or commands on a non-transitory computer-readable medium, such as a random access memory (RAM), a read-only memory (ROM), a magnetic medium such as a harddrive, or an optical medium such as a CD-ROM. Any such computer-readable medium may also reside on or within a single computational apparatus, and may be present on or within different computational apparatuses within a system or network.

Flowchart illustrations and block diagrams of methods, systems, and computer program products according to embodiments are used herein. Each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, may provide functions which may be implemented by computer readable program instructions. In some alternative implementations, the functions identified by the blocks may take place in a different order to that shown in the flowchart illustrations.

In compliance with the statute, the invention has been described in language more or less specific to structural or methodical features. The term “comprises” and its variations, such as “comprising” and “comprised of” is used throughout in an inclusive sense and not to the exclusion of any additional features.

It is to be understood that the invention is not limited to specific features shown or described since the means herein described comprises preferred forms of putting the invention into effect.

The invention is, therefore, claimed in any of its forms or modifications within the proper scope of the appended claims appropriately interpreted by those skilled in the art.

Claims

1. A method for identifying a courier to deliver goods, the method being performed by a server and comprising: receiving from a user, via a user device, a delivery request for delivery of goods to a purchaser, the delivery request including at least one of courier data, retailer data and/or transaction data; extracting the data included in the request and processing the extracted data to identify delivery related particulars; processing the delivery related particulars and determining a courier score associated with the delivery request; and outputting a delivery assignment to the courier based on the courier score.

2. A method in accordance with claim 1 wherein the user device comprises a retailer device or a courier device such that if the user device is a retailer device, the delivery request may include retailer data and transaction data. If the user device is a courier device, the delivery request may include courier data.

3. A method in accordance with claim 1 or claim 2 wherein the delivery request is encrypted and wherein processing the extracted data may include processing the extracted data while the data remains encrypted.

4. A method in accordance with any one of the preceding claims wherein the delivery related particulars include processing the delivery related particulars to identify one or more of a delivery location; a retailer location; courier carrying capacity requirements; and latest delivery date.

5. A method in accordance with any one of the preceding claims wherein the courier score includes determining one or more courier sub-category scores and using the sub- category scores to determine the courier score and wherein each sub-category score represents a factor of the delivery score.

6. A method in accordance with claim 5 wherein the sub-category scores are based on location data associated with one or more of the courier data, the transaction data or the retailer data, and a courier capacity associated with the courier.

7. A method in accordance with any one of the preceding claims wherein determining the courier score further comprises comparing data included in the delivery related particulars with data associated with a courier record.

8. A method in accordance with claim 7 wherein the data included in the delivery related particulars may be compared with data associated with one or more courier records.

9. A method in accordance with any one of the preceding claims further comprising the step of receiving a delivery assignment acceptance request in response to a courier accepting the output delivery assignment and, updating a courier record associated with the courier.

10. A method in accordance with claim 9 wherein updating the courier record associated with the courier includes updating a courier carrying capacity at least for a date range associated with the delivery assignment.

11. A method in accordance with claim 9 or claim 10 wherein if the courier does not accept the delivery assignment request, the method comprises outputting the delivery assignment request to one or more additional couriers and wherein each of the one or more additional couriers are associated with a courier record in a courier database.

12. A method in accordance with any one of the preceding claims wherein the courier data includes, for each courier: courier vehicle carrying capacity; courier location data; and courier availability.

13. A method in accordance with claim 12 wherein the courier location data includes one or more of: a courier route destination; a courier route starting location; a date at which the courier will be at the courier starting location and/or the courier route destination and wherein the courier data is associated with one or more courier records stored in a courier database.

14. A method in accordance with any one of the preceding claims wherein the retailer data includes, for one or more retailers: a retailer identifier and retailer location data and wherein each retailer is associated with a retailer record, which is associated with the retailer data and stored in a retailer database.

15. A method in accordance with any one of the preceding claims wherein the transaction data at least includes, for one or more transactions: a purchaser location, preferably a delivery location, a purchaser identifier, and a size associated with the goods to be delivered.

16. A method in accordance with any one of the preceding claims wherein the retailer data and the transaction data are associated with each other.

17. A method in accordance with claim 16 wherein the retailer data and the transaction data of a particular transaction are associated with the same retailer record.

18. A method in accordance with claim 16 wherein the transaction data of a particular transaction is associated with the transaction record stored in a transaction database.

19. A system for identifying a courier to deliver goods, the system comprising: a memory for storing computer-readable program code and a processor for executing the computer-readable program code; a delivery request receiving component for receiving from a user, via a user device, a delivery request for delivery of goods to a purchaser, the delivery request including at least one of courier data, retailer data and/or transaction data; a data extracting component for extracting the data included in the delivery request and processing the extracted data to identify delivery related particulars; a courier score determining component for processing the delivery related particulars and determining a courier score associated with the delivery request; and a delivery assignment outputting component for outputting a delivery assignment to the courier based on the courier score.

20.Acomputer program product for identifying a courierto deliver goods, the computer program product comprising a computer-readable medium having stored computer- readable program code for performing the steps of: receiving from a user, via a user device, a delivery request for delivery of goods to a purchaser, the delivery request including at least one of courier data, retailer data and/or transaction data; extracting the data included in the request and processing the extracted data to identify delivery related particulars; processing the delivery related particulars and determining a courier score associated with the delivery request; and outputting a delivery assignment to the courier based on the courier score.