WO2012168735A1

WO2012168735A1 - Delivery system and method

Info

Publication number: WO2012168735A1
Application number: PCT/GB2012/051306
Authority: WO
Inventors: Gregory Reeve; John Maynard; Peter Cornforth
Original assignee: Vodafone Ip Licensing Limited
Priority date: 2011-06-09
Filing date: 2012-06-08
Publication date: 2012-12-13
Also published as: GB201109650D0; GB201112636D0; GB2492421A

Abstract

A system and method of enabling collection of a physical entity by an intended recipient, used with an arrangement including a stored value account system associated with a mobile telecommunications network, such that the intended recipient is an authorised user of a stored value account which is associated with a smart card usable in the mobile telecommunications network, the method including a network entity of the stored value account system: receiving payment for the delivery of the physical entity; reserving at least part of the payment to one or more service providers pending successful delivery of the physical entity to the intended recipient;receiving identification information for the intended recipient that is associated with the stored value account;upon receiving a collection request for the physical entity, verifying the intended recipient; and upon positively verifying the intended recipient, releasing the at least part payment via the stored value account system to the one or more service providers. Preferably the identification information received is also associated with the mobile telecommunications network smart card and the verifying step includes using the mobile telecommunications network to verify that the intended recipient is in physical possession of the smart card. The account is preferably a stored value account, such as M-PESA.

Description

Delivery System and Method

Field of the Invention

The present invention relates to a system and method for implementing delivery of a physical product. More particularly the present invention relates to a system and method for implementing delivery of a physical product to an intended recipient, where the recipient does not have a usable delivery address. Even more particularly the present invention relates to a system and method for enabling delivery to, and collection by, an intended recipient without a usable delivery address using a mobile telecommunications network.

Background

In the developed world, where the majority of the population have an address to which delivery of parcels and the like can be effected, there is a reasonable degree of certainty of those parcels reaching the intended recipient.

There are some instances still occurring of parcels never arriving at their intended destination, due to being lost or stolen en route. Whilst this is not an overly rife problem in most developed countries, it does occur, and so any approach to further minimise its occurrence would be of value.

More problematic, however, is the fact that in developing countries, such as India and the majority of the African countries, many people do not have residences to which parcels can be delivered. In this regard, many townships in these regions include slums or "shanty" towns which are made up of makeshift homes with no official address. The same problem applies to rural areas in both developed and developing countries where addresses may also not be commonplace.

It is possible for people who are resident in such regions to arrange for delivery of a parcel to be effected to a post office for collection, however, this approach still has its problems. In particular, this approach has difficulties in verifying that the person collecting a parcel is the correct intended recipient, as many people in developing countries do not have adequate forms of identity. This has unfortunate implications for the intended recipient, as third parties aware of the delivery may try to collect the parcel with fraudulent identification. There are also disadvantageous implications for the sender of the parcel, as they are generally not able to obtain confirmation that the goods have been properly received. These problems are currently major barriers for delivery companies working with confidence in such emerging markets.

Therefore, a technical problem to be overcome is the ability to verify the identity of an intended recipient of a physically delivered item for collection with an enhanced degree of certainty.

Overall, there is therefore a need for an improved system and method that overcomes or ameliorates at least one of the problems of the prior art. More specifically there is therefore a need for a system and method for delivery of physical products which is able to provide improved accountability and verification of delivery to the intended recipient.

Summary of the Invention

According to one aspect, the present invention provides a method of enabling collection of a physical entity by an intended recipient, used with an arrangement including a stored value account system associated with a mobile telecommunications network, such that the intended recipient is an authorised user of a stored value account which is associated with a smart card usable in the mobile telecommunications network, the method including a network entity of the stored value account system:

receiving payment for the delivery of the physical entity;

reserving at least part of the payment to one or more service providers pending successful delivery of the physical entity to the intended recipient;

receiving identification information for the intended recipient that is associated with the stored value account;

upon receiving a collection request for the physical entity, verifying the intended recipient; and upon positively verifying the intended recipient, releasing the at least part payment via the stored value account system to the one or more service providers.

This first aspect of the invention advantageously links an intended recipient with a stored value account and a smart card and uses this association to manage the delivery/collection of a physical product to the intended recipient with enhanced surety.

According to a second aspect, the present invention provides a method of enabling collection of a physical entity by an intended recipient, used with an arrangement including a stored value account system associated with a mobile telecommunications network, such that the intended recipient is an authorised user of a stored value account associated with a smart card that is usable in the mobile telecommunications network, the method including:

enabling the intended recipient to collect the physical entity from a collection location upon a verification of the intended recipient's identity by using the mobile telecommunications network to verify the intended recipient's physical possession of the smart card. Advantageously this second aspect of the invention physically ties a unique telecommunications identifier of the intended recipient via the smart card (e.g. an MSISDN on a SIM). This approach therefore advantageously validates possession of the validation information rather than just knowledge of it, as per the standard password approach. Uniquely, this second aspect of the invention makes use of a telecommunication provider's existing security features as a means of verifying the identity of the individuals for the delivery companies. This provides an added element of security, particularly since it prevents third parties stealing the parcel number "knowledge" and collecting the parcel - they additionally require physical possession of the SIM. In this way the SIM acts as a central source of verification cyclically linking the actual delivery recipient, the stored value account and the telecommunications network. This physical validation approach is preferably utilised in conjunction with the step of communicating a unique parcel identifier to the intended recipient's mobile terminal, so that a twofold association between the delivery procedure and the telecommunications network is made, which enables a more reliable exchange of information, as well as a more reliable approach of ensuring successful deliveries. Overall, the telecommunications network serves to assist a delivery company in gathering identity information and can also assist in determining appropriate pickup and drop-off points. Advantageously these aspects of the invention enable a telecommunications network to be utilised in cooperation with a delivery network in order to facilitate delivery of physical products with enhanced surety.

This is a new and advantageous use of existing telecommunications networks that enables people in less developed regions to have the ability to receive physical products, despite the hardships and limitations of their physical environment. It also facilitates the opening up of new customers and markets to product manufacturers and product suppliers, as well as enabling delivery companies to physically reach new customers.

