AU2008202642A1 - A payment, delivery and escrow system - Google Patents

Description

P/00/011 Regulation 3.2

AUSTRALIA

Patents Act 1990 COMPLETE SPECIFICATION STANDARD PATENT

(ORIGINAL)

Name of Applicant: Actual Inventor: Address for Service: Invention Title: Sensis Pty Ltd, ACN 007 423 912, of 222 Lonsdale Street, Melbourne, Victoria 3000, Australia Kathryn GARDINER DAVIES COLLISON CAVE, Patent Attorneys, of 1 Nicholson Street, Melbourne, Victoria 3000, Australia Payment, delivery and escrow system Details of Associated Provisional Applications: 2007903203 filed 14 June 2007 2007904391 filed 11 September 2007 The following statement is a full description of this invention, including the best method of performing it known to us:- P %0PER\SPM~a payrnwn delisy and =crow sysm canplmdo-i 3106r2008 00 -1n A PAYMENT, DELIVERY AND ESCROW SYSTEM

FIELD

(-i 5 The present invention relates to a payment, delivery and escrow system for purchase of (Ni O products. (Ni 00

SBACKGROUND

The purchase of products, i.e. goods or services, using online computer systems has gradually become accepted by traders and consumers, despite the difficulties that are inherent in using an online environment. The difficulties include product inspection, verification or trust of the parties involved in a transaction, perceived security of online payments and product delivery. Providing an online system that is accepted and trusted by both traders and consumers presents a number of technical challenges for the designers of such systems.

A business to consumer (B2C) ecommerce system, such as Amazon.com, presents fewer difficulties as the purchase and delivery infrastructure can be developed and controlled by the business that supplies the products to consumers. There is also a perceived level of trust by the consumer if the seller is a known business. Ecommerce systems or marketplaces providing consumer to consumer (C2C) transaction facilities are considerably more difficult to establish as the system needs to cater for the demands and requirements of both purchasers and sellers of products. Furthermore, C2C transactions are more vulnerable to fraudulent activities, particularly by sellers, than B2C transactions.

One successful system is that provided by eBay Inc. The eBay system however still has a number of problems that limit its use. The primary problem relates to ensuring that a seller actually sends the product to the purchaser and ensuring that the purchaser or buyer is satisfied that the product corresponds with what they expected to receive, based on a description in an advertisement for a product. Whilst the eBay system facilitates transactions between buyers and sellers, by allowing a seller to advertise a product, and a PAOPERMSPM' py>ment deiva y d mro, son pledo c-i3 062008 00 -2buyer to bid on or offer to purchase a product, the eBay system itself does not include components that cater for secure payment, delivery or inspection by the buyer or a process to manage disputes between the buyers and sellers. Once payment has been submitted, it is essentially up to the buyer and seller to make arrangements for payment and delivery of the product. For example, a seller may fail to send the product or may send a product that is O substantially different to that described in the advertisement. For this reason, the eBay 00 0system relies heavily on components that rank sellers by past reputation to try and invoke a Slevel of trust that encourages buyers to make a purchase.

Accordingly, it is desired to address the above or at least provide a useful alternative.

SUMMARY

In accordance with the present invention there is provided a payment, delivery and escrow (PDE) system, including: a purchase module for receiving agreement data, representing an agreed purchase of an advertised product by a buyer, and delivery data indicating a delivery location for the product; a delivery module for generating delivery instruction data for delivery to said delivery location using a trusted party; a tracking module for invoking an inspection timer process in response to receiving a receipt message from the trusted party advising receipt of the product from the delivery location; and a payment module for processing payment data from the buyer representing payment for the product, for sending a seller message to a seller of the product confirming the payment, and for transferring the payment to the seller on a satisfactory completion of the inspection timer process.

The present invention also provides a payment, delivery and escrow system, including: an advertising module for registering seller data for a seller, and receiving and publishing for the seller an advertisement for a product; P OPER\SPM\. pa)inwl dcliy~y d crow tyum caplac doc I3/061200 00 -3a purchase module for receiving agreement data representing an agreed purchase of _the product by a buyer, delivery data indicating a delivery address for the product, and payment data representing payment for the product; ,IC a delivery module for processing the payment data to obtain payment for the product, and sending a seller message to the seller confirming the payment and providing O delivery instruction data for delivery to said delivery address using a trusted party; and 0a escrow module for invoking an inspection timing process in response to receiving a receipt message from the trusted party advising receipt of the product at the delivery address, and for transferring the payment to the seller on a satisfactory completion of the inspection timing process.

The present invention also provides a process, including: sending a seller message to a seller confirming that payment for a product has been received and providing delivery instruction data for delivery to a delivery address using a trusted party; invoking an inspection timer to time an inspection period in response to receiving a receipt message from the trusted party advising collection of the product at the delivery address; and instructing transfer of the payment to the seller on a completion of the inspection period unless an issue message associated with the product is generated.

DESCRIPTION OF THE DRAWINGS Preferred embodiments of the present invention are hereinafter described, by way of example only, with reference to the accompanying drawings, wherein: Figure 1 is a block diagram of a preferred embodiment of a payment, delivery and escrow (PDE) system; Figure 2 is a flow diagram of an advertising process performed by the system; Figure 3 is a flow diagram of a purchase process performed by the system; Figure 4 is a flow diagram of a delivery and escrow process performed by the system; PVOPER\SPM\a payment delivcy d escrow sysim opl.do-I3/061200 00 -4-

;Z

Figure 5 is a flow diagram of product return process performed by the system; and ¢€3 Figures 6 to 11 are flow diagrams of processes performed by a further preferred embodiment of the PDE system.

5 DETAILED DESCRIPTION 0A payment, delivery and escrow (PDE) management system 102, as shown in Figure 1, includes a PDE module 104 and a trusted party module 106, which may be implemented using respective computer servers that communicate using a data communications network 108. The PDE system 102 communicates with a seller client 110, a buyer client 112 and a trusted party client 114 via the data network 108. The PDE module 104 is in communication with a PDE data store 116 in the form of a networked database. The PDE system supports and provides a PDE service process as part of an online C2C ecommerce system, and the process can be invoked by one or more parties using the C2C system.

A trusted party associated with the trusted party module 106 provides a package delivery system for delivery and tracking of a package between geographic locations, such as between Post Offices or between courier service points, or in certain embodiments between residential or business (work) addresses. The seller client 110 is accessible by a seller, i.e.

a person wishing to sell a product. The buyer client 112 is accessible by a buyer, i.e. a person wishing to purchase the product. The trusted party client 114 is located at a delivery location of the package delivery system of the trusted party and is accessible by an operator at the delivery location, for example an employee of the trusted party and/or a person wishing to access or lodge the package at the delivery location. Examples of a trusted party include the Australia Post Australian Postal Corporation), TNT TNT Toll Toll Holdings Limited), The United States Postal Service, and United Parcel Services of America Inc. An administrator administers and controls the PDE module 104, and receives reports as described below. The PDE module 104 and the administrator may be associated with or operated by an advertiser, such as a publisher of classified advertisements for products.

