GB2455812A

GB2455812A - Method and system for authenticating delivery of goods

Info

Publication number: GB2455812A
Application number: GB0725148A
Authority: GB
Inventors: Marcus Maxwell Lawson; Alan Betteridge
Original assignee: First Ondemand Ltd
Current assignee: First Ondemand Ltd
Priority date: 2007-12-21
Filing date: 2007-12-21
Publication date: 2009-06-24
Also published as: WO2009081149A1; GB0725148D0

Abstract

Goods ordered on-line, or remotely, are assigned a goods identification token which contains a unique identifier. The recipient of the goods is assigned a recipient identification token which also includes a unique reference. At the point of delivery, both tokens are scanned and the delivery is authenticated only if the tokens form a matching pair. In one embodiment the recipient can further secure the verification process by use of a Security Code value which can be validated on or offline.

Description

METHOD AND SYSTEM FOR AUTHENTICATING DELIVERY OF

GOODS

This invention relates to methods and systems for authenticating delivery of goods. It is particularly, but not exclusively, concerned with delivery of goods to the correct recipient.

In recent years, on-line shopping has become increasingly popular, and that popularity is projected to increase dramatically in coming years.

Typically, goods are ordered and paid for on-line and then delivered to the recipient at an address given by the recipient during the on-line transaction. This address may be that of the purchaser or a trusted third party. Payment is made when the order is placed and is typically by credit or debit card and is an example of a transaction type known as cardholder not present'.

Cardholder not present' transactions have been used for many years and in some forms, for example mail order services, operate in a very similar manner to on-line shopping in that goods are delivered to an address that has been provided by a purchaser and payment is made in advance from a location remote from the goods provider.

Typically, when goods are delivered, the recipient is required to sign for them to acknowledge receipt. This signature has little security value as the delivering party, which is often a contracted third party, has no mechanism for checking the authenticity of the signature. At best, the signature provides little more than an indication that the goods were delivered by the delivery company to a party who purported to be the addressee.

Fraud with customer not present transactions' is endemic and is categorised as friendly fraud to distinguish it from the use of counterfeit credit cards which is also a significant problem. Friendly fraud exploits weaknesses in the security of the delivery chain and exists in a number of forms. These include the interception of goods by a person falsely claiming to be the intended recipient. Here the bogus recipient will claim to be the intended recipient and take delivery of the goods and sign for them if required. As the signature is not authenticated, the false identity will not be detected. Another example is claimed non-delivery of goods where the recipient maintains falsely that the goods were not delivered or that they were not the person who signed for the goods. In this latter case the supplier is obliged to re-send the goods. It is common for goods falsely obtained to be returned to the supplier for a refund so enabling the bogus recipient to obtain cash payment for the value of the intercepted goods. In the case of alleged non-delivery is also common for goods to be returned to a supplier other than the one from which they were purchased.

There are many other aspects to fraud relating to the delivery of goods purchased remotely. Suppliers lose a significant amount of revenue to this type of fraud and also have to carry the administrative overhead of handling genuine enquiries from customers where goods have been intercepted, and fraudulent claims from customers pretending not to have received goods.

In the past, attempts have been made to introduce signature verification systems which would be used at the point of delivery, but these have not been successful. Signature verification is particularly difficult in an off-line system such as would typically be used by a delivery company as it requires very significant computer processing. Moreover, it requires a specimen signature from every possible recipient to work. This is not practical.

There is therefore a need to provide a method and system which can improve the security of goods delivery in a practical manner and which can reduce losses due to fraud.

S

The present invention therefore aims to meet this need and to provide a method and system which can increase the security of goods deliveries and reduce losses due to fraud and which can easily be integrated into conventional modes of goods delivery.

Broadly, the invention provides a pair of tokens which link goods to a recipient. One of the tokens is a goods token and the other is a recipient token. At the point of delivery, data in the tokens is compared, preferably after some processing, to determine whether the tokens match. If there is a match, the delivery is authenticated.