The amalgamation of mobile network security and user validation with the delivery procedures results in a synergistic combination that attains a result that was heretofore unachievable. In particular, the usage of the intended recipient's mobile network information (e.g. their M-PESA SIM and account combination) is used in a twofold manner to:

i) communicate unique delivery information (i.e. the parcel number via an SMS to the intended recipient's MSISDN); and

ii) verify the collection (i.e. through the correct parcel number and account PIN combination and/or possession of the SIM identity information).

According to another aspect, there is provided a method of using a mobile telecommunications network to determine a particular location for delivery of a physical entity to an intended recipient, such that the intended recipient has a stored value account usable with a mobile telecommunications network smart card (such as a SIM), the method including:

determining one or more collection agents:

associated with the stored value account; and/or

proximate a geographic location associated with the mobile telecommunications network smart card; and

enabling selection of the one or more determined collection agents as the particular location for delivery of the physical entity. Preferably the one or more collection agents determined to be associated with the stored value account are agents that the intended recipient has utilised with the account for other services, such as banking services, and which are also usable for delivery services. These aspects of the invention enable a means of delivery, product tracking and payment so that delivery companies can reach people in areas where addresses are not commonplace, such as slums and rural areas. Importantly, these aspects of the invention do not require the users to have bank accounts or credit cards, but can still provide all consumers with adequate consumer protection.

Brief Description of the Drawings

Embodiments of the invention will now be described with reference to the accompanying Figures, in which: Figure 1 illustrates a summary of the overall delivery procedure according to an embodiment of the invention;

Figure 2 illustrates a flowchart of a procedure for sending a parcel from the sender's viewpoint according to an embodiment of the invention;

Figure 3 illustrates a flowchart for determining a parcel collection point according to an embodiment of the invention; Figure 4 illustrates an example network architecture and confirmation message flow that could be utilised to effect a customer initiated agent location determination, such as described in relation to Figure 3; Figure 5 illustrates a flowchart of a parcel collection procedure according to an embodiment of the invention;

Figure 6 illustrates an example network architecture that could be utilised to effect an agent initiated customer parcel collection, such as described in relation to Figure 5; and

Figure 7 illustrates a flowchart of a parcel delivery procedure where the intended recipient pays for the transaction according to an alternative embodiment of the invention.

Detailed Description

The embodiments of the present invention make use of telecommunications networks to provide a unified and integrated system configuration with delivery companies in order to deliver physical entities, particularly to individuals with no usable address for delivery purposes.

The physical entities may be any goods, products, device, articles and the like that have a physical presence, such that it needs to be physically transported between locations. Typical examples include packages, parcels and the like.

At present, telecommunications networks are being used in developing countries in order to provide such individuals with money transfer services. This has proved to be a unique and valuable approach for people in those regions to not only securely receive monies from remotely located friends and relatives, but to help develop and expand commerce within communities in developing countries. All that is required for individuals to participate in this money transfer scheme is a stored value account linked with the telecommunications company managing the scheme, and a smart card, such as a SIM that is associated with the account, and is usable in the mobile network. An example of such an existing stored value account system is known as M-PESA.

M-PESA is an alternative to traditional bank accounts and accordingly usable as a payment solution by persons without such monetary facilities. Users with such a stored value bank account are able to transfer money to, and receive money from, other users of the system with a compatible M-PESA account, using registered retail outlets. The accounts are "stored value" in that the accounts store money for transfer to other person (e.g. to pay bills).

It is to be appreciated, however that these money transfer services only relate to the virtual transfer of money between accounts in the system, and that there is no physical transfer of products between remote locations. The problems and considerations associated with a physical product delivery, such as verification of the correct recipient at the collection point, are entirely distinct from those of virtual transfers.

The embodiments of the present invention nevertheless make use of these stored value accounts. More particularly, in the physical product delivery approaches of the present invention, stored value accounts controlled by a mobile network provider may be used:

a) to effect payment for the physical deliveries. This enables individuals who may not normally have access to product delivery (e.g. due to not having access to a credit card) to benefit therefrom. Also, from the delivery companies' viewpoint, it removes, or at least reduces, the onus of managing fraudulent orders (e.g. it removes the risk of orders placed using cloned credit cards); and

b) in the verification of the person collecting the physically delivered product. In this regard, since the accounts are secure and personal to individuals, the present invention also makes use of their security aspects as a means of verifying the identity of the individuals for the delivery companies.

This use of the network account to verify the intended recipient of a delivered product is distinct and unique from its normal usage. An example of how these network accounts are used in relation to the present invention will now be generally described with reference to Figure 1. Figure 1 provides a flowchart of an exemplary procedure according to an embodiment of the invention for physically effecting the transfer and delivery of a physical entity (e.g. a parcel) from one location to another. In this regard, firstly, the procedure requires a collection address to be nominated for the parcel to be delivered to and collected from, and the delivery paid for (10). How this step is achieved is not essential to the invention, and several different alternatives exist, including:

i) a sender of a parcel visiting a dispatch agent to drop off the parcel to be sent and pay for the delivery;

ii) a sender of a parcel to contact a dispatch agent to arrange for collection of the parcel and payment for the delivery;

iii) a merchant acting on behalf of the sender to contact a dispatch agent to arrange for collection of the parcel and payment for delivery; and

iv) a merchant acting on behalf of the intended recipient to contact a dispatch agent to arrange for collection of the parcel and payment for delivery.

In all these examples, payment may be made by any means, including from a stored value account held by the sender with a telecommunications company managing the overall procedure. When the payment is made, the monies preferably are not sent directly to all the parties involved, but are instead essentially held in trust in a holding account until the entire delivery is completed, or at least until each entity to be paid has completed their part of the procedure. This money can be held by the telecommunications company managing the network stored value accounts, but preferably the money is managed by the delivery company. Where the money is managed and held by the delivery company, the delivery company is considered to essentially own the parcel from the time it is picked up from the dispatch agent, to the time it is delivered to the collection agent. It is this latter approach that will be described in the following embodiments. With the parcel ready for delivery, the nominated delivery company will come and collect the parcel from the pick up/dispatch agent (1 1). When this occurs, the dispatch agent has fulfilled their part of the procedure, and so, according to this embodiment, their commission will be paid to them from the holding account.

At step (12) the delivery company determines the recipient collection point. This may be determined in a number of ways, including:

i) the sender nominating the collection location for the recipient;

ii) the intended recipient nominating an agent independently; or

iii) the network determining one or more collection agents that may be suitable, and the intended recipient nominating the most appropriate agent from those suggested for them to collect from. This is the more preferred option and will be described in more detail in relation to Figure 3. Once the collection location is determined, the delivery company will deliver to that collection location (13). The recipient is then able to collect the parcel upon successful being verified as the intended recipient. This typically involves the intended recipient proving they are in possession of the unique parcel number and being able to verify physical possession of the SIM that is associated with both the mobile network and the stored value account. By presenting the SIM at the collection location, the network is able to physically verify the presence of the recipient. This may be achieved by virtue of the SIM having a registered communication session with the network or may involve the network performing a Location Area Update (LAU) in relation to the SIM. At the network level, a comparison of an identity from the SIM, such as the MSISDN or IMSI, will occur with that associated with the stored value network account. Ideally the recipient will also verify themselves as the owner of the network account associated with the unique parcel number via a PIN (i.e. the network account is verifiable with a PIN). Importantly the parcel number is also associated with the user's MSISDN/SIM, by virtue of the unique parcel number having been communicated to it) (14). With the parcel collected by the intended recipient, the collection agent has fulfilled their role in the overall procedure and in turn receives their commission (15). Figures 2, 3, 5 and 7 provide more specific descriptions of particular aspects of the overall procedure, which may be considered as embodiments of the invention. In this regard, firstly Figure 2 illustrates an example of a procedure that may be implemented when a parcel is dropped off to a dispatch agent. This is an expansion of one possible aspect of step (10) of Figure 1, in that it is from the viewpoint of the sender effecting payment using a network stored value account.

When a person wishes to send a parcel to another person, be it a gift or a product ordered by the other person, according to this example, to effect the delivery, the sender takes the parcel to a participating agent store (i.e. the dispatch agent). This agent store acts as an intermediary or gateway between the person sending the parcel and the courier/delivery company who will be responsible for physically transporting the parcel. In this example, it is the delivery company that provides the overriding management of the procedure.

Further, in this example both the dispatch agent and the sending customer have accounts with the telecommunications network (although where the sender pays by other means, only the dispatch agent need have an account in order to receive their commission). This effectively makes both entities known to the telecommunications network and allows it to manage their interrelationship, particularly by providing a reliable source of funds for the services to be rendered, thereby ensuring payment is validly received and not retracted (e.g. which could occur when a fraudulent credit card is used for payment).

To initiate the delivery procedure, an application (i.e. "app") on a terminal will be opened at the dispatch end. This application can be on a terminal associated with either the sender or the dispatch agent (i.e. the dispatch agent may perform the steps on the sender's behalf). The terminal is typically a mobile terminal or handset, but may also be a fixed landline terminal. Upon opening this delivery application, the customer is ideally presented with initial options to send or collect a parcel. In this instance, since a parcel is to be sent, the customer would select the "send" option (20). The application would then prompt the sending customer to enter an identifier (e.g. a code) corresponding to the dispatch agent (21). The dispatch agent is the agent that the sender has selected to drop off the parcel to for pick up by the delivery company. Preferably the application also prompts the sending customer for an identifier (e.g. a code) corresponding to the delivery company that has been selected to manage the physical delivery of the parcel (22). The inclusion of this step enables the sender to have a choice of delivery agents (although there may only be one possible delivery agent). This step is also useful for the dispatch agent, where the dispatch agent acts as a pick up point for multiple delivery companies, as it enables them to readily distinguish between them. In this regard it is of course important that the parcel is passed to the correct courier.

The application then prompts the customer to enter an identifier of the intended parcel recipient. Preferably this is the parcel recipient's mobile number (23). The managing entity will utilise this number to communicate with the intended recipient to notify them of the parcel to be delivered and arranging for a collection location to be selected. Importantly, this recipient identifier (e.g. mobile number) is also associated with the intended recipient's network account that will also be used for verification of the intended recipient's identity. In other words, for the intended recipient to participate in this approach, they need a secure network account (e.g. M-PESA) which is verifiable with a PIN and which is associated with a particular SIM (i.e. with its own unique phone number/MSISDN). The application then prompts the customer to enter the payment amount (24). Typically this is determined at the dispatch point, and is variable depending upon factors such as the destination of the parcel, the delivery company used and any applicable commission rates. The application then prompts the customer to confirm the transaction (25) by entering a secure/secret personal identifier, preferably being a PIN associated with their network account (e.g. M-PESA).

All the entered information regarding the different entities involved in the delivery procedure is then processed in order to create the delivery transaction. This processing may be undertaken by a single management entity which is authorised to manage the M-PESA network account payments/authorisation aspect, as well as the delivery aspect. Alternatively, separate entities (e.g. a network account management entity and the designated delivery company) are used to process the different components, which is the approach that is taken with this embodiment of the invention, since the network account processing requires access to some sensitive information (e.g. the account PIN).

In this regard, the network management entity that is responsible for the M-PESA network accounts confirms the sender's PIN, and collects the required payment from the sender's M-PESA account. This money is ideally moved to a holding account for distribution of the necessary funds when the delivery process is, or stages thereof are, completed. Alternatively, the money may be pre-allocated to the relevant parties' accounts within the system (e.g. the dispatch and collection agents), but no party is able to access them until the transaction is completed in its entirety, or at least until each party completes their part of the procedure. When the payment is collected from the sender, and the funds are being held "in trust" the delivery transaction is considered to be created and to enter a pending "authorised state". This state will change to a "complete" state when the delivery is successfully completed, and all applicable parties have been paid for their services. These states are useful for communicating the status of each delivery between the delivery companies and the network management entity, the latter having the ultimate responsibility for the overall process. In addition to the monetary management aspect, the network management entity also checks to see if the recipient has any outstanding deliveries and assigns the new parcel a sequential number that is indicative of the number of outstanding deliveries for that recipient. It is preferable that the network management entity performs this step, as, where multiple delivery companies are being used, it has access to information on deliveries from various different delivery companies to the intended recipient.

This check enables a recipient to have more than one parcel in the process. For example, if no deliveries are outstanding the parcel is assigned a tag of value "0". If there are outstanding deliveries a parcel tag of value n+1 is created. This number is sent to the dispatch agent for marking on the parcel itself. (Note that this value is different to the unique parcel number which is created by the delivery company, as described further below.)

With the network management entity having confirmed the payment aspect of the transaction, it sends a message (e.g. an SMS) to the dispatch agent. The sender also preferably receives a corresponding message from the network management entity. An example SMS sent to the dispatch agent could be of the form:

"Payment received of {payment value} from {sender MSISDN} to be sent to {recipient MSISDN} with parcel tag {tag number}."

This enables the agent to confirm the payment amount as correct and to mark the parcel with a personal identifier of the recipient (e.g. their MSISDN) and the tag number. The parcel is then ready for collection by the courier/delivery company. It is to be appreciated that the recipient's mobile number is effectly the new postal address, and would typically be marked on the parcel by the sender. Courier companies will not pick up parcels without this information. The network management entity additionally enters the delivery transaction into a system accessible by the delivery company so that the delivery company can confirm and process the delivery aspect of the transaction. This system is preferably located on a server associated with the network management entity to which each delivery company has their own section that they can log in to in order to see delivery transactions/jobs that are applicable to them. It is also preferable that this system is associated with the M-PESA account system, as this would simplify the monetary transfer between accounts.

The creation of a delivery transaction on the remote system essentially serves as a notification to the applicable delivery company of a new job. To access this information, an authorised user of the delivery company logs into the front end platform using their username, password and company name. A successful log in will land the user in the business account management section for their company, which will include an indication of new and pending delivery jobs being managed by the company. This ideally shows the user all of their pending transactions in an "authorised" state, and lists the MSISDN of the sender and the recipient. This interface is also usable by the delivery company to mark transactions as complete once delivery has been finalised and as confirmation that the necessary commissions to the agents have been released. The network management entity has access to this information so that they too are aware of the respective delivery statuses. The interface can also enables the delivery company to determine:

o costumers who have paid to send a parcel but whose requests have not been processed;

o customers who have been processed but have not confirmed their agent collection point;

o customers who have confirmed their pick up point but not collected their parcel; and

o successful completed deliveries.

This information can be presented in the form of adhoc reports provided over a specific time period, and list details such as date the current status was entered.

Where a job is listed on the interface as a new job, a confirmation step is preferably included in the transaction procedure to ensure that the delivery company has a right of veto over the job, in case they are unable to fulfil the job, for instance. In most instances, however, the delivery company will confirm the delivery job, and create a unique parcel number associated with the delivery. The delivery company will then send a confirmation message (e.g. an SMS) to the intended recipient notifying them of the pending delivery, sending the unique parcel number and requesting them to nominate/confirm a collection agent from which to collect the parcel.

Collection Point Determination

The collection location for the parcel may be determined in a number of ways, including:

i) by the sender nominating a collection agent. This option is suitable where the sender has a good knowledge of the recipient's location, and can be implemented by the sender entering an identifier (e.g. a code) for the collection agent at the time of arranging the delivery. Where this option is implemented, the delivery company may notify the intended recipient of the same and given them the option of altering it, if desired; and