PA)PERWSPK4 paymlm defivary zod awrow symon -plewdo-13060200 00 The PDE module 104 includes a registration module 118, an advertising module 120, a purchase module 122, a first delivery and escrow module 124, a communications module 126, a data storage module 128 and a reporting module 130. The first delivery and escrow module 124 includes a tracking module 132 and a payment module 134. The communications module 126 includes a dispute resolution module 136 and a feedback module 138. The trusted party module 106 includes a second delivery and escrow module 0140.

The registration module 118 supports a registration process 208 that can be the same for all sellers. If a seller chooses to offer the PDE process as one of the payment and delivery options, then the seller only needs to provide bank account details. A seller can select payment and delivery preferences as part of their registration, and/or when listing specific advertisements. The buyer registration process 308 supported by the registration module 118 is no different for a buyer completing a transaction with or without the PDE process.

The registration module 118 and the advertising module 120 provide an advertising process 200, as shown in Figure 2, in connection with the seller client 110. The advertising process 200 commences with the seller client 110 establishing a connection to the PDE system 102 via the data network 108 (step 202). Once the connection is established, the registration module 118 determines whether the seller client 110 is registered (step 204). When the seller client 110 provides registration confirmation data, such as a username password combination or identifying cookie data, to the registration module 118 in step 204, the registration module 118 completes a login process (step 206).

If the seller corresponding to the seller client 110 has not previously registered with the PDE system 102, the seller client 110 fails to provide the registration confirmation data, and the registration module 118 commences the seller registration process (208). In the seller registration process the registration module 118 seeks receipt of seller profile data of the seller. The profile data includes: seller bank account data representing a bank account accessible by the seller, seller name data, seller residential address data, seller contact data (including telephone, email, postal, etc.) and/or preferred delivery location data representing a preferred location to drop-off and/or pick-up packages in a package P.%0PEWSPMa payinmi dclivry -nd mrrow syn =plae dm-13061008 00 -6n delivery system of the trusted party, or a business or residential address of the buyer). On initial registration, the registration module 118 may only require profile data representing the seller's nominated bank account, and the seller's name. The registration module 118 can then collect other seller profile data (address, email, phone, etc.) as required subsequently or from a related third party database. The seller may also provide subsequently a nominated outlet of the trusted party for returned items. To provide a degree of anonymity 00 0and avoid a product going to the private address of buyers or sellers, the delivery locations and outlets are restricted in certain embodiments to locations of the trusted party, e.g. Post Offices. In other embodiments home and/or work addresses can be used, if desired.

The seller registration process (step 208) generates registration confirmation data for the seller client 110. The seller client 110 may then access the login process of the registration module 118 (step 206). After logging in to the system 102 a website of the advertiser), the seller client 110 is provided with an advertisement submission process by the advertising module 120 (step 210). In the advertisement submission process, the advertising module 120 receives advertisement data from the seller client 110 representing at least one advertisement for the product that the seller wishes to sell. For example, the seller client 110 may transmit text data, image data, format data, and other content data to the advertising module 120 to allow an advertisement to be formed. At this point, the seller can choose to offer PDE as an option for purchasing the product. The advertising module 120 then generates and publishes the advertisement (step 212) in a form accessible to a buyer client 112 on a website served over the Internet, and/or in email/message bulletins transmitted to at least one buyer client 112). With publication of the advertisement in step 212, the advertising process 200 ends.

The registration module 118 and the purchase module 122 perform a purchase process 300 in conjunction with the buyer client 112, as shown in Figure 3. In a similar process to the seller connection and registration, the purchase process 300 commences with the buyer client 112 connecting to the PDE system 102 (step 302). If the buyer client 112 provides registration confirmation data to the registration module 118 (determined at step 304), the registration module 118 provides a login process at step 306. If, on the other hand, the P \0PERWM'j prnent del i-y md ese- sysicni ewiplac dm-13/D612009 00

O

-7buyer has not registered, and thus the buyer client 112 is unable to provide registration _confirmation data to the registration module 118, the registration module 118 provides a buyer registration process 308, similar to the seller registration process 208 described above. In the buyer registration process the registration module 118 seeks receipt of buyer profile data of the buyer, including: buyer name data, buyer residential address data, buyer contact data (including telephone, email, postal, etc.) and/or preferred delivery location 0 data representing a preferred location to drop-off and/or pick-up packages in a package delivery system of the trusted party, or a business or residential address) and buyer acceptance of the PDE terms and conditions. The system may give the buyer information about their nearest delivery location post office location) as the default based on the address business or residential) they used for registration, and provide the option to change their preference if they would prefer to go to another delivery location. The system may also automatically select the nearest delivery location based on the buyer's address. Information from this buyer registration process maybe populated into a delivery label for printing. Buyer bank account data, such as bank/credit card details, representing a bank account accessible by the buyer is normally only provided by the buyer when purchasing.

Following the buyer registration process, the buyer client 112 provides the registration confirmation data to the registration module 118 and performs the buyer login process of step 306. In the buyer login process (step 306) certain buyers are not able to log in, e.g. if they have previously been included in a PDE Blacklist, accessible by the PDE module 104.

Once the buyer client 112 has logged into the PDE module 104 via the website publishing an advertisement), the purchase module 122 generates an advertised product selection process (step 310) in which the buyer client 112 submits product selection data representative of the product which the client wishes to buy. The product selection data may be in the form of a product code, contained in the advertisement, or it may be automatically generated by the PDE module 104 when the buyer client 112 selects an electronically provided advertisement with the buyer clicking on a link on an advertisement webpage). The buyer can limit their search results to advertisements which offer the PDE service, i.e. the advertising module only generates advertisements where the P 0EPMSPM\. p~ymi ddi~y d -oow nm mplac d-1306r2008 00 -8seller has selected a particular purchase mode PDE). If the advertisement does not offer the PDE service as a payment and delivery option, the buyer is able to submit a request to the seller to enable the item to be purchased and delivered using the PDE service. The C2C site allows a buyer to select purchase options, and by selecting PDE the request is sent to the seller. The seller is able to submit a response accepting or denying O the request. An accept response invokes a PDE service offer for the item.