In another aspect of the invention, a pair of tokens is provided. A security code from one entity is encrypted into a token provided to a second entity.

The relationship between the two entities is authenticated by recreation of the encrypted security code from a code provided by the first entity and a unique identifier contained in a first entity token.

More specifically the invention is defined by the independent claims to which reference should be made.

Embodiments of the invention have the advantage that fraud caused by interception of goods, or alleged non-receipt of goods can be reduced, thereby saving retailers significant amounts of money.

Preferably, the recipient enters a security code such as a PIN when ordering the goods. During creation of the token pair, this security code is encrypted in the goods identification token as a value determined by hashing the security code with a unique identifier for the recipient identification token. The encryption uses a public key related to a private key held at the token creation point and is used to encrypt data in the token pair. At the point of delivery, the recipient enters their security code into a PDA or other device which scans the goods identification token and the recipient identification token. The unique identifier is extracted from

S

the recipient identification token and hashed with the security code using the same public key. This hashed value is then compared with the encrypted value of the security code held in the goods identification token.

The two values are compared and, if they match, delivery can be verified.

This preferred embodiment of the invention has the advantage that the comparison of the token pairs can take place remotely and be performed by a device that does not need to refer back to the system that generated the tokens. It can therefore be performed off-line. Because the security value is encrypted within the goods identification token there is no need to store security codes on the device.

Embodiments of the invention will now be described, by way of example only, and with reference to the accompanying drawings, in which: Figure 1 is an overview of the method and system embodying the invention; Figure 2 is a similar view to figure 1 of an alternative embodiment of the invention; Figure 3 is a schematic diagram showing the creation and authentication of a token; and Figure 4 is a flow chart showing steps performed in the.

authentication process.

Referring to Figure 1, an outline of the method and system embodying the invention will first be described.

Figure 1 shows an on-line retailer 10 which takes orders from a customer 20. As well as details of the goods, the customer will supply payment details and a delivery address to the on-line retailer at 10. In the example given, the goods are ordered on-line and communication between the retailer and customer is on-line but the invention may also be embodied in an off-line system such as a mail order system which the customer

S

communicates with the retailer by telephone or mail, or where goods are to be collected from a pick up point or purchased for later collection.

On receipt of the customer order, the on-line retailer sends a communication to the customer, at 30, which confirms the order. This may be sent, for example, by fax or email. In the off-line example this may be by fax or mail or by text message. Details of the goods and the delivery address are then sent to a delivery company shown as logistics company 35 which is responsible for delivery of the goods to the customer at 40.

In order to increase security of delivery and ensure that the goods are delivered to the correct recipient, the embodiment of the invention uses a token which is associated with the goods and which has two verification or authentication components. One relates to the identity or the goods or the package and the other relates to the identity of the recipient. On delivery, both identity components must be present for the delivery to be authenticated.

It is well known for on-line retailers to check the identity of customers placing orders. This stage is illustrated at 40. These checks may compare the address given with the known details for that customer name and may check the age given by the customer with known records to detect obvious attempts at fraud. The data checking service 40 communicates with verification databases 45. The data checking services also communicate with a token generation and storage provider 50 which is described in more detail below. This provider, in response to an order notified by the on-line retailer, creates a dual identity for the order. In a preferred embodiment, this dual identity comprises a matched pair of secured digital tokens. Matched tokens are not necessarily identical but include at least some data that can be compared between tokens of the pair to verify that the tokens form a pair. The token provider returns a two part token, or two matched or linked tokens to the on-line retailer which sends one of the

S