ii) by the recipient nominating a collection agent once the delivery procedure has been initiated. It is this option that is being utilised in the present embodiment of the invention, and which will be further described in relation to Figure 3.

In this regard, with reference to Figure 3, upon the intended recipient being notified that a parcel is to be delivered to them (e.g. by a confirmatory email sent by the network or the nominated delivery company), the intended recipient will open the delivery app on their mobile terminal (31) and go to the "collect parcel" menu option. It is to be appreciated that this application is linked to the intended recipient's network account (e.g. M-PESA) and in fact the delivery functionality may be incorporated as another operation of the M-PESA phone app. This phone app would typically be configured to communicate with a remote server associated with the M-PESA system via USSD (Unstructured Supplementary Service Data), for instance. In the "collect parcel" section, the intended recipient will be prompted to enter their unique parcel number (32). As indicated above, typically the intended recipient will be notified of their parcel number in a confirmation message sent by the delivery company. As this delivery procedure is linked to the network account system, the intended recipient is also prompted to enter the PIN number (33) for their M-PESA network account. Additionally, as the intended recipient's mobile terminal will typically have an active communication session with the telecommunications, network, the intended recipient's SIM will be registered with the network and accordingly the network will know a unique identity associated with that SIM, such as the MSISDN/IMSI. The network can therefore be configured to provide this unique ID to the stored value account system (or equivalently confirmation of an ID provided by an M-PESA server as the correct ID), as a verification of the intended recipient being in physical possession of the SIM, which is associated with the M-PESA account, and was the entity to which the parcel number was communicated.

The system will then validate the data combination of the customer's PIN, parcel number as well as, optionally, their MSISDN (34) (the system typically will determine the MSISDN from the communication session established between the user's SIM and the network server).

Where the data is valid (e.g. where the PIN, MSISDN and parcel number match for the intended recipient), then an agent for collection of the parcel needs to be confirmed. The application therefore opens up an appropriate menu on the user's terminal to enable this to be effected. This menu may prompt the intended recipient to enter and/or determine the desired agent collection point (35) (e.g. a code designating the desired collection agent).

Where an intended recipient does not know the code for a proximate collection agent, or wishes to view other alternatives, for example, the desired agent "determination" option may be selected. Upon the selection of this option, the application may be configured to then present to the intended recipient: o one or more agents that the customer most frequently uses. This option is the most preferable, and is implemented through the use of a database that monitors the customer's transactional data;

o one or more agents that are the most proximate to the user's registered home location. This option accesses a pre-designated home location of the user (e.g. for their M-PESA account registration), as well as a database of available collection agents and selects one or more of those available agents that are proximate to that home location (e.g. those within a predetermined range of the home location);

o one or more agents that are the most proximate to the user's current location, as determined with reference to the telecommunications network (e.g. based on serving base station location); or

o one or more agents that are the most proximate to the user's current location, as determined based upon their current GPS devised co-ordinates.