00 Following receipt of the product selection data, the purchase module 122 requires provision of purchase mode data (step 312) representing the preferred mode of purchase, e.g. pick-up and pay in person, pay using bank transfer, pay using the PDE service, pay using PayPal, Paymate, bank cheque, money order, or personal cheque, etc. When the PDE purchase mode is selected, the purchase module 122 automatically performs a cost calculation (step 314) to generate cost data indicative of the total price of purchasing the product via the PDE service, which is based on: the advertised product cost in the advertisement); the seller's estimate postage and handling charges for shipping from the seller's preferred delivery location to the buyer's preferred delivery location (in the package delivery system of the trusted party); administration or transaction fees for administration and/or use of the PDE system 102; charges/fees associated with the type of goods; etc.

The cost calculation may also generate max/min data indicative of the maximum and minimum limits of costs associated with products saleable and deliverable via the PDE system 102. For example, whether the PDE service is able to be displayed on the screen as an option for the seller could be pre-determined by the following checks: Listing Value (including Postage PDE Fee) must be less than a selected price threshold $1,000); (ii) Total Open PDE Transactions must be $10M; (iii) The seller is not Blacklisted from using PDE; and (iv) an Auction can only be enabled for PDE if another Payment Delivery Option is also enabled (due to the $1,000 or price threshold rule).

The cost determination may also generate alert data or prevent completion of the transaction via PDE if the calculated cost, or total price, is greater than the maximum amount permitted per customer, per transaction or if it will exceed the overall system limit at any one time.

P )OPERSPM\ p, y l ddivy ud m- syul copla, doc-13/06/2008 00 -9- Following the cost determination, the buyer may decide to buy the product and thus activate the purchase order request and acceptance process (step 316). In the purchase request and acceptance process, Terms and Conditions data is generated by the delivery Sand escrow modules 124, 140 and transmitted to the buyer client 112 and the seller client 5 110. The purchase order request and acceptance process requires that the clients 110, 112 O generate acceptance data in response, indicating acceptance by the buyer and the seller of 0the Terms and Conditions of the PDE process; the seller will have already accepted these if Sthey included PDE in their advertisement. Once the Terms and Conditions are accepted, the PDE module 104 generates a unique transaction reference number (TRN) used to uniquely identify all data associated with this transaction. The PDE module 104 then creates a data record in the PDE data store 116 indexed by the TRN. In the purchase request and acceptance process of step 316, the buyer selects how they will pay for the product, e.g. online payment via an online payment gateway (option or over-thecounter payment in person at a retail premises of the trusted party (option if the customer is reluctant to pay over the Internet.

The Terms and Conditions data, and message data indicative of the responses of the seller client 110 and the buyer client 112 are logged digitally recorded) by the data storage module 128 and recorded in the PDE database 116 in a data structure referenced by the TRN. In fact, all communication between the PDE system 102, and the clients 110, 112, 114 is from this point recorded by the data storage module 128 indexed by the TRN and stored in the PDE data store 116. It is advantageous to record this data to assist with the dispute resolution process and fraud.

Following the acceptance of the order, a delivery and escrow process 400 (shown in Figure is provided by the first delivery and escrow module 124 and/or the second delivery and escrow module 140.

If the online payment option was selected (as determined in step 404), the delivery and escrow process 400 enters an online payment process (step 406), executed by the payment module 134. In the online payment process of step 406, the buyer client 112 or the trusted P)OPERSPM\a paymi divry nd mrow syum orplc doc.131061200S 00 Sparty client 114 transmits payment data which provides payment of the calculated cost from the buyer's bank account to the delivery and escrow module(s) 124, 140. The payment data may be associated with an online credit card payment, whereby payment N, funds corresponding to the cost are transferred from the buyer to an escrow account of the PDE system 102, e.g. maintained by an established bank or credit union.

00 0Alternatively, in the over-the-counter payment process, the buyer prints a payment transaction slip including the TRN and goes into a designated payment location post office or bank branch office). A retail operator in the payment location post office or bank branch office) scans the payment slip and is notified of the amount that the buyer is required to pay, based on the total purchase price of the product (inclusive of any postage and handling fees or transaction fees passed on by the seller). The buyer can pay by cash, EFTPOS or selected credit cards.

If the buyer does not pay in full after a predetermined period, reminder messages generated by the system are sent to a message account via email, or Short Message Service, etc) of the buyer.

Once the payment data is processed, a payment received message is generated and transmitted to the seller client 110 indicating that the payment process has been performed.

The payment process also generates a confirmation message for the buyer client 112 recording details of the payment data funds transferred, time of transfer, etc.). The payment data is also recorded in the PDE data store 116 referenced by the TRN.

The delivery and escrow process 400 includes a barcoded delivery label generation process (step 408), wherein delivery label data is generated by the PDE system 102 and transmitted to the seller client 110 enabling the seller client 110 to generate delivery labels that display shipping parameters for the product using the package delivery system of the trusted party.

The delivery label includes a display of the TRN, or a related unique transaction identification code, and the delivery details of the package, including the delivery locations of the buyer the package destination) and the preferred delivery location of the seller pa t deify =d -ya v= ploe d- 13/D/2008 00 -11the return address). The preferred delivery location data is provided by the registration module 118. The delivery location data may be displayed on the delivery label as a computer readable format, for example a barcode. The delivery label is arranged to be easily readable, preferably machine readable, by the trusted party client 114 or an operator of the trusted party client 114, at the various delivery locations in the package delivery 0 system. The delivery label is generated in a format that is printable on a home printer of 00 0the seller, and sized to be attached to a package containing the product. The delivery label data may also be transmitted to the trusted party client 114 located at the seller's (i.e.

sender's) preferred delivery location the seller's local Post Office). The delivery label may then be generated at the seller's preferred delivery location and attached to an appropriate package as part of the lodgement process.

In any case, following generation of the delivery label, the package containing the product is lodged in the preferred delivery location of the seller, and the corresponding trusted party client 114 generates package received data. The client 114 may include a scanner for automatic scanning of the delivery label and automatic tracking. Alternatively, the package location data may be manually entered by an operator of the trusted party client 114.