tokens to the customer with the order acknowledgement and sends the other to the logistics company to be associated with the goods. The token sent to the customer is a recipient identity token and the token sent to the logistics company is a goods identity token. The goods identity token is typically fixed to the goods or their packaging, for example by printing or embossing or by printing onto a label which is fixed to the goods or the packaging. Preferably, both the recipient identity token and the goods identity token are encoded onto a glyph, this may be a data matrix or a PDF4I 7 or other suitable bar code. Alternatively, the tokens may be encoded in RFID tags. These are particularly suitable for the goods identity token as they allow a parcel to be tracked to a place where a data transaction takes place when the parcel passes a sensor. In this way, the despatcher has confirmation that, for example, the goods have left the despatch depot. It is unlikely that there is a RFID sensor at the point of delivery but the PDA used to read the recipient identification token can also be used to read the RFID tag. It will be appreciated that the different methods of encoding may be used for the two tokens of a token pair such that the customer ID token may be encoded in a PDF4I7 bar code, for example, and the goods identification token in an RFID tag.

At the point of delivery, the two tokens must be matched for the delivery authentication process to begin. This may be done on-line or off-line. In the example of Figure 1, a PDA or similar device can scan the token as the goods and the token supplied to the customer and return the tokens on-line to the authentication server. If the tokens form a matched pair, the delivery can be authenticated. This may or may not require the recipient to input a security code such as a PIN as described below. In an alternative embodiment, the authentication can be performed off-line by the PDA. This is described below. The degree of identity required for there to be a match will vary depending on what additional data is carried by the tokens, but at least some part of the data in one token must be identical to data in the other token although in the preferred embodiment the match is achieved only after data is input from the recipient and some processing of the token data. In this respect, the term matching indicates that the two tokens belong together.

In both the on-line and off-line embodiments the customer may input a PIN (Personal Identification Number) during the online purchase process. This PIN may be required as well as the recipient identity token for verification.

Embodiments of the invention ensure that only the intended recipient of the goods, or a party trusted by them, may authenticate delivery as only they have the recipient identity token, and if applicable the PIN. This removes the risk of fraud both by customers alleging that they have not received goods when they have received them and also removes the risk of fraud by interception of goods by someone other than the intended recipient.

The order identification carried in the goods identification token may be additional to an order identification used by the delivery company.

Alternatively, the delivery company may adopt the order identification used in the token as its own order identification. The authentication of matched tokens may be time stamped and authentication details including the time stamp may be returned to the retailer for their records. The time stamp may further assist in restoring delivery queries from customers.

It is possible that goods could be ordered and paid for using a stolen credit or debit card or a stolen identity. Embodiments of the present invention reduce the attractiveness of using stolen identities or cards as the perpetrator of the fraud has to be present to take delivery of the goods and provide the recipient identification token. This adds another process which requires more time and so makes this type of crime less attractive.

Figure 2 shows an alternative embodiment of the invention in which the goods are delivered by a secure delivery company. This embodiment is particularly suited to delivering high value goods, foreign exchange, bank notes, traveller cheques and the like.

In Figure 2, the goods to be delivered are foreign currency which is supplied from an on-line foreign exchange provider 110. This provider receives orders from customers 120, for example companies or individuals who order the currency via purchase interface screens 122 on their computer web browser. The customer may be given a choice or delivery methods for the currency. This example assumes that the customer selects secure delivery. The customer, at 124, enters a PIN to further secure the identity. As with the previous example, the on-line retailer passes the order details and the customer details, including the PIN, to the data checking service 130 which includes authentication server 135. The authentication server creates the token pair as in the previous example, a first token of the pair comprising a unique recipient identification token and the second token comprising a unique goods identification token. The encoding of the tokens onto a glyph such as a data matrix or PDF417 or an RFID tag takes place at the authentication server. The tokens may be valid for a single use only or for multiple instances of authentication. The latter enables a trusted recipient status who can re-use a recipient identification token for more than one delivery. Alternatively, a single recipient token may validate a batch of packages each of which carry a unique goods identification token.