Where the present invention is linked with the existing M-PESA system, which heretofore has been used for enabling deposits and withdrawals of money, the suggestion of agents may be in regard to those agents for whom the intended recipient typically uses in regard to cash deposits and/or withdrawals. In this situation, the customer transaction data is ideally analysed in order to ensure that only agents are suggested that are registered to take part in parcel delivery, as well as cash transactions (as not all agents in the M-PESA system may be implementing the present parcel delivery service). In this scenario, should the intended recipient's most frequently used agent not be a participant in the parcel delivery system, then the application could suggest one or more alternative agents, preferably being ones that are closest to the most frequently used agent.

The application also preferably has an override procedure in regard to this suitable agent determination procedure, whereby, should the user not consider any of the suggested collection agents to be appropriate, the application enables the user to enter an identifier of the agent from which they would like to collect the parcel. Once an appropriate collection agent has been designated, a message will be sent to that agent seeking confirmation that they would accept the job. Upon receiving this confirmation, the delivery setup is complete (36). Where the collection agent data is not valid, the network server may terminate the communication session and display an error message (37).

Figure 4 illustrates an example of the network infrastructure that may be utilised to implement the customer-initiated collection agent determination procedure, such as outlined in Figure 3. In particular, to determine the suggested collection agents at step 35, the mobile terminal may use a USSD communication, sent via a USSD Gateway of the mobile network operator domain, to obtain the necessary suggestions from an integration server associated with the M-PESA system. A USSD service server would receive the message from the USSD gateway, and the analysis to dynamically determine one or more suggested collection agents performed by software associated with the mobile menu database. This software in turn accesses a database of customer transactional data, which includes data relating to most frequently used agents.

Upon the integration server sending the agent suggestions back to the mobile terminal via the same USSD route, where the user selects a particular agent, this selection is communicated back to the integration server, again using USSD. The inbound USSD request is then forwarded by the integration server to the selected agent to obtain their response. This message is sent via a message forwarding system of the core telecommunications network. The agent confirms their participation in the delivery by sending their confirmation message, which is sent back to the integration server of the M-PESA system, via the message forwarding subsystem. The integration server uses a message multiplexer to transform this confirmation message into an SMS message for forwarding to the user's mobile terminal/SIM via the SMS infrastructure of the mobile network.

Parcel Collection

Once all parties to the delivery process are in place, the delivery company is then in a position to commence the physical delivery (although there is an option for the delivery company to pick up the parcel before the collection agent has been finalised).

Once the delivery company has picked up the parcel from the dispatch agent, that agent has fulfilled their part of the transaction. Accordingly the dispatch agent may receive their commission once this occurs. In this regard, the necessary funds are moved from the holding account to the dispatch agent's fund account (e.g. their M-PESA account). Alternatively, the funds may be held in the holding account until the entire delivery process has been completed, although this is obviously less preferable to the agents. The value of the commission paid is typically set by a pre-designated tariff.

The delivery company will then effect delivery of the parcel to the collection agent. Once this occurs, a notification (e.g. an SMS) is ideally sent to the recipient notifying them of such. This notification may be sent by any suitable party, including the collection agent or the delivery company. The intended recipient will then need to visit the collection agent's store in person in order to collect the parcel. The recipient will have been provided with the unique parcel number by the delivery company, typically in an SMS to their mobile number.

To complete the delivery under the control of the managing system, with reference to Figure 5, the intended recipient provides the agent with a personal identifier, such as their mobile number. The agent will utilise this information (together with the tag number which is given to the agent by the delivery company) to physically locate the parcel. The agent will then access the M-PESA delivery application on their terminal, and go the parcel collection menu option (50). They will be prompted to enter the parcel number (51) and the recipient's mobile phone number (52). The network server will then confirm if this combination is valid or not (53). The network server will also verify that, in addition to the intended recipient having the required verification knowledge (i.e. knows the parcel number), that the are physically in possession of verification data (i.e. the network SIM card liked to the M-PESA account). The network will perform this verification using its standard security registration procedures (e.g. as performed when implementing a communication session). The users may also be asked to enter their M-PESA pin as further validation of their identity, but this is not essential.

As a still further confirmation (or even alternative confirmation), the network server may verify that the intended recipient and the agent are in the same location such as by:

i) checking that the mobile terminals of the intended recipient and the agent are using the same base station, or at least neighbouring base stations;

ii) obtaining GPS coordinates of the intended recipient's mobile terminal, and confirming these against corresponding GPS coordinates of the agent's handset (i.e. so that they at least substantially match). The agent's GPS coordinates may be determined in real time or be held in a database);

iii) using USSD verification. In this regard USSD (Unstructured Supplementary Service Data) is a real-time protocol which GSM mobile terminals use to communicate with their networks. It could be used for present purposes by the customer's mobile number into the menu on the agent's handset. Upon receipt of this information, the network can generate a USSD menu on the intended recipient's phone, which is used to receive the intended recipient's unique code.

Where the verification is valid, notification is sent to the agent of such (54), giving the agent authorisation to give the package to the recipient.

The completion of the delivery enables the transaction in the management system to be updated from the "authorised" state to the "complete" state. This update may be manually entered into the delivery company's front end interface and/or automatically by the M-PESA system upon validating the recipient's details at the collection point. As the agent receives the parcel number from the customer, fraud is not possible. Upon the transaction being completed, the funds being held in the holding account are made available to the relevant parties requiring remuneration (55) (e.g. the delivery company and the collection agent). More particularly, where the M-PESA system is utilised, these funds will be released into each parties' M-PESA account.

It is also to be appreciated that if any of the verification steps are not valid (e.g. the parcel number/recipient identifier combination), no collection authorisation is given. Also, it is possible in this situation that no commissions will be paid to some or all of the parties involved in the delivery service as well. In this instance, the network server would typically issue a failure message (56) to the collection agent's terminal, directing the customer to contact their customer service provider.

Figure 6 illustrates an example of the network infrastructure that may be utilised to implement the agent initiated parcel collection procedure, such as outlined in Figure 5. More particularly, upon the collection agent obtaining the prospective recipient's mobile number and parcel number, the agent enters this information into their M-PESA terminal, and it is sent to the integration server associated with the M-PESA system via the mobile network operator. Preferably this information is sent via a secure SMS. At the integration server, this secure SMS is received by an SMS Service component.