The administrator of the PDE module 104 is the entity associated with the delivery labels, and thus the administrator has the authority (in the eyes of the trusted party) to provide directions to the trusted party in relation to a package (as agent of the sender or recipient) marked with one of the delivery labels. Normally, the package is not redirected midway through the process.

The generation of lodgement data by the trusted party client 114 commences a package tracking process (step 410) of the delivery and escrow process 400. In the package tracking process, the PDE system 102 receives updated location data indicative of the locations, and times of arrival, of the package at one or more locations in the package delivery system. The PDE system 102 may display an updated location of the package, representative of the package location data, for transmission to the seller client 110 and the P;\OPER'SPM\. ddiv .d row d..13106/2008 00 -12buyer client 112, enabling the seller and the buyer to keep track of the package.

The package tracking process of step 410 completes when the package has been transferred through the package delivery system to arrive at its destination address, being the preferred delivery location of the buyer. Upon arrival of the package at the destination address (i.e.

O the acquittal of the package), arrival data is submitted to the PDE system 102 using the 00 0delivery module and the trusted party client 114 at the buyer's delivery location. The arrival data can then be transmitted to the buyer client 112, and optionally the seller client 110 by the delivery module.

Once the package has arrived at the buyer's delivery location, the buyer is notified that the package is available for collection. (In alternative embodiments, the buyer's delivery location is a home or work address, and the package may require a signature or receipt.) The PDE system 102 generates reminder messages for the buyer if the parcel is not collected after a pre-determined amount of time, e.g. 5 or 10 days. The reminder messages are sent to the buyer via email, or SMS, etc. The delivery and escrow process 400 performs an [D check and handover process (step 416) in which the trusted party client 114 generates data indicative of a successful ID check of the buyer (or a nominated person acting on behalf of the buyer) by the trusted party a photograph ID check on a driver's license, signature confirming collection and proof of purchase via the unique TRN before the package is provided to the buyer), and that the package has been picked up from the delivery location.

Following the delivery and ID check and package handover (or 'pick up') process, the escrow module of the PDE system 102 invokes an inspection timer start process (step 418), wherein an inspection timer is started, allowing the buyer a set period 24 hours) in which to inspect the product and find whether or not it is satisfactory. In the inspection timer start process, timer start data is transmitted to the seller client 110, the buyer client 112 and the PDE system 102 indicating that the timer has started. Automatic commencement of the inspection period at the time of handover of the package is aimed at giving the seller some comfort that problems with the product will be reported in a P.)OPEWRSPM\a payment dclivey and escrow sysIa corrplaicdloc-13/06./20 00 -13- Spredetermined period of time. However, the end of the inspection period does not preclude a buyer from separately contacting the seller to raise a problem after the inspection period has lapsed, in accordance with their contractual or statutory rights. At the conclusion of N the inspection time, if no dissatisfaction or issue message has been received from the buyer client 112, or after a predetermined number of days if the package is not collected, as O determined at step 420, the escrow module (124 and/or 140) of the PDE system 102 0performs a payment transfer process to the seller (step 422), wherein payment (less any PDE service transaction fees) is transmitted to the seller in accordance with their bank account data from the escrow account, and confirmation data is transmitted to the seller client 110 and the buyer client 112. Payment transfer times are tracked by the tracking module 132, and alerts are generated if payments are not performed within pre-selected payment time limits.

The system 102 can be structured so the first delivery and escrow module 124 determines buyer satisfaction (420) and instructs the second delivery and escrow module 140 to complete the payment transfer process (422). Alternatively, the first delivery and escrow module 124 can handle all payment transactions associated with the escrow account, as discussed below.

If buyer dissatisfaction is registered by the buyer client 112 prior to the expiry of the inspection timer, the delivery and escrow process enters a dispute resolution process.

Dissatisfaction is registered by the buyer client 112 generating and sending a product issue message (including the TRN) for the delivery and escrow module 124, 140.

Depending on the outcome of the dispute resolution process negotiated by the buyer and seller, the PDE system 102 may perform a product return process 500 (step 424). In the product return process 500 (shown in Figure the delivery and escrow module 124 (and/or the second delivery and escrow module 140) generates return display label data and transmits it to the buyer client 112 representing a return display label, of a similar format to the display label initially sent to the seller, for printing, and containing details of the seller's preferred delivery location (step 502). The product return process 500 then P.\OPER\SPM! pymml dcliivoy cd -sy simi -p ldoc.I M31061200 00 -14waits for the trusted party client 114 to transmit data to the tracking module 132 indicative of the return lodgement of the package by the buyer client 112 at the preferred lodgement location of the buyer. The product return process 500, on receipt of the return lodgement Sdata, commences the package tracking process 504 which tracks the progress of the S 5 package from the buyer's lodgement location back to the seller's delivery location, and O tracks receipt of the package by the seller. The seller may be required to undergo an 00 0identity check procedure, and pick-up data in a return handover message may be Stransmitted from a trusted party client 114 at the seller's preferred delivery location indicative of return handover of the package. Upon return handover of the package, a second inspection timer process (step 506) commences which allows a specified period of time 24 hours) for the seller client 110 to determine whether the returned product is in the same condition as it was in when it was sent by the seller. If the seller is satisfied, i.e.

no dissatisfaction is registered (by sending an issue message) before the second inspection timer expires (determined at step 508), the product return process 500 performs a payment transfer process (step 510) to the buyer, in which funds held in the escrow account are transferred to the buyer's bank account. If, on the other hand, the seller is dissatisfied (determined at step 508) the product return process 500 initiates a dispute resolution process (step 512) which is performed by the dispute resolution module 136 in the PDE module 104.

In the dispute resolution process performed by the dispute resolution module 136, dispute messages, indicating the source of the dispute, which may be the seller and/or the buyer, are transmitted to the seller client 110, the buyer client 112 and/or the administrator of the PDE module 104. The dispute resolution process receives message data corresponding to messages sent by the seller and/or the buyer and/or the administrator, leading to the resolution of the dispute. The dispute message data is recorded by the data storage module 128 in the PDE data store 116 marked in records using the TRN. The dispute resolution module 136 may also generate message data requesting the holder of the package (commonly the seller, although alternatively the buyer) to lodge the package at a delivery location, and generate dispute lodgement form data for the printing of a dispute lodgement form which will be interpreted by the trusted party client 114 at the delivery location to PV)PERSPM\ paymmi dclivcry.d ow sy o. plaed N/O'2OO8 00

;Z

enable the disputed package to be returned to the administrator of the PDE system 102.

The administrator may conduct arbitration, independently inspect the product, and, using the dispute resolution module 136, generate outcome messages for the seller and the buyer.