The authentication server as well as generating the tokens has reporting and auditing functions and stores the tokens for authentication and reconciliation. An example of a suitable system is disclosed in W02006/059124 the contents of which are incorporated herein by reference. This publication, entitled On-line generation and authentication of items' discloses a core system which generates tokens based on parameters supplied by an application specific wrapper which interfaces between the core and the application. The core also includes a store for generated tokens which is used for authentication. It will be appreciated that where authentication is performed on-line, the authentication server generates the unique identifiers and the tokens, holds the PINs or other security codes, and authenticates the goods identifications tokens to the recipient identification tokens. However, in the example given below, authentication is performed off-line by a remote device. In that example, the server is used to generate the identities and the tokens, to encrypt token data and to provide the appropriate public keys to the remote device to enable authentication, and to receive and store the results of authentications. This latter step is important as it enables the results of verifications I authentications to be tracked and details to be provided to the merchants.

Returning to Figure 2, which is an on-line example, the pair of tokens generated by the authentication server is returned to the on-line provider which sends the recipient identification token to the customer with an invoice or a confirmation of the order, and the goods identification token to the secure delivery company who is responsible for delivery. The customer may print their token or store it in a PDA, mobile telephone or other communications device which can display for scanning the token encoded in its glyph.

At the delivery company, receipt of a new package for delivery will cause a standard delivery label to be generated. To this is added the goods identification token encoded into the data matrix, other glyph, RFID tag or in some other manner and the combined label is applied to the goods.

Depending on the goods the information on the label may be applied directly to the goods or their packaging. As an alternative, the glyph or RFID tag may be applied as a secondary label in addition to the standard delivery label. The deliverer is provided with a PDA (Personal Digital Assistant).

The PDA has authentication application software installed and is used to read both the goods glyph or tag and the customer glyph at the point of delivery. At the point of delivery, the recipient glyph is also scanned and the customer is required to input the PIN assigned to the transaction, If this is accepted the retrieved token can be verified at the token generation and storage process which must confirm both that the token is correct and that it is a matched pair with the package token. If this is so, the customer is authenticated and can receive the package.

Figure 3 illustrates the generation of the tokens in more detail. The tokens illustrated in this example are particularly suited to an off-line authentication and use a security code such as a PIN. As shown at 200, the generic structure of the token is preferably of the form: <Type><TIN><Pin Flag>cPayloaci><security> Type' enables devices to recognise the token as either a recipient identification token or a goods identification token.

TIN is a Token Identification Number and is a unique number assigned to each token and ensures that each token and each token pair can be uniquely validated. The TIN is unique for all tokens irrespective of type.

The PIN flag is a single value indication as to whether a PIN is present on the recipient identification token and is set to zero if no PIN is present.

Where PINs are used, the recipient identification token does not carry the PIN and so this flag is set to zero. The goods identification token does carry the PIN and this flag is set to 1. An example of the recipient identification token (202) and the goods identification token (204) is shown inFigure3.

The Payload may in some circumstances be omitted but is preferred to be an order reference number. The payload of the recipient identification token is just this reference whereas the payload of the Goods identification token is the order reference and the PIN.

The security section of each token is a digital signature. The value is generated in the authentication server, as disclosed in W02006/0591 24 referred to above, by generating a hash of the entire token data (preceding the security component) using a private key held at the authentication server. This enables a remote off-line handheld device to validate the contents of the tokens to ensure that they have not changed using the associated public key. The authentication of the public key is validated by a digital certificate stored on the PDA.

Preferably the PIN stored on the goods identification token is an encrypted value which may be created by generating an encrypted hash of the TIN of the recipient token and the PIN value using the same public key as is used to validate the digital signature. The PIN cannot be decrypted by a third party as it is encrypted with the public key and can only be decrypted by the private key held at the authentication server. By including the TIN of the recipient identification token, which is different from that of the goods identification token within which the encrypted PIN is stored. If a third party could read the goods identification token they would not have access to the customer ID token needed to obtain the TIN value.

Referring back to Figure 3, the creation of the token pairs by the by the token creator which in this example forms a part of the authentication server is shown at 250. A recipient token may be used against a single goods identification token or multiple packages having the same order reference. In the latter case, each goods identification token may have a unique identifier and an identification of how many packages are in the order. The private keys used in the digital signature generation are stored at the token generation and storage process and the customer and goods identifications generated by the process are linked to customer verification data and purchase data received from the merchant.