Also, it is to be appreciated that on the collection agent's terminal, where it is already set up for M-PESA no new hardware need be created, and that the existing software, with some menu adaptations (e.g. to allow entry of the customer's mobile phone number and parcel number), can be reutilised.

When the SMS is received at the integration server, it passes through a message multiplexer to a message forwarding subsystem, before being forwarded to a M- PESA core server, where a transaction processor determines whether the phone number/parcel number combination are valid. This validation is performed with reference to a database associated with the M-PESA core server. It is appreciated that in this example, the M-PESA server is separate to the integration server, but alternatively the two may be combined. When the validation is complete, the M_PESA core server sends the result back to integration server, using a message forwarding subsystem. At the integration server, the result message is sent to the collection agent's terminal, via the mobile network infrastructure, as an SMS message.

The embodiments that have been described so far embody the key aspects of the invention, particularly in regard to the synergistic combination of a unique telecommunications network identifier of the intended recipient to the physical entity being delivered that not only enables a unique identifier of the physical entity to be sent to the intended recipient, but which can also be used to securely and confidently verify the identity of the intended recipient in relation to that delivered physical entity. Variations however are possible from what has been described so far, for example, the creation of the delivery transaction need not be initiated by the dispatch agent, but may alternatively be created by the delivery company. In this regard, an authorised user of the delivery company may log into their company's front end interface using the appropriate username and password. A successful log in will land the user in the business account management section for their company, which will include an option to "create a delivery". This approach would typically be used when the sender does not utilise the M-PESA system to initiate the delivery and a delivery request has been received by email, for example, from a given merchant). The "create a delivery" option typically would prompt the user to enter the recipient's mobile number and the sender's contact details

In addition to allowing the delivery company to create a single delivery, the delivery creation option, may also enable multiple deliveries to be imported and processed. In this regard, selecting the option to import multiple deliveries would allow the user to browse files and upload a file (e.g. a csv file) containing mobile numbers of multiple would-be recipients, thereby enabling the user to process multiple deliveries from that one sender at once. Similarly, selecting the option to process multiple delivers would typically present to the user multiple mobile numbers of customers that have made a payment to the delivery company and whose deliveries have not already been processed. The user can select any or all of these to process, whereby processing will generate, for each transaction, a unique parcel number, a tag number, and a message to the intended recipient notifying them of the pending delivery. The processing will also ideally validate the recipient's mobile number to ensure that it is a full number with the correct country code. An example of such a message, which typically will be sent by SMS, is:

Sender {Name} has sent you a parcel using {Delivery Company Business Name}. Please confirm your collection point using your M-PESA menu and this parcel number {parcel number} . You have multiple parcels to collect, and this one is numbered {tag number} .

The senders may have dropped their parcels off with the delivery company, or the delivery company may need to pick up the parcel from a merchant. In both instances, the delivery company will need to check to ensure that the parcels are all marked with the recipient's MSISDN, and tag number.

In previous embodiments, the sender of the parcel has been responsible for paying for the delivery procedure. However, this is not essential to the invention. In this regard, with reference to Figure 7, an alternative embodiment of the invention is described, whereby the intended recipient takes responsibility for at least part of the payment. The sender of the parcel typically initiates the delivery procedure (70). This may be when the sender takes the parcel to a dispatch agent, or contacts the delivery company directly (e.g. via an internet trader or the delivery company's internet portal). In this regard, the sender will provide details of the intended recipient including their MSISDN number (71). Where this procedure is being performed from the dispatch agent's premises, the procedure can proceed in a similar manner to that described in relation to Figure 2, except payment is not taken from the sender's account (or alternatively, part of the payment may be taken from the sender's account, and the rest sought from the intended recipient). Instead, where payment is expected from the recipient, the value of this expected payment is determined (72). This amount could be just the cost of delivery or could alternatively also include the cost of the item being delivered. The amount may be derived from information provided by the sender, a merchant (e.g. an internet trader) and/or the delivery company when creating the delivery event.

The delivery company will then create a unique parcel number attributable to the item being delivered (73) and a notification message sent to the intended recipient (74) that contains this parcel number. This notification message may also identify the sender of the parcel, and request payment to effect the delivery. It may also nominate a collection agent from which to pick up the parcel.

Upon receiving this notification message (e.g. via SMS), the intended recipient may then confirm the collection agent they would like the parcel to be delivered to (75), where requested. The procedure in this regard may proceed in a similar manner to that described in relation to Figure 3 with the intended recipient confirming their preferred collection agent for the parcel number. An addition to this procedure, however, is that authorisation is also requested to collect the expected payment from the intended recipient's account (76). This authorisation may be obtained once the customer has confirmed their preferred collection point, and is typically obtained by the intended recipient entering their network account PIN (e.g. M-PESA account) to a payment prompt. If the PIN is correct (77), their account is debited (78) and the delivery entry will enter a pending "authorised" state (79). This may require the delivery company instructing the sender to drop off the parcel at the dispatch agent (if this has not already occurred) or just notifying that the sender that the delivery initiation has been finalised and the parcel will be collected from the dispatch agent. Once the transaction enters this "authorised" state, and the recipient's account debited, the appropriate payment is made to the delivery company and also possibly to the dispatch and collection agents (except where the delivery company manages their commissions), although these funds are not accessible until the transaction has been completed. Also, where an Internet trader is involved, that entity may also receive a payment in a similar manner at this point.

Where the delivery company manages the agents' commissions, these will be paid to the dispatch agent upon collection of the parcel.

In another variation, rather than the intended recipient nominating the collection point, this is specified by the sender of the parcel. This would be particular useful where a mail order company has already collected the details of the preferred collection point for the recipient. This embodiment could be initiated in the same manner as was described in relation to Figure 2, with the app being utilised to enter the dispatch agent's code (21), the delivery company's code (22) and the parcel recipient's mobile number (23). In addition, however, an option is included in the app to ask the sender if they would like to specific the pick up location. If the sender selects "yes", then the app prompts the sender to enter an identifier (e.g. a code) for the collection agent. The app would then proceed in the manner described in relation to Figure 2 for entering payment (24) and verifying the sender by PIN (25) etc. Further, upon the transaction being verified, a message (e.g. SMS) could be sent to the dispatch agent as follows:

"Payment received of {payment value} from {sender MSISDN} to be sent to {Recipient MSISDN} with parcel tag number {tag number} ." When the delivery company collects the parcel from the dispatch agent, the courier collecting the parcel ideally has a mobile terminal with an M-PESA app that has a menu option to "process parcel". This menu option requires the courier to, upon picking up the parcel, enter the intended recipient's MSISDN, the tag number and the dispatch agent' short code. The courier will also be required to enter his own M-PESA PF as confirmation that the correct courier is collecting the parcel. This procedure makes it possible to provide parcel tracking services so that the recipient and/or sender can follow at what stage their parcel is at. It is also to be appreciated that this collection procedure from the dispatch agent may be performed by a separate courier on behalf of the delivery company. Where this occurs, the same procedure is performed, although the delivery company will additionally provide a commission to the courier once the parcel is collected or handed over to the delivery company. In this regard, the delivery company's front end system will include a menu option for processing parcels dropped off at their depot by such couriers. For instance, to confirm the parcel depot drop off, the depot will enter the courier's MSISDN, the intended recipient's MSISDN and the tag number (the latter both labelled on the parcel). The parcel is then linked with the previously created "authorised" transaction on the delivery company's system.

Further, one or more different couriers could then be used to handle the delivery of the parcel from the delivery company's depot to the collection agent, and for each of these couriers, a similar procedure would be utilised in regard to their usage of the M-PESA app on their respective mobile terminal. Again, the M-PESA app and its ability to log collections/drop offs would enable tracking of the parcel to the eventual collection agent.

The embodiments of the invention that have been described are to be taken as illustrative of the invention and not limitative, to the extent that changes and additions are possible.

Furthermore, the exact order of the steps as described and defined is not essential, and can be varied as required. In addition, singular references do not exclude a plurality. Also, although individually listed, a plurality of means, elements or method steps may be implemented by, for example, a single unit or processor. Additionally, the term "comprising" does not exclude the presence of other elements or steps. Further, the embodiments have generally described the procedure under which a successful delivery takes place. If however the delivery does not take place, for instance if the parcel is not collected from the sending agent or the collection agent, then the network server may also include a feedback loop for the sender to notify them of such after a certain period of time elapses. For example, should a transaction not be completed within 7 days (e.g. if the intended recipient does not confirm a collection point for a parcel), then the transaction could be automatically cancelled and the funds returned from the holding account.

Overall, it is to be appreciated that the methods provided in the present invention may be implemented by any suitable means, including in a computer program, software, or firmware tangibly embodied in a computer readable storage medium for execution by a general purpose processor. Examples of computer readable storage mediums include read only memory (ROM), a random access memory (RAM), a register, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media and optical media such as CD ROM disks and digital versatile disks (DVDs). Other features of the invention are set out in the following numbered paragraphs:

1. A method of utilising a mobile telecommunications network for delivering a physical entity from a first location to a second location and enabling collection of the physical entity by an intended recipient, the second location being associated with the intended recipient, and the method including:

determining a mobile telecommunications identifier associated with the intended recipient;

associating a unique entity identifier with the physical entity; and

using the mobile telecommunications identifier to notify the intended recipient via the mobile telecommunications network of the unique entity identifier, such that the intended recipient is able to collect the physical entity from the second location upon verifying their possession of the unique entity identifier and verifying the intended recipient's identity, which includes a verification associated with their mobile telecommunications identifier.

2. The method of paragraph 1 wherein the intended recipient additionally is an authorised user of an account associated with the mobile telecommunications identifier and the verification associated with the mobile telecommunications identifier includes:

verifying the intended recipient as the authorised user of the account. 3. The method of paragraph 2 wherein the intended recipient is verified as the authorised user of the account upon entering a PIN.

4. The method of any one of paragraphs 1 to 3 further including determining the second location by transmitting a message to the intended recipient including information identifying one or more collection agents that may be suitable.

5. The method of paragraph 4 wherein the one or more collection agents that may be suitable are determined by:

determining one or more collection agents previously used with a stored value account associated with the intended recipient's mobile telecommunications identifier; and/or

determining one or more agents that are proximate a geographic location associated with the mobile telecommunications network smart card associated with the mobile telecommunications identifier; and

enabling selection of one of the one or more determined collection agents as the second location for delivery of the physical entity.

6. A system configured to utilise a mobile telecommunications network for enabling the delivery of a physical entity from a first location to a second location and enabling collection of the physical entity by an intended recipient, the second location being associated with the intended recipient, and the system including processing means configured to:

receive a mobile telecommunications identifier associated with the intended recipient;

determine a unique entity identifier to be associated with the physical entity; and use the mobile telecommunications identifier to notify the intended recipient via the mobile telecommunications network of the unique entity identifier, such that the intended recipient is able to collect the physical entity from the second location upon verifying their possession of the unique entity identifier and verifying the intended recipient's identity, which includes a verification associated with their mobile telecommunications identifier.

7. The system of paragraph 6 further configured to:

receive connection data from an agent at the second location, the collection data including the mobile telecommunications identifier and the unique entity identifier;

compare the received collection data with correct delivery data associated with the system; and

provide the agent with identity confirmation data, confirming whether or not the collection data was valid.

8. The system of paragraph 6 or 7 wherein the intended recipient additionally is an authorised user of an account associated with the mobile telecommunications identifier and the system is further configured to receive a PIN as part of the collection data, and additionally verify the PIN as part of the collection data comparison.

9. The system of any one of paragraph 6 to 8 wherein the processor is further configured to determine the second location by transmitting a message to the intended recipient including information identifying one or more collection agents that may be suitable.

10. The system of paragraph 9 wherein the processor is configured to:

determine the one or more collection agents that may be suitable by:

determining one or more collection agents previously used with a stored value account associated with the intended recipient's mobile telecommunications identifier; determining one or more agents previously used by the intended recipient for parcel collection;

determining one or more agents that are proximate a registered home location associated with an account of the intended recipient; and/or

determining one or more agents that are proximate a geographic location of a mobile telecommunications network smart card associated with the mobile telecommunications identifier;

such that the intended recipient is able to select one of the one or more determined collection agents as the second location for delivery of the physical entity or nominate an alternative collection agent.