SUnder control of the administrator, the dispute resolution module 136 may also disperse monies in the escrow account to the buyer and/or the seller's bank account, and/or provide O monies from a dispute resolution fund administered by the PDE system 102.

00 The data storage module 128 provides for recordal logging) of all message and event data generated or received by the PDE system 102, and provides an interface to the PDE data store 116.

Communications between the PDE module 104 and the data network 108 are conducted via the communications module 126 which provides for data communications in a variety of forms, including via the Internet, email generation and reception, HTML generation and web-based submission, FTP upload/download, on-line messaging, and telephonic connections with voice recognition and generation. The communications module 126 provides continuous data communications access with the PDE module 104 for the clients 110, 112 and 114. The communications module 126 also provides anonymous data transfer between the seller client 110 and the buyer client 112, for confirming payment or discussing package contents) and copies these message to the data storage module 128.

The communications module 126 also includes a feedback module 138 for receiving feedback on a transaction process. The feedback may be received from the seller client 110 and/or the buyer client 112, and is recorded by the data storage module 128 indexed by the TRN. The feedback module 138 may also generate an historical feedback data for display, e.g. on the Web, indicative of the performance of the buyer and/or seller in previous transactions.

The communications module 126 may also perform a message filtering process, to remove and/or tag messages that contain undesirable content, e.g. spam, offensive language, P.%OPERXPM\, pymmsl dcl;.my wld ese- g~nm pine dwd-131)060 00 -16unnecessary large blocks of data, etc.

The PDE module 104 also includes a reporting module 130, for generating report data on NI the performance of the PDE system 102 for the administrator of the PDE module 104. The report data provides for the generation of reports detailing the 'metrics' of the PDE system 102, including: business metric reports, site usage reports, security analysis reports, 00 0financial reports, etc. The business metric reports include information on unique sellers, unique buyers, the number of transactions in a certain time period, the payment type selected in each transaction, the number of disputes generated by the buyer/seller, fraudulent activities, and the time periods elapsed between events. The site usage reports include page flow and events reporting. The security analysis reports include summaries of fraudulent or illegal activities. Other reports may be generated on the basis of the report data provided by the reporting module 130 under control of the administrator.

An advantage of the PDE system 102 is that it provides an interface or buffer between the seller and the buyer, both coordinating transfer of the product through the trusted party's delivery system, and coordinating of payment of the calculated cost for the product.

The PDE module 104 and the trusted party module 106 may be implemented using computer servers manufactured by IBM Corporation or Apple Inc., running operating systems such as Microsoft Windows, Linux, UNIX or Mac OS X. The modules 118, 120, 122, 124, 126, 128 and 130 of the PDE module 104, and the module 140 of the trusted party module 106 may be software modules including executable computer program code written using a programming language, such as C, Java, or Microsoft.Net. In alternative embodiments, the software modules may be replaced or substituted at least in part by hardware modules or components such as dedicated ASICs (application-specific integrated circuits) or FPGAs (field programmable gate arrays) to perform at least some of the processes of the modules 104 and 140 at improved speed.

The trusted party client 114, the seller client 110 and/or the buyer client 112 may be personal computers as manufactured by IMB Corporation or Apple Inc., running operating P.PER\SPMa paymeri dclicry ad =row synm ompltc.doc.I3/0&7008 00 D -17n systems such as Microsoft Windows, Linux, UNIX or Mac OS X, and communication tools, such as a web browser. The data network 108 may include: a secure extranet between the PDE module 104, the trusted party module 106 and/or the trusted party client

C

114; and (ii) the Internet between the PDE system 102, the seller client 110 and/or the IN 5 buyer client 112. The PDE datastore 116 may include a computer server as manufactured by Lenovo Corp, and a database server, such as MySQL, to establish and maintain the O 0 PDE database.

The PDE system 102 may be configured such that steps relating to escrow are performed primarily by the first delivery and escrow module 124 (rather than the second delivery and escrow module 140), which in turn carries out escrow-related steps in communication with a related financial institution a bank or credit union). In this configuration, the following steps are performed by the first delivery and escrow module 124: generation of the Terms and Conditions data in the purchase request process (step 316); (ii) generation of the online payment process (step 406)-including reception of the payment data from the buyer client 112 or trusted party client 114-and subsequent transmission of this payment data to the financial institution for processing and storage in the escrow account; (iii) generation of the confirmation message for the buyer client 112 recording detail of the payment data, which includes confirmation data from the financial institution; (iv) generation of the delivery label data (step 408); generation of the package tracking process (step 410), including reception of location data and transmission of the package location; POPER\SPM\ pymn ddivay md row commmpla doc.3/&061'2 00 -18- (vi) performance of the inspection timer start process (step 418); (vii) performance of the payment transfer process (step 422), with payment being (I transmitted to the seller from the financial institution where the payment has been stored; and 00 (viii) generation of the product return process 500 and activation of the dispute resolution process (which is performed by the dispute resolution module 136.

In a specific embodiment of the PDE system 102, the delivery and escrow process 400, and the product return process 500 are performed as described below with reference to Figures 6 to 11.

The PDE module 104 generates a payment process 602, as shown in Figure 6, once a purchase request has been accepted invoking the PDE service (step 316 in Figures 3 and e.g. when an online auction is won, when a buyer has accepted a second-chance offer or when an immediate buy request has been made. During the payment process 602, the 'PDE transaction state' moves from 'sold' to 'paid'. The payment process 602 commences with the PDE module 104 creating a transaction number, or TRN (step 604), and immediately starting a payment reminder timer (step 606). The PDE module 104 asks the buyer (via buyer client 112) whether the buyer wishes to pay now (step 608): if the answer is yes, an online payment process is performed by the buyer (step 610); if not, the PDE module 104 generates a 'pay in person receipt' which is transmitted to the buyer to make the payment in person, e.g. at a location of the trusted party or of the related financial institution (step 612). The buyer, with the 'pay in person receipt', may then pay in person (step 614) in conjunction with the trusted party client 114 at the designated location of the trusted party or of the related financial institution, which collects the payment (step 616).

When a payment has been made in person, the trusted party client 114 registers the payment with the trusted party module 106 (step 618), which then informs the PDE module 104 (step 620); the trusted party client 114 also provides a receipt to the buyer P flPEWSPM\. plyn-. ddi-y -d -ro -pl d-3 I06000 00 -19- (steps 622 and 624). (Altemrnatively, the financial institution registers payment and informs _the PDE module 104.) If the buyer does not pay within a first allocated time periodcontrolled by the payment reminder timer-a payment reminder message is transmitted to Nthe buyer, e.g. via email, SMS, etc. (step 626), and the PDE module 104 starts a second missed payment alert timer (step 628). If the buyer has still not paid at the end of the second missed payment alert timer, the PDE module 104 generates an alert to the PDE 00 0administrator that the payment has not been made within the designated time period. For San online payment, as performed in step 610, the PDE module 104 collects payment details of the buyer (step 632) and generates payment and transaction details for transmission to the trusted party (step 634). The trusted party module 106 receives payment details (step 636), either from the trusted party module 106 itself (due to a 'pay in person' payment) or from the PDE module 104 (due to an online payment), and consequently initiates an escrow process (step 638) wherein payment details of the transaction are transmitted to a relevant financial holding structure or financial institution bank, credit union, etc.).