The verification I authentication process will now be described in more detail with respect to Figure 4. The PDA device has an authentication software application installed and is provided with the public keys and associated digital certificates. These may be distributed by a Certificate Authority such as WiseKey or Verisign Inc. The PDA scans each of the goods identification token and the recipient identification token at 300.

The device checks the hash using the public key for each token and the digital certificate verifies that the public key is valid thus validating the contents of the tokens at 310. The software application recognises the token type from the Type information and retrieves the order references from both tokens to check that they match at 320. The customer is then prompted to enter a PIN at 330 and the PIN value entered is added to the unique reference number in the recipient token.. The encrypted PIN value is then recreated at 340 by adding the PIN to the recipient token TIN and hashing using the public key to produce an encrypted value at 350.

The encrypted value is then compared to the value in the package token at 360. If the values are the same, the device displays a message that the delivery may proceed and the delivery is authenticated at 370. The customer is then required to re-enter their PIN at 380 to confirm receipt of the goods. The device can then communicate the delivery at 390 individually or as a batch back to the token generation and storage process.

The receipt of authentication date by the authentication server is useful as it allows records of authentications to be stored which can be used against queries from customers, whether fraudulent or not. Moreover it provides an audit trail of the authentication process and can provide data regarding authentication back to the on-or off-line merchant who sold the goods, and to delivery companies.

S

As a further level of verification, the application running on the PDA device may send further information about the verifications that have taken place.

In one embodiment the PDA application may encrypt the PIN entered by the recipient using the public key and send it back to the token generation and storage process which can decrypt it with the private key and compare the PIN against the original PIN entered into the system at time of purchase. Where the PDA verifies on-line, this may be part of the authentication process. Where verification is off-line it may be used as an additional level of security as part of the audit of the off-line process and token transaction status update.

It will be appreciated that the verification process in this embodiment is off-line; that is the PDA does not have to communicate with the authentication server to authenticate the matching pair of tokens.

Moreover, the PDA does not need to have knowledge of the PINs as it compares an encrypted version of the PIN and order number with a previously stored encrypted value. It merely needs to have the public key.

The embodiment described enables authentication of delivery of given goods to a designated recipient and relies on the use of a pair of linked tokens. This concept may be applied to other areas and various modifications to the embodiments described are possible. Broadly, the embodiment described may be used to authenticate the relationship between a first entity and a second entity. The first entity may be a person, group of people or a legal entity and the second entity may be goods, but could be a second person, group of people or legal entity.

In addition to delivery of goods, embodiments of the invention may be used for the collection of goods. A typical scenario is where a party has purchased goods from, for example, a department store and has to collect them. The goods will carry the goods identification token as before and

S

the purchaser will receive the recipient identification token as before and will present this for scanning at the collection point. The two tokens are scanned as in the embodiment described and, if the tokens match, the goods are released. However, the token content may vary and the authentication may be performed on-line where the scanner is owned and used by the company selling the goods. Collection of goods may be viewed as an alternative type of delivery.

In a further alternative, the scanner is in possession of the customer, who subscribes to a verification service. In this case, an off-line verification such as is described with reference to Figure 3 is preferred.

A further advantage of embodiments of the invention relates to hire purchase transactions. Many customers purchase goods on credit, entering into an agreement with the retailer to repay the loan over a prescribed period. The loan is underwritten by a loan company who wilt not release the value of the goods to the retailer until supplied with proof of delivery of the goods. This can lead to customers paying off loans for goods they did not receive, as the delivery was intercepted, or alleging non-receipt and refusing to pay off the loan. Embodiments of the invention provide non-repudiable proof of receipt which eliminates, or at least significantly mitigates these problems.

The invention may be applied to other areas such as prescription medicines. In this aspect, the goods are the medicines to be dispensed and the recipient is the patient. This may be used to confirm that the correct patient is picking up a prescription but, advantageously, also to confirm that a patient is being given the correct drugs. This can be a significant issue within hospitals in particular.