11. The system of any one of paragraphs 6 to 10 wherein one or more parties involved in the delivery, including a sender of the physical entity, the intended recipient and agents at the first and second locations, have stored value accounts with the mobile telecommunications network which accounts are used to pay and remunerate for the delivery, as applicable.

12. The system of paragraph 11 which is associated with an account system to which the stored value accounts belong.

13. The system of any one of paragraphs 6 to 12 wherein the mobile telecommunications identifier is a phone number of the intended recipient.

14. In the delivery of a physical entity from a first location to a second location, an application for use on a portable terminal for enabling the verification of the identity of an intended recipient of the physical entity at the second location, the method including:

obtaining a mobile telecommunications identifier associated with the intended recipient;

obtaining a unique entity identifier of the physical entity from the intended recipient; and sending the unique entity identifier and the mobile telecommunications identifier to a remote authorisation server for verification that the sent data matches; and

receiving confirmation of the result of the verification, which enables a user of the application to release the physical entity to the intended recipient where the sent data is positively verified.

15. The application of paragraph 14 wherein the intended recipient additionally is an authorised user of an account with the mobile telecommunications identifier and the method further includes:

upon the intended recipient collecting the physical entity from the second location, additionally verifying the intended recipient as the authorised user of the account. 16. A method of enabling collection of a physical entity by an intended recipient, for use with an arrangement including a stored value account system associated with a mobile telecommunications network, such that the intended recipient is an authorised user of a stored value account associated with a smart card that is usable in the mobile telecommunications network, the method including:

enabling the intended recipient to collect the physical entity from a collection location upon a verification of the intended recipient's identity by using the mobile telecommunications network to verify the intended recipient's physical possession of the smart card.

17. The method of paragraph 16 wherein the verification of the intended recipient's identity includes the mobile telecommunications network obtaining a unique identity from the smart card and forwarding the unique identity to a controller of the stored value account to verify that the unique identity matches a corresponding unique identity associated with the stored value account.

18. The method of paragraph 16 or 17 further including: determining the unique identifier associated with the smart card from the stored value account;

associating an article identifier with the physical entity;

using the unique smart card identifier to notify the intended recipient via the mobile telecommunications network of the article identifier; and

enabling the intended recipient to collect the physical entity from the second location upon a further verification verifying their possession of the article identifier. 19. The method of any one of paragraphs 16 to 18 further including:

associating a unique entity identifier with the physical entity; and using the mobile telecommunications identifier to notify the intended recipient via the mobile telecommunications network of the unique entity identifier, such that the intended recipient is able to collect the physical entity upon additionally verifying their possession of the unique entity identifier.

20. The method of any one of paragraphs 16 to 19 wherein the verification further including verifying the intended recipient as the authorised user of the account upon entering a PIN.

Claims

CLAIMS:

1. A method of enabling collection of a physical entity by an intended recipient, used with an arrangement including a stored value account system associated with a mobile telecommunications network, such that the intended recipient is an authorised user of a stored value account which is associated with a smart card usable in the mobile telecommunications network, the method including a network entity of the stored value account system:

receiving payment for the delivery of the physical entity;

upon receiving a collection request for the physical entity, verifying the intended recipient; and

upon positively verifying the intended recipient, releasing the at least part payment via the stored value account system to the one or more service providers.

2. The method of claim 1 wherein the identification information received is also associated with the mobile telecommunications network smart card and the verifying step includes using the mobile telecommunications network to verify that the intended recipient is in physical possession of the smart card.

3. The method of any one preceding claim wherein the payment for the delivery of the physical entity is received from the intended recipient's stored value account and held in a trust account associated with the stored value account system until the physical entity is delivered and collected.

4. The method of any one preceding claim wherein the payment for the delivery of the physical entity includes monies due to a plurality of different service providers in the delivery procedure, the method including releasing the monies due to each of the plurality of service providers upon each service provider completing their part of the delivery procedure.

5. The method of claim 4 further including releasing the monies due to each of the plurality of service providers into stored value accounts belong to each of the service providers.

6. The method of any one preceding claim further including:

associating a unique entity identifier with the physical entity; and

using the mobile telecommunications identifier to notify the intended recipient via the mobile telecommunications network of the unique entity identifier, such that the intended recipient is able to collect the physical entity upon additionally verifying their possession of the unique entity identifier.

7. The method of any one preceding claim wherein the verification further including verifying the intended recipient as the authorised user of the account upon entering a PIN.

8. An arrangement including a stored value account system associated with a mobile telecommunications network configured to enable collection of a physical entity by an intended recipient, such that the intended recipient is an authorised user of the stored value account which is associated with a smart card usable in the mobile telecommunications network, the arrangement further including a network entity configured to:

receive payment for the delivery of the physical entity;

reserve at least part of the payment to one or more service providers pending successful delivery of the physical entity to the intended recipient;

receive identification information for the intended recipient that is associated with the stored value account;

9. The arrangement of claim 8 wherein the identification information received by the network entity is also associated with the mobile telecommunications network smart card and the network entity is further configured to use the mobile telecommunications network to verify that the intended recipient is in physical possession of the smart card.

10. The arrangement of claim 8 or 9 further including a trust account associated with the stored value account system which is configured to receive and hold payment for the delivery of the physical entity until the physical entity is delivered and collected.

11. The arrangement of any one of claims 8 to 10 wherein the payment for the delivery of the physical entity includes monies due to a plurality of different service providers in the delivery procedure, and the network entity is further configured to release the monies due to each of the plurality of service providers upon each service provider completing their part of the delivery procedure.

12. The arrangement of claim 11 wherein at least one of the plurality of different service providers have respective stored value accounts, and the network entit is further configured to release the monies due to each of these service providers into the respective stored value accounts.

13. The arrangement of any one of claims 8 to 12, wherein the network entity is further configured to:

determine a mobile telecommunications identifier associated with the intended recipient;

associate a unique entity identifier with the physical entity; and

use the mobile telecommunications identifier to notify the intended recipient via the mobile telecommunications network of the unique entity identifier, such that the intended recipient is able to collect the physical entity upon additionally verifying their possession of the unique entity identifier.

14. The arrangement of any one of claims 8 to 13 wherein the network entity is further configured to perform the verification by verifying the intended recipient as the authorised user of the account upon entering a PIN.