Once payment and transaction details have been registered (either in step 620 or step 634) both the buyer client 112 and the seller client 110 are informed that the payment has been made by transmission of payment receipt and escrow messages (steps 640, 642 and 644).

After informing the buyer and seller, the PDE module 104 commences a create label process (step 646) for the creation of a shipping display label for the product. An audit module 128A, in the data storage module 128 of the PDE module 104, performs a plurality of event log processes 648 to record all data relating to transactions and messaging of the payment process 602. At the end of the payment process 602, the 'PDE transaction state' has become 'paid' and the 'delivery state' has become 'label created'.

The create label process 646 is initiated by the PDE module 104 upon receipt of a "create label message" from the payment process 602 or the dispute resolution process at step 512 or in step 702, shown in Figure 7. In the create label process 646, the PDE module 104 generates a label (step 704) including data representing the shipping label/address, the relevant transaction ID, and sender and receiver details. The label is displayed through an online interface by the PDE module 104 (step 706) for the sender who may log in to securely access the label in step 708. The sender may then print the label (step 710) and P 0PEWS~PM\a paym-n delicmy md miow &yartm oplde wo1310&2008 00 n, affix the label to a parcel for shipping/post by the trusted party (step 712). The label can only be accessed by the registered sender, and is only accessible once generated in accordance with the payment process 602 or the dispute resolution process 512. The create label process 646 also generates tracking data for the trusted party by sending label details to the trusted party (step 714) to receive in step 716 and be used for parcel tracking. The PDE module 104 generates log data regarding the create label process 646 for recordal in 0the audit module 128A (step 718). Following transmission of the label details in step 714, Sthe PDE system 102 commences a parcel not sent first timer (step 720) after which it is tested whether the parcel has been sent, using data from the trusted party, e.g. lodgement data of the parcel at a location of the trusted party (step 722). If the parcel has not been sent, a second parcel not sent timer is started (step 724), and a 'parcel not sent first follow up message' is transmitted to the sender (step 726). If the parcel has still not been sent (tested in step 728) the PDE module 104 commences a'parcel not sent process' 730 which triggers issue and trust and safety alerting to be acted upon by an administrator of the PDE module 104. A message is also sent to the sender in the form of a 'parcel not sent second follow up message' (step 732). The automated label creation process 646, automated commencement of tracking, and the reminder and alerting processes (720, 724, 730) advantageously provide security, reliability and accountability for users of the PDE system 102.

Once a shipping label has been created in the create label process 646, the package is delivered by the trusted party in a delivery process 800, shown in Figure 8. In the delivery process 800, the PDE module 104 manages a one-way transfer of goods, following an initial payment or following a dispute, from the sender to the recipient. In the delivery process 800, the sender may be the seller of the goods, i.e. in an initial buy context, or may be the original buyer, returning the goods after a dispute procedure. The delivery process 800 is commenced by the sender accessing and printing a label generated in relation to delivery of the parcel (step 802). Once printed, the label is affixed to a parcel, and lodged by the sender at a location of the trusted party, or any relevant outlet for accepting parcels (step 804). At the trusted party location, the trusted party client 114 generates an accept parcel process (step 806) which includes accepting and rejecting labelled parcels according P NOPERSPMa paymmn ddivay .d su c=npla doc.13/06/20S 00 -21to predefined acceptability criteria size, dangerous goods, etc.). Once accepted, the trusted party module 106 receives data of the parcel in an acceptance scan process (step 808) which also generates delivery status data for the PDE module 104 (step 810) for notifying the parties (step 812) and the audit module 128A (step 814). The update delivery status messages are related by the transaction ID TRN) of the shipped parcel.