Embodiments of the invention can overcome this problem by incorporating into the payload a product identification of the type typically applied to pharmaceuticals on their packaging either as an alphanumeric code or within a bar code or other glyph. This identifier is encoded into the payload of both the goods identification token and the recipient identification token. The recipient identification token may form a part of the prescription given to the patient or may be sent directly to the patient for example by email or to a mobile telephone. This option is particularly advantageous for the delivery of drugs and medical equipment direct from the manufacturer to be patient which is desirable where the drugs or medical equipment is specifically tailored to a particular patient.

In one embodiment the goods identification token, which carries or links to the unique identification of the medication, such as that proposed by the FDA in the United Sates or EFPIA in Europe, may also be used as a means for indicating whether a patient has both received and is taking their prescribed medication. When the medication is taken, the token identifying the medication and the recipient identification token, identifying the patient may be sent by the patient, or their carer to the token generation and storage system where they can be monitored. This enables the status of adherence by the patient to their medication regime to be monitored. It will be appreciated that the tokens remain live and that each time medicine is taken, the patient can send the details back to the system.

In the embodiments described, it is assumed that the life of the token expires when the goods are delivered, delivery is authenticated and receipt is acknowledged. In a further embodiment of the invention tokens may remain live after the original transaction has been completed. This has many advantages, for example where goods have warranties or guarantees, the token pair may serve to connect the warranty or guarantee holder with the goods. In this respect the payload of the tokens may include a product serial number or a link to a serial number held elsewhere. By extending the token lifecycle, a listing of the goods and

I

their relationship to the customer may be developed. In one example of this aspect the goods are passports and the customer a passport holder.

Many other modifications to the embodiments described are possible and will occur to those skilled in the art without departing from the scope of the invention which is defined by the following claims.

Claims

Claims 1. A method of verifying delivery of goods to an intended recipient, comprising: receiving an order for the goods, the order identifying a recipient for the goods; creating a pair of tokens comprising recipient identification token and a goods identification token, the recipient identification token and the goods identification token each having a unique identity and being linked; associating the goods identification token with the goods; providing the recipient with the recipient identification token; and on association of the goods with the recipient comparing at least a portion of the recipient identification token with at least a portion of the goods identification token and, if they match, verifying delivery of the goods to the recipient.
2. A method according to claim 1, wherein the pair of tokens each include a common transaction identifier.
3. A method according to claims 1 or 2, wherein the goods identification token includes a PIN supplied by the recipient with the order for the goods.
4. A method according to claim 3, wherein the creation of the pair of tokens comprises signing each of the pair of tokens with a value generated by encrypting token data using a private key, the signatures being validated by a public key associated with the private key.
5. A method according to claim 4, wherein the PIN of the goods identification token is an encrypted PIN value derived by hashing the PIN value supplied by the recipient with the unique identifier of the recipient identification token using the public key.
6. A method according to claim 5, wherein the comparison of the recipient identification token and the good identification token comprises receiving a PIN from an intended recipient, retrieving the unique identifiers from the recipient identification token, hashing the received PIN with the unique identifier using the public key, comparing the hash with the hashed value of the PIN held in the goods identification token, and, if the values are the same, verifying the recipient.
7. A method according to any preceding claim comprising, after verifying of the recipient, receiving a PIN from the recipient to confirm receipt of the goods.
8. A method according to any preceding claim, wherein each of the tokens comprise a token type identifier, the unique token identifier, a PIN flag, a payload and a security component.
9. A method according to any preceding claim, wherein the comparison and verification is performed on-line at the point of creation of the tokens.
10. A method according to any of claims Ito 8, wherein authentication is performed off-line by a device having a scanner for scanning the token pair and running verification software.
11. A system for verifying delivery of goods to an intended recipient, comprising: means for receiving an order for the goods, the order identifying a recipient for the goods; a token generator for creating, in response to the order, a pair of tokens comprising a recipient identification token and a goods identification token, the recipient identification token and the goods identification token each having a unique identifier and being linked; means for associating the goods identification token with the goods; means for providing the recipient with the recipient identification token; and means for comparing at least a portion of the recipient identification token with at least a portion of the goods identification token and, if there is a match, for verifying delivery of the goods to the recipient.
12. A system according to claim 11 wherein the means for associating the goods identification token with the goods comprises means for applying the token to the goods or packaging for the goods.
13. A system according to claim 12, wherein the token is applied to a label which is applied to the goods as their packaging.
14. A system according to any of claims 11 to 13, wherein the tokens are encoded onto glyphs.
15. A system according to any of claims 11 to 13, wherein the tokens are encoded onto RFID tags.
16. A system according to any of claims 11 to 15, wherein the means for comparing comprises a scanner for scanning the tokens.
17. A system according to claim 16, wherein the comparing means is remote from the token generator.
18. A system according to any of claims 11 to 17, wherein each of the pair of tokens includes a common transaction identifier.
19.. A system according to any of claims 11 to 18, wherein the goods identification token includes a PIN supplied by the recipient within the order for the goods.
20. A system according to claim 19, wherein the token generator comprises a digital signature generator for creating a digital signature for