(N

Following the acceptance scan, the parcel is physically transported to its destination (step 0 816) and receives an arrival scan after arrival at the destination location (step 818); this arrival scan process validates the actual location scanned against the expected destination, and informs the PDE module 104 that the parcel has successfully arrived in an update delivery status process (step 820). The PDE module 104 then logs the update delivery update data in the audit module 128A (step 822) and notifies both parties of the arrival of the package (step 824).

Upon receiving the collect parcel message from the PDE module 104 (in step 826) the recipient presents at the delivery location and requests the parcel (step 828). An operator of the trusted party, at the delivery location, validates the identity of the recipient (step 830), the trusted party module 106 receives data relating to a collection scan indicating collection of the parcel by the recipient (step 832), and the parcel is handed over to the recipient (step 834). The delivery process 800 ends with the recipient receiving the parcel (step 836). Once the trusted party module 106 receives the collection scan data, this is transmitted to the PDE module 104 (step 838), which generates log data for the audit module 128A (step 840) and accordingly notifies the parties that the parcel has been collected, and a corresponding inspection period has commenced (step 842). During the delivery process 800, the 'delivery state' moves from 'parcel lodged', through 'parcel arrived' (at the delivery location), to 'parcel inspection'. If a parcel is not collected, a collection reminder process (step 844), provided by the PDE module 104, generates reminder data for the recipient to collect the parcel; if the collection timer expires, e.g. if not collected after 5 days, a reminder message is generated and sent to the recipient. If the uncollected time period extends to a greater number, e.g. 10 days, the administrator of the PDE module 104 is alerted, thereby ensuring that parcels are not left uncollected at locations of the trusted party for unnecessarily long periods of time.

P.EPMR\SPU PYlmt dclivery d escow Syrern Coniplae dom.131062003 00 -22 The inspection process 900, initiated by collection of the parcel by the recipient, commences with an inspection timer process (step 902) having a timer started by parcel Ncollection (step 904). Data relating to the commencement of the inspection timer is O 5 recorded in the audit module 128A (step 906) and the timer runs for a pre-selected time, O e.g. 24 hours (step 908). During this time, the 'PDE transaction state' is in the 'inspection' 00 0state, and the parcel recipient may identify issues (step 910), e.g. that the received parcel is Snot as expected. If displeased by the parcel, the parcel recipient can raise an issue message or event via a number of means, including via an online interface to the PDE module 104, a telephonic interface with the contact centre in communication with the PDE module 104 or an automated contact centre (interactive voice response system, IVR) also in communication with the PDE module 104 (in steps 912, 914 and 916 respectively). Any raised issue is registered with the dispute resolution module 136 (step 918), which commences the dispute resolution process 512. If no issues are raised within the inspection timer process, issues relating to inspection are considered to be complete, and the 'PDE transaction state' moves from the 'issue' to the 'disbursed and closed' state. If an issue is raised via an IVR system (step 116) the PDE module 104 generates a message for the parcel recipient (step 920) to provide further details regarding the issue, which is also included in the registered issue (step 918). Once data representing the issue is registered, messages are generated and transmitted to the parcel recipient and parcel sender (steps 922 and 924) and lodged with the audit module 128A (step 926). The disbursement of funds at the end of the process occurs after a set number of business days from the resolution of the issue, or at the resolution of the inspection timer, e.g. 10 business days. Issues cannot be raised after the expiration of the inspection timer process. The various contact centres, including the online interface and the IVR system, are available at all times to allow for a parcel recipient to respond immediately with any issues identified.

A specific example of the dispute resolution process 512, shown Figure 10, includes an add issue details process 1002 and a dispute management process 1004. In the dispute resolution process 512, a dispute issue may be raised by either a buyer or a seller (step 1006), using for example an online interface to generate update details of each issue in the P.%OPERSPM's payrnmt dclivery" nd plaeddm-1,0&200 00 -23dispute resolution module 136 (step 1008); the dispute resolution module 136 in turn generates messages regarding each issue for transmission to the issue respondent, i.e. the other party, (step 1010) and for logging into the audit module 128A (step 1012). For each raised issue, the issue respondent and the issue raiser may propose solutions to the dispute resolution module 136 (step 1012): any proposed solution is then transmitted to both

(N

O parties (steps 1014, 1016) who then respond to the dispute resolution module 136. The 00 0responses are received by the dispute resolution module 136 in a resolution management C, process 1018. The resolution management process 1018 is iterative. New resolutions may only be proposed if no existing pre-proposed resolutions are currently open or available.

The parties may communicate directly with each other only if communication has not been blocked by either party or the administrator of the PDE module 104. The terms and conditions of the PDE process stipulate that communications outside the dispute resolution process 512 may void the PDE guarantee offered by the PDE process.

The resolution management process 1018 finishes when there is either an Acceptance or an Escalation of the process. A timer runs as part of this executed task to automatically escalate at expiry of the timer. The duration of the timer is specified by the administrator.

Automatic escalation may also occur following the rejection of a selected number of proposals (selected by the administrator). Resolutions are rejected in step 1020, resolutions are accepted at step 1022 and the dispute escalates in step 1023. Both acceptance and escalation steps lead to notification of a Trust and Safety Unit of the administrator of the PDE system 102, which can then resolve the existing dispute (step 1024). As all disputes must lead to this resolution process, both buyer and seller in any transaction have a high degree of security and trust in the PDE process. All transactions and events in the dispute resolution process 512 are logged by the audit module 128A, and the transaction status is constantly updated at every step in the PDE module 104. Once a resolution has been reached, the details are recorded by the dispute resolution module 136 (step 1026) and the disbursement details, corresponding to the resolution of the dispute, are sent to the audit module 128A, the PDE module 104, the issue raiser and respondent (step 1028). The banking details of the respondent and the issue raiser are then updated (steps 1030, 1032). All disbursements that occur after a dispute are performed following P;)OPERWM8y pymmi driva) wd miow umplacd-131W2008 00 -24n disbursement instructions that specify how the escrowed funds are to be divided between _3 the disputing parties, e.g. as specified in the Terms and Conditions of the PDE service.

During the PDE resolution process 512, the 'PDE transaction state' moves from 'issue' to 'disburse'. The 'delivery state' may also move to a 'label creation' state if the resolution of the issues involves a further shipping/transport step of the parcel(s).

00 0The escrowed funds stored in the escrow account are disbursed in a disbursement process S1100 either by default, at the expiration of the inspection timer process, or as specified at the resolution of a dispute process, as shown in Figure 11. The disbursement process 1100 commences with the PDE module 104 accessing disbursement details relating to this transaction ID and sending them to the relevant escrow entity, being either the trusted party or a financial entity, for disbursement of the funds (step 1102). The PDE module 104 also sends messages recording the disbursement of funds to both the buyer and the seller (steps 1104 and 1106 respectively). The PDE module 104 then updates the status of the PDE process, which is available online (step 1108) and generates a feedback capability for both the buyer and the seller so feedback can be recorded on experiences of the process (step 1110). The escrow entity receives the disbursement confirmation data and performs the disbursement (steps 1112, 1114). The disbursement process 1100 also performs disbursement error correction processes, including if a disbursement fails three times, the relevant party receives messages to contact the administrator of the PDE module 104 to manually correct the error.

The PDE module 104 also generates a Help Desk Tool which enables users to manage their details online, view transaction details as they are updated, view and manage banking, escrow and disbursement data, create, send and view messages, block communications between disputing parties), view and approve resolutions (in a dispute resolution process), generate and print shipping labels, update and view feedback, and access at least some log information including log information generated by the audit module 128A.

Many modifications will be apparent to those skilled in the art without departing from the scope of the present invention as herein described with reference to the accompanying P.OPMRSPMf, pa- ddivy -d n -plmd..I3/6/20S 00 00 drawings.

Claims (34)

1. A payment, delivery and escrow (PDE) system, including: a purchase module for receiving agreement data, representing an agreed purchase of an advertised product by a buyer, and delivery data indicating a delivery location for the 00 product; a delivery module for generating delivery instruction data for delivery to said delivery location using a trusted party; a tracking module for invoking an inspection timer process in response to receiving a receipt message from the trusted party advising receipt of the product from the delivery location; and a payment module for processing payment data from the buyer representing payment for the product, for sending a seller message to a seller of the product confirming the payment, and for transferring the payment to the seller on a satisfactory completion of the inspection timer process.

2. A PDE system as claimed in claim 1, wherein the PDE system sends an arrival message to the buyer, advising of arrival of the product at the delivery location, in response to arrival data generated by the trusted party.

3. A PDE system as claimed in any of the preceding claims, wherein the receipt message is only generated and sent by the trusted party after verifying the identify of a person receiving the product at the delivery location.

4. A PDE system as claimed in any of the preceding claims, wherein the delivery instruction data includes delivery label data for generating a coded delivery label, which indicates the delivery location of the buyer. P.OPERSPM\ payrom dclivoy wd ,ro pm plac.-13/06(200 00 O D -27- s

5. A PDE system as claimed in claim 4, wherein the coded delivery label is machine- Sreadable.

6. A PDE system as claimed in any of the preceding claims, wherein the delivery module generates return label display data representing a return label including an 00 indication of a delivery location of the seller.

7. A PDE system as claimed in claim 6, wherein the return label is machine-readable.

8. A PDE system as claimed in claim 1, wherein the delivery location is restricted to a location of the trusted party.

9. A PDE system as claimed in claim 3, wherein the delivery location is automatically selected by the purchase module based on the nearest location of the trusted party to an address of the buyer.

A PDE system as claimed in one of claims 3 or 4, including a client of the trusted party, at the delivery location, in communication with at least one of the modules of the PDE system.

11. A PDE system as claimed in any of the preceding claims, wherein the purchase module automatically generates cost data for the buyer indicative of a total price for: the product, postage and handling to the delivery location, and fees for use of the PDE system.

12. A PDE system as claimed in claim 6, wherein the purchase module generates an alert if the total price is greater than a selected price threshold.

P.OERSPM\a pmcnt diivycry and yrow syos o.plm oc-13/06120 00 -28- ;Z S13. A PDE system as claimed in claim 1, wherein the delivery location is a business or _residential address of the buyer.

"14. A PDE system as claimed in any of the preceding claims, wherein the PDE system invokes a further inspection timer process in response to receiving a return message from 00 the trusted party advising of return of the product to the seller at the seller's preferred delivery location, and the payment module transfers payment to the buyer on a satisfactory completion of the further inspection timer process.

15. A PDE system as claimed in any of the preceding claims, wherein the payment data from the buyer is generated by a financial institution related to the buyer

16. A PDE system as claimed in claim 15, wherein the financial institution is the buyer's bank, and the payment data represents an online credit card payment.

17. A PDE system as claimed in any of claims 1 to 14, wherein the payment data from the buyer is generated at the delivery location.

18. A PDE system as claimed in claim 17, wherein the payment data is generated based on payment by cash, EFTPOS or a credit card at the delivery location.

19. A PDE system as claimed in any of the preceding claims, wherein the PDE system commences a payment reminder timer process following receipt of the agreement data, and generates a payment reminder message for the buyer, if the payment data is not received within completion of the payment reminder timer process.

A PDE system as claimed in any of the preceding claims, wherein the PDE system P NOPERISPM\ py-* ddi-y cd =o-.yn -oplard.-13/61200 00 -29- commences a not-sent timer process following generation of the delivery instruction data, _and generates a follow up message for a sender of the product, indicating that the product has not been sent, if lodgment data, representing lodgment of the product, is not received N within completion of the non-sent timer process. \O 00

21. A PDE system as claimed in any of the preceding claims, including an advertising module for receiving advertisement data for the product from the seller, and for generating an advertisement for the buyer.

22. A PDE system as claimed claim 21, wherein the advertising module only displays an advertisement for the buyer if the seller has selected a predetermined purchase mode.

23. A PDE system as claimed in claim 22, wherein the predetermined purchase mode involves use of the PDE system.

24. A PDE system as claimed in any of claims 21 or 22, wherein, if the advertisement does not offer use of the PDE system, the purchase module receives purchase mode selection data representing a request from the buyer to offer purchase of the product using the PDE system.

A PDE system as claimed in any of the preceding claims, including a dispute resolution module for performing a dispute resolution process when dissatisfaction data, representing dissatisfaction of the buyer and/or the seller, is received by the PDE system.

26. A PDE system as claimed in claim 25, wherein the dissatisfaction data includes buyer dissatisfaction data, representing buyer dissatisfaction with the product, received before expiry of the inspection timer process. POPERiSPM\a paymmi ddivcy md mr- um compleedo.131061200 00

27. A PDE system as claimed in any of the preceding claims, including a feedback module for receiving feedback on past use of the PDE system, and for generating historical ,feedback data for indicating the performance of the buyer and/or seller in a previous \O rI 5 transaction. 00

28. A PDE system as claimed in any of the preceding claims, including: a seller client, accessible by the seller, in communication with at least one of the modules of the PDE system; and a buyer client, accessible by the buyer, in communication with at least one of the modules of the PDE system.

29. A payment, delivery and escrow system, including: an advertising module for registering seller data for a seller, and receiving and publishing for the seller an advertisement for a product; a purchase module for receiving agreement data representing an agreed purchase of the product by a buyer, delivery data indicating a delivery address for the product, and payment data representing payment for the product; a delivery module for processing the payment data to obtain payment for the product, and sending a seller message to the seller confirming the payment and providing delivery instruction data for delivery to said delivery address using a trusted party; and a escrow module for invoking an inspection timing process in response to receiving a receipt message from the trusted party advising receipt of the product at the delivery address, and for transferring the payment to the seller on a satisfactory completion of the inspection timing process.

A product delivery and escrow (PDE) process, including: sending a seller message to a seller confirming that payment for a product has been received and providing delivery instruction data for delivery to a delivery address using a trusted party; P/OPERSPM payin dliiay md .rowys00 ro plae docI3/06/2003 00 -31- invoking an inspection timer to time an inspection period in response to receiving a receipt message from the trusted party advising collection of the product at the delivery address; and instructing transfer of the payment to the seller on completion of the inspection 5 period unless an issue message associated with the product is generated. 00

31. A process as claimed in claim 30, wherein the issue message is generated in response to the buyer submitting an issue or concern with the product.

32. A process as claimed in any of claims 30 or 31, wherein the payment represents an agreed purchase price for the product and an additional payment for invoking the process.

33. A process as claimed in any of claims 30 to 32, wherein the process includes events which are accessible for display to parties associated with the process.

34. A payment, delivery and escrow (PDE) system, substantially as hereinbefore described with reference to the accompanying drawings. A payment, delivery and escrow (PDE) process, substantially as hereinbefore described with reference to the accompanying drawings.