S

each of the pair of tokens by encrypting token data with a private key, the signatures being validated by a public key associated with private key.
21. A system according to claim 20, wherein the token generator comprises a means for deriving an encrypted value of the PIN for inclusion in the goods identification token by hashing the PIN supplied by the recipient with the unique identifier of the recipient identification token using the public key.
22. A system according to claim 21, wherein the comparing means comprises means for receiving a PIN from an intended recipient, means for retrieving the unique identifier from the recipient identification token, means for hashing the PIN with the unique identifier, means for comparing the hash with the hashed value of the PIN held in the goods identification token and means for verifying the recipient if the values are the same.
23. A system according to any of claims 11 to 22, wherein the comparing means comprises means for receiving a further PIN after verification and, on receipt of the PIN, confirming verification to the token generator.
24. A device for use with the method for verifying delivery of goods to an intended recipient according to any of claims 1 to 10, comprising: a scanner for scanning the goods identification token from the goods and for scanning the recipient identification provided by the intended recipient; and means for comparing at least a portion of the recipient identification token with at least a portion of the goods identification token to determine whether to verify the delivery.
25. A device according to claim 24, further comprising means for receiving a PIN from the intended recipient, means for retrieving the unique identifier from the scanned recipient identification token; means for hashing the unique identifier with the PIN to create an encrypted PIN value, means for retrieving an encrypted PIN value from the goods identification token; and means for comparing the created encrypted PiN value with the retrieved encrypted PIN value to determine authenticity.
26. A method according to any of claims 1 to 10 wherein the pair of tokens remains active after verification whereby the goods and the recipient can be re-verified.
27. A method according to any of claims I to 10 wherein the goods are medicines and the recipient is a patient to whom the medicine has been prescribed.
28. A method of verifying delivery of goods to an intended recipient, comprising: receiving an order for the goods, the order identifying a recipient for the goods and including a security code; creating a pair of linked tokens comprising a recipient identification token and a goods identification token, the recipient identification token and the goods identification token each having a unique identity and the goods identity token including an encrypted security code value; associating the goods identification token with the goods; providing the recipient with the recipient identification token; on association of the goods with the recipient and receipt of a security code from the recipient, deriving an encrypted value of the recipient security code from the security code and the unique identifier of the recipient identification token; and comparing the derived encrypted value with the encrypted value of the security code in the goods identification token and, if they match, verifying delivery of the goods to the recipient.

S
29. A method according to claim 28, wherein the encrypted value of the security code is a hash of the security code and the unique identifier of the goods identification token..
30 A method according to claim 29, wherein the creation of the pair of tokens comprises signing each of the pair of tokens with a value generated by hashing each token's data using a private key, the signatures being validated by a public key associated with the private key.
31. A method according to claim 30, wherein the security code value of the goods identification token is derived by hashing the security code value supplied by the recipient with the order with the unique identifier of the recipient identification token using the public key associated with the private key used to sign the tokens.
32. A method according to claim 31, wherein the encrypted value of the security code supplied on association of the goods with the recipient is derived by hashing the input security code with the unique identifier from the recipient identification token using the public key.
33. A method according to any of claims 28 to 32, comprising reporting the results of verification to an administration system linked to the token creation.
34. A method according to claim 33, wherein the step of reporting the transaction / verification results comprises encrypting the security code supplied by the recipient using the public key and sending the encrypted security code to the administration system.
35. A method according to any of claims 28 to 34, wherein the steps of deriving the encrypted value of the recipient security code and comparing the derived encrypted value with the encrypted security code value in the goods identification token to verify the recipient with the goods are performed off-line.
36. A method according to any of claims 28 to 35, wherein the derivation of the encrypted recipient security code value comprises scanning the recipient identification token to retrieve the unique identifier; and hashing the identifier and the recipient security code with the public key
37. A system for verifying delivery of goods to an intended recipient, comprising: means for receiving an order for the goods, the order identifying a recipient for the goods and including a security code; means for creating a pair of linked tokens comprising a recipient identification token and a goods identification token, the recipient identification token and the goods identification token each having an unique identity and the goods identity token including an encrypted value of the security code; means for associating the goods identification token with the goods; means for providing the recipient with the recipient identification token: means for deriving an encrypted value of the recipient security code on association of the goods with the recipient and receipt of a recipient security code, the encrypted value being derived from the recipient security code and the unique identifier of the recipient identification token; and means for comparing the derived encrypted value of the recipient security code with the encrypted security code value in the goods identification token; and, if they match, verifying this and allowing delivery of the goods to the recipient.
38. A system according to claim 37, wherein the encrypted value of the security code is a hash of the security code and the unique identifier of the goods identification token.
39. A system according to claim 38, wherein the means for creating the pair of tokens comprises means for signing each of the pair of tokens with a value generated by hashing token data using a private key, the signatures being validated by a public key associated with the private key.
40. A system according to claim 39, wherein the encrypted security code value of the goods identification token is derived by hashing the security code value supplied by the recipient of the order with the unique identifier of the recipient identification token using the public key associated with the private key used to sign the tokens.
41. A system according to claim 40, wherein the encrypted value of the security code supplied on association of the goods with the recipient is derived by hashing the input security code with the unique identifier from the recipient identification token using the public key.
42. A system according to any of claims 37 to 41, comprising means for reporting the results of verification to an administration system linked to the token creation means.
43. A system according to claim 42, wherein the means for reporting the results comprises means for encrypting the security code supplied by the recipient using the public key and for sending the encrypted security code to the administration system.
44. A system according to any of claims 37 to 43, wherein the means for deriving the encrypted value of the recipient security code and for comparing the derived encrypted value with the encrypted security code

S

value in the goods identification token to verify the recipient with the goods are configured to perform off-line.
45. A system according to any of claims 37 to 44, wherein the means for deriving the encrypted recipient security code value comprises a scanner for wherein scanning the recipient identification token to retrieve the unique identifier; and means for hashing the identifier and the recipient security code with the public key.
46. A method of verifying the relationship of a first entity to a second entity, comprising: receiving information relating to the second entity and the first entity, the information relating the first entity including a security code; creating a pair of linked tokens comprising a second entity identification token and a first entity identification token, the tokens each having a unique identity and the second token including an encrypted value of the security code; associating the second entity identification token with the second identity; providing the first entity with the first entity identification token; on association of the second identity with the first identity and receipt of a security code from the first entity, deriving an encrypted value of the first entity security code from the security code and the unique identifier of the first identity identification token; and comparing the derived encrypted value with the encrypted value of the security code in the second entity identification token and, if they match, verifying the relationship of the first entity to the second entity.
47. A method according to claim 26 and 27 comprising sending the goods identification token and the recipient identification token to an administration system to indicate to the system that the patient has taken the medicine.