WO2001044994A2

WO2001044994A2 - Transaction method, system, and apparatus

Info

Publication number: WO2001044994A2
Application number: PCT/CA2000/001189
Authority: WO
Inventors: Kombiz O. Eghdami; Alton Ing; Duncan Westby Phillips
Original assignee: Vlinxcom Inc
Current assignee: Vlinxcom Inc
Priority date: 1999-12-15
Filing date: 2000-10-06
Publication date: 2001-06-21
Anticipated expiration: 2002-06-15
Also published as: WO2001044994A8; AU7766400A

Abstract

L'invention concerne un procédé, un système et un appareil permettant de faciliter des transactions. Des aspects de cette invention permettent aux acheteurs d'effectuer des transactions commerciales nationales et/ou internationales avec des vendeurs, auxquelles un certain nombre de participants supplémentaires peuvent participer potentiellement, lesdits participants incluant des assureurs, des institutions financières qui offrent un crédit à des acheteurs et/ou des dépositaires légaux pour des fonds de retenus, des inspecteurs de biens et des coordinateurs de logistique notamment des expéditeurs et/ou des transitaires. Quelques uns des participants supplémentaires ou la globalité d'entre eux participant à une transaction donnée n'ont pas à être sélectionnés par les acheteurs ou les vendeurs, mais au lieu de cela ils peuvent être sélectionnés antérieurement avant la transaction par une autorité coordinatrice centrale.A method, system and apparatus for facilitating transactions are provided. Aspects of this invention allow buyers to conduct national and / or international business transactions with sellers, in which a number of additional participants may potentially participate, said participants including insurers, financial institutions that offer credit to buyers and / or legal depositaries for holdback funds, property inspectors and logistics coordinators including shippers and / or freight forwarders. Some of the additional participants or all of them participating in a given transaction do not have to be selected by the buyers or sellers, but instead they can be selected before the transaction by a central coordinating authority.

Description

Transaction Method, System, and Apparatus

BACKGROUND OF THE INVENTION Field of the Invention The present invention relates to a method, system, and apparatus for facilitating transactions. It is particularly well suited to coordinating commodity transactions between many parties resident in many jurisdictions, including buyers, sellers, financers, shippers, insurers, inspectors, and escrow agents.

Description of Related Art People have been trading commodities internationally for much of human history. The trading of tea, spice, furs, metals, minerals, fruit, vegetables and livestock have all been prominent in the development of nations.

International commodities trading is inherently risky and thus traders have faced both fortune and ruin. Ships sink. Cargo is hijacked. Purchasers refuse to pay. Commodities fail to meet purchaser expectations. Governments detain commodities. Over time, traders have developed and refined ingenious mechanisms for allocating such transaction risks, including insurance, bills of lading, letters of credit and escrows, inspection certificates, and standard Sale of Goods contracts, terms, statutes, and case law.

Beyond such mechanisms however, successful traders have also depended upon superior communications. For example, in the 19^th Century, the Rothchilds installed a brother in each of the principal cities of Europe and maintained a flock of carrier pigeons to carry messages between them. This arrangement enabled the family to acquire and exchange reliable local knowledge pertinent to their transactions.

Furthermore, huge trading houses have evolved to minimize trading risks by internally coordinating all aspects of trade for their own account. Nevertheless, the multi-party and inter-jurisdictional aspects of commodities trading cause significant market inefficiency for all other traders. For these latter traders, commodities trading is implemented through a web of bilateral agreements that can be difficult to coordinate. These latter traders do not benefit from a central coordinating authority and instead have to spend years developing networks of parties that work reliably together.

The Internet offers the promise of introducing significant efficiencies in the way in which companies handle the international trading of commodities. However, conventional initiatives are aimed primarily at speeding up existing decision making processes, for example the selection of the appropriate shipper or insurer for a particular consignment, or increasing messaging security. For example, the Bolero.net system is a business to business communications system designed to allow a number of different entities involved in international trade (e.g. sellers, exporters, buyers, importers, carriers, freight forwarders, financial institutions and customs) to communicate securely with one another. A central co-ordinating authority operates to define certain rules and procedures that govern how the various entities will contract, and to provide the secure messaging infrastructure. This approach nevertheless still requires a party to select the participants in its transactions and for them all to becomes members of the Bolero organization. Hence, it is appropriate primarily for large organizations with existing networks of international trade partners (e.g. sellers, exporters, importers, carriers, freight forwarders, financial institutions etc.) which are seeking to increase the efficiency of existing processes. It does not serve an entity inexperienced in international trade, such as a business buyer who simply wishes to receive a consignment of goods from abroad but does not wish to develop relationships and negotiate contracts with the large number of entities necessarily involved with international trade transactions.

SUMMARY OF THE INVENTION

What is needed therefore is an efficient way to facilitate and coordinate interactions between trading parties. The present invention is directed toward such a way.

The present invention, in one aspect, provides a server running a program for a web-based service for buyers to enter into national and/or international trade transactions with sellers, in which a number of additional participants can potentially participate, the additional participants including: insurers, financial institutions offering credit to buyers or verifying a buyer's creditworthiness, escrow agents holding payment monies pending delivery of goods or services, logistics co-ordinators, including shippers and freight forwarders, and inspectors of goods or production processes. Some or all of the additional participants that actually participate in a given transaction may not be selected by either of the buyers or sellers but instead may have been previously selected by a central co-ordinating authority prior to the transaction.

Because the central controller has pre-selected all of the additional participants required to complete a business to business trade transaction, including even a complex international trade transaction, this aspect of the invention greatly simplifies such transactions for buyers and sellers. For buyers or sellers inexperienced in such transactions, this is particularly appealing.

Preferably, potential buyers place bid amounts with the central co- ordinating authority, so that the system becomes a dynamic auction with the market setting the price at which goods are sold on the basis of supply and demand. The bid amounts may be based on a per item or per unit price, rather than a price for a complete consignment of goods, such that in one embodiment a buyer is able to bid successfully for a portion of a single consignment, with the goods being shipped or otherwise transported once other buyers have successfully bid for the remaining items in a consignment. This makes it possible for relatively small scale buyers to buy goods without having to buy a complete consignment: so for example, where a complete consignment constitutes 500 microwave ovens, a given buyer need only bid against a unit price for a total of 50 ovens. When the remaining 450 ovens are sold, the shipment occurs.

One particular application for the present invention is in the auction of excess inventory, such as liquidation stock, overruns and cancelled orders. Existing processes for selling such inventory are haphazard, fragmented and inefficient. Buyers for such goods include discounters, resellers, wholesalers, auctioneers, and liquidators.

One aspect of the present invention may therefore provide a central controller for coordinating the parties to a transaction. The parties enter into agreements with the central controller and, through the central controller, enter into agreements with each other. This arrangement enables the central controller to synchronize the parties in performing their obligations to each other and to produce an audit log of each party's performance of its obligations.

Advantageously, this arrangement also fosters a network of experienced parties with documented capabilities available to transact. Because the parties are already members of the network, little cost or delay is incurred in concluding agreements specific to a desired new transaction. Additionally, when the parties value their access to this network, they are disposed to meet their obligations to avoid censure and maintain such access.

In another aspect, there is provided a web-based service for buyers to enter into trade transactions with sellers, in which a potential buyer can select items of goods for sale from one or more sellers, and cause a list only of the selected items to be displayed for viewing by that particular potential buyer at his client device. In this way, a potential buyer can monitor the progress of, for example, auctions of items of interest, in a convenient way. It removes the need for a potential buyer to navigate through the whole of an auction site simply to find the items that were previously of interest. Instead, those items are presented to the potential buyer as a personalized listing. According to one aspect of the present invention, there is provided a method and corresponding apparatus for facilitating trade. The method and apparatus provide for: presenting an offer by a group to provide a lot comprising at least one item; selecting a winning bid received from a winning bidder, selected from bids received from bidders bidding consideration in satisfaction of the offer presented; and fulfilling the offer and the winning bid by arranging for the group to receive the consideration that was bid in the winning bid and for the winning bidder to receive the lot.

The members of the group may be chosen from a list including: seller, insurer, shipper, inspector, financer, and escrow agent. The choice may be made by a seller or one bidder, or by a central controller. Where the controller chooses, it may receive payment from the chosen member.

The offer presented may include terms dependent on a bid received. For example, the membership of the group may so depend. Furthermore, terms of the offer may depend on a characteristic or preference of a bidder.

Thus the selection of financer, for example, may depend on the location of a bidder.

Presenting the offer may include validating the group, for example, assessing the businessworthiness of at least one member of the group. Validating the group may include monitoring infractions by a member of the group, an example infraction being an occasion when a member failed to meet an obligation as offered. Furthermore, presenting the offer may include validating the offer itself, which may necessitate requesting an inspection of the lot for example and then reporting the results of the inspection. Additionally, presenting the offer may include presenting the costs for inspecting the lot.

Presenting the offer may also include presenting other anticipated costs, for example: shipping costs, customs costs, taxation costs, duty costs, insurance costs, escrow costs, credit costs, and commission costs. Effectively, presenting the offer may include presenting the total cost to deliver the lot to a bidder. Presenting the offer may be achieved by presenting many offers, for example in response to a search request or upon identifying a submitter of a previously submitted search request.

Presenting the offer may include presenting the total cost to deliver the lot to a bidder divided by a number of items in the lot to yield a per item cost.

By extension, selecting a winning bid may include selecting the winning bid from various bids submitted in satisfaction of less than the number of items in the lot. Such bids might be expressed as a per item cost and a quantity of items for less than the total number of items in the lot, for example. Thus, a number of winning bids might be selected from among a number of bids expressed as a per item cost and a quantity of items so long as the combined quantity of items for all of the bids selected is less than or equal to the number of items in the lot.

Fulfilling might include arranging for: full payment for the lot, a letter of credit pledged for the lot, or escrowing the lot and the payment for the lot.

Fulfilling might also include arranging for: inspection of the lot, delivery of the lot, or insurance of the lot.

Presenting, selecting, and fulfilling might be coordinated by exchanging a token between nodes in a network having a central controller and peripheral processors in communication with the central controller, each peripheral processor respectively operated by a bidder or at least one of the group making the offer. Exchanging the token might include securely signing the token at one of the nodes and might include exchanging data between the token and at least one of the plurality of nodes, for example exchanging a request that another one of the nodes perform an action or performing an action at one of the nodes in response to the data exchanged. In this regard, it may be desirable to present a database entry form mapped to the exchanged data at one the nodes and to maintain a database having a list of prior token exchanges and a list of planned token exchanges. Preferably, exchanging the token comprises exchanging at least a portion of the database between the token and a node.

There might further be provided a bidder interface apparatus configured to communicate with the apparatus via the communication network and having: a processor; a communication port to connect the processor to the communication network; and a memory storing codes for directing the processor to communicate a token via the communication port, communicating including at least one of transmitting a token to the communication port and receiving a token from the communication port, such that the bidder interface can transmit a token to the apparatus and to receive a token from the apparatus.

There might further be provided a seller interface apparatus configured to communicate with the apparatus via the communication network and having: a processor; a communication port to connect the processor to the communication network; and a memory storing codes for directing the processor to communicate a token via the communication port, communicating including at least one of transmitting a token to the communication port and receiving a token from the communication port, such that the seller interface can transmit a token to the apparatus and to receive a token from the apparatus.

There might further be provided an insurer interface apparatus configured to communicate with the apparatus via the communication network and having: a processor; a communication port to connect the processor to the communication network; and a memory storing codes for directing the processor to communicate a token via the communication port, communicating including at least one of transmitting a token to the communication port and receiving a token from the communication port, such that the insurer interface can transmit a token to the apparatus and to receive a token from the apparatus. There might further be provided a shipper interface apparatus configured to communicate with the apparatus via the communication network and having: a processor; a communication port to connect the processor to the communication network; and a memory storing codes for directing the processor to communicate a token via the communication port, communicating including at least one of transmitting a token to the communication port and receiving a token from the communication port, such that the shipper interface can transmit a token to the apparatus and to receive a token from the apparatus.

There might further be provided an inspector interface apparatus configured to communicate with the apparatus via the communication network and having: a processor; a communication port to connect the processor to the communication network; and a memory storing codes for directing the processor to communicate a token via the communication port, communicating including at least one of transmitting a token to the communication port and receiving a token from the communication port, such that the inspector interface can transmit a token to the apparatus and to receive a token from the apparatus.

There might further be provided an escrow agent interface apparatus configured to communicate with the apparatus via the communication network and having: a processor; a communication port to connect the processor to the communication network; and a memory storing codes for directing the processor to communicate a token via the communication port, communicating including at least one of transmitting a token to the communication port and receiving a token from the communication port, such that the escrow agent interface can transmit a token to the apparatus and to receive a token from the apparatus.

There might further be provided a financer interface apparatus configured to communicate with the apparatus via the communication network and having: a processor; a communication port to connect the processor to the communication network; and a memory storing codes for directing the processor to communicate a token via the communication port, communicating including at least one of transmitting a token to the communication port and receiving a token from the communication port, such that the financer interface can transmit a token to the apparatus and to receive a token from the apparatus.

According to another aspect of the invention, there is provided a computer readable medium for providing codes for directing a processor to: present an offer by a group of at least two parties to provide a lot comprising at least one item comprising at least one of a product and a service; select at least one winning bid received from at least one winning bidder, selected from at least one bid received from at least one bidder bidding consideration in satisfaction of the offer presented; and fulfill the offer and the at least one winning bid by arranging for the group to receive the consideration that was bid in the at least one winning bid and for the at least one winning bidder to receive the lot.

According to another aspect of the invention, there is provided a signal embodied in a carrier wave, the signal having code segments for directing a processor, the signal having: a first code segment directing the processor to present an offer by a group of at least two parties to provide a lot comprising at least one item comprising at least one of a product and a service; a second code segment directing the processor to select at least one winning bid received from at least one winning bidder, selected from at least one bid received from at least one bidder bidding consideration in satisfaction of the offer presented; and a third code segment directing the processor to fulfill the offer and the at least one winning bid by arranging for the group to receive the consideration that was bid in the at least one winning bid and for the at least one winning bidder to receive the lot. According to yet another aspect of the invention, there is provided a system, including a central controller having a network interface configured: to communicate with a seller interface apparatus and to receive from the seller interface apparatus an offer to provide an item including at least one of a product and a service; to communicate with a bidder interface apparatus and to receive from the bidder interface apparatus a bid in satisfaction of the offer; to communicate with a shipper interface apparatus and to receive from the shipper interface apparatus particulars for shipping the item from a seller associated with the seller interface apparatus to a bidder associated with the bidder interface apparatus; and to communicate with an insurer interface apparatus and to receive from the insurance interface apparatus particulars of insurance coverage for shipping the item from the seller to the bidder.

The system might further include a seller interface apparatus in communication with the network interface, a bidder interface apparatus in communication with the network interface, a shipper interface apparatus in communication with the network interface, or an insurer interface apparatus in communication with the network interface.

The network interface might further be configured: to communicate with an inspector interface apparatus to receive from the inspector interface apparatus particulars of an inspection of the item, to communicate with a financer interface apparatus and to receive from the financer interface apparatus particulars of trade facilities extended to the bidder that may include credit, for example a letter of credit or a line of credit, or to communicate with an escrow agent interface apparatus and to receive from the escrow agent interface apparatus particulars of an escrow established between the bidder and the seller pertaining to the item. Thus the system might further include an inspector interface apparatus in communication with the network interface, a financer interface apparatus in communication with the network interface, or an escrow agent interface apparatus in communication with the network interface. According to yet another aspect of the invention, there is provided a server running a program for a web-based service for buyers to enter into at least one of national and international trade transactions with sellers, in which a number of additional participants can potentially participate, the additional participants being selected from the following list: insurers; financial institutions offering trade facilities to buyers; escrow agents for holding funds submitted by buyers; logistics co-ordinators, comprising shippers and freight forwarders; and inspectors of goods or production processes; in which at least one of the additional participants which actually participates in a given transaction is not selected by either of the buyers or sellers but instead has been previously selected by a central co-ordinating authority prior to the transaction. At least one of the additional participants may pay a fee to the central co-ordinating authority to participate in a given transaction.

In one embodiment, the server is configured such that a buyer bids an amount for goods of interest based on a per unit price, rather than a price for a complete consignment of goods, with a buyer being able to bid successfully for a part only of a single consignment, with the goods being shipped or otherwise transported once other buyers have successfully bid for the remaining items in a consignment.

Desirably, the server stores substantially all of the information required for all participants to fully participate in a transaction.

According to yet another aspect of the invention, there is provided a server running a program for a web-based service for buyers to enter into trade transactions with sellers, in which a potential buyer can select items of goods for sale from one or more sellers, and cause a list only of the selected items to be displayed for viewing by that particular potential buyer at his client device.

Further aspects and advantages of the present invention will become apparent upon considering the following drawings, description, and claims. BRIEF DESCRIPTION OF THE DRAWINGS

In drawings that illustrate embodiments of the invention:

Figure 1 is a block diagram of a system for processing transactions according to one aspect of the invention, the system having a plurality of nodes including a central controller and a plurality of peripheral interfaces each connected to the central controller, including at least one of each of a seller interface, a buyer interface, a financer interface, a shipper interface, an insurer interface, an inspector interface, and an escrow agent interface.

Figure 2 is a block diagram of the architecture of each node of Figure 1 , including the central controller and the plurality of peripheral interfaces, each node having a data storage device.

Figure 3 is a data structure diagram detailing the data storage device of the central controller of Figure 1 , the data storage device storing a plurality of databases including a token database.

Figure 4 is a data structure diagram detailing the data storage device of the seller interface of Figure 1.

Figure 5 is a data structure diagram detailing the data storage device of the buyer interface of Figure 1.

Figure 6 is a data structure diagram detailing the data storage device of the financer interface of Figure 1. Figure 7 is a data structure diagram detailing the data storage device of the shipper interface of Figure 1. Figure 8 is a data structure diagram detailing the data storage device of the inspector interface of Figure 1. Figure 9 is a data structure diagram detailing the data storage device of the insurer interface of Figure 1. Figure 10 is a data structure diagram detailing the data storage device of the escrow agent interface of Figure 1.

Figure 11 is a data structure diagram of a token exchanged between the nodes of Figure 1. Figure 12 is a data structure diagram detailing the token database stored in the central controller data storage device of Figure 3. Figure 13 is a flowchart of a seller registration process transacted between the central controller, the seller interface, and the financer 5 interface of Figure 1.

Figure 14 is a seller registration form view into the plurality of databases stored in the central controller data storage device of Figure 3 and as manipulated by tokens exchanged between the central controller, the seller interface, and the financer interface of Figure o 1 in the seller registration process of Figure 13.

Figure 15 is a flowchart of an auction configuration process transacted between the central controller, the seller interface, the shipper interface, and the inspector interface of Figure 1. Figure 16 is an auction configuration form view into the plurality of s databases stored in the central controller data storage device of

Figure 3 and as manipulated by tokens exchanged between the central controller, the seller interface, the shipper interface, and the inspector interface of Figure 1 in the auction configuration process of Figure 15. o Figure 17 is a pre-bid shipping quotation form view into the plurality of databases stored in the central controller data storage device of Figure 3 and as manipulated by tokens exchanged between the central controller, the seller interface, and the shipper interface of Figure 1 in the auction configuration process of Figure 15. 5 Figure 18 is an inspection charge form view into the plurality of databases stored in the central controller data storage device of Figure 3 and as manipulated by tokens exchanged between the central controller, the seller interface, and the inspector interface of Figure 1 in the auction configuration process of Figure 15. o Figure 19 is a flowchart of a buyer registration process transacted between the central controller, the buyer interface, and the financer interface of Figure 1. Figure 20 is a buyer registration form view into the plurality of databases stored in the central controller data storage device of Figure 3 and as manipulated by tokens exchanged between the central controller, the buyer interface, and the financer interface of Figure 1 in the buyer registration process of Figure 19.

Figure 21 is a flowchart of an anonymous auction searching process transacted between the central controller and the buyer interface of Figure 1.

Figure 22 is a flowchart of a registered auction searching process transacted between the central controller and the buyer interface of Figure 1.

Figure 23 is an auction search screen form view into the plurality of databases stored in the central controller data storage device of

Figure 3 and as manipulated by tokens exchanged between the central controller and the buyer interface of Figure 1 in the either the anonymous auction searching process of Figure 21 or the registered auction searching process of Figure 22.

Figure 24 is a flowchart of an auction bidding process transacted between the central controller, the seller interface, and a plurality of buyer interfaces of Figure 1.

Figure 25 is an auction bid detail form view into the plurality of databases stored in the central controller data storage device of Figure 3 and as manipulated by tokens exchanged between the central controller, the seller interface and the plurality of buyer interfaces of Figure 1 in the auction bidding process of Figure 24.

Figure 26 is a flowchart of a post-bidding process transacted between the central controller, the seller interface, a plurality of buyer interfaces, and the shipper interface of Figure 1.

Figure 27 is a post-bid request for quotation form view into the plurality of databases stored in the central controller data storage device of

Figure 3 and as manipulated by tokens exchanged between the central controller, the seller interface, the plurality of buyer interfaces, and the shipper interface of Figure 1 in the post- bidding process of Figure 26. Figure 28 is a post-bid shipping quotation form view into the plurality of databases stored in the central controller data storage device of 5 Figure 3 and as manipulated by tokens exchanged between the central controller, the seller interface, the plurality of buyer interfaces, and the shipper interface of Figure 1 in the post- bidding process of Figure 26. Figure 29 is a quotation consolidation form view into the plurality of o databases stored in the central controller data storage device of

Figure 3 and as manipulated by tokens exchanged between the central controller, the seller interface, the plurality of buyer interfaces, and the shipper interface of Figure 1 in the post- bidding process of Figure 26. s Figure 30 is a flowchart of a letter of credit issuance process transacted between the central controller, the seller interface, the buyer interface, a buyer-financer interface, and a seller-financer interface of Figure 1. Figure 31 is an application for irrevocable letter of credit form view into the o plurality of databases stored in the central controller data storage device of Figure 3 and as manipulated by tokens exchanged between the central controller, the seller interface, the buyer interface, a buyer-financer interface, and a seller-financer interface of Figure 1 in the first embodiment fulfillment - letter of 5 credit issuance process of Figure 30.

Figure 32 is a flowchart of a first embodiment logistics fulfillment process transacted between the central controller, the seller interface, the buyer interface, a buyer-financer interface, a seller-financer interface, a shipper interface, an insurer interface, and an o inspector interface of Figure 1.

Figure 33 is an insurance cover note form view into the plurality of databases stored in the central controller data storage device of Figure 3 and as manipulated by tokens exchanged between the central controller, the seller interface, the buyer interface, a buyer- financer interface, a seller-financer interface, shipper interface, insurer interface, and inspector interface of Figure 1 in the first embodiment logistics fulfillment process of Figure 32.

Figure 34 is a flowchart of a second embodiment logistics fulfillment process transacted between the central controller, the seller interface, the buyer interface, an escrow interface, a seller- financer interface, a shipper interface, an insurer interface, and an inspector interface of Figure 1.

Figure 35 is a flowchart of a first embodiment inspection process transacted between the central controller and inspector interface of Figure 1.

Figure 36 is a flowchart of a second embodiment inspection process transacted between the central controller and inspector interface of Figure 1.

Figure 37 is a flowchart of a supervisory process transacted between the central controller and one of the peripheral interfaces of Figure 1.

Figure 38 is a flowchart of a supervisory process transacted between the central controller and two of the peripheral interfaces of Figure 1.

DETAILED DESCRIPTION Overview

Internet business auctions are expected to grow to $55 billion by 2002, creating unprecedented new markets for sellers and lower costs and expanded access for buyers.

The present invention is exemplified by the independent auction web site, VLINX.com, for surplus manufactured goods, such as closeout, dead inventory, seconds and refurbished goods. Prior to VLINX.com, this was a highly fragmented and inefficient market segment in the business-to-business sector. VLINX.com appeals to sellers of such goods because of its ease of use, the effectiveness of competitive bidding, and the ability to reach new buyers. The direct door-to-door transaction convenience provided through this web site is far superior to conventional approaches: Buyers gain access to a wider range of goods at highly competitive prices, utilizing web based software for lower information and transaction costs with the prior need to locate and negotiate terms with banks, insurers, shippers, freight forwarders etc. entirely removed. Thus, the small buyer should no longer be at a disadvantage or unable to participate in trade transactions requiring such intermediaries or service providers.

The VLINX.com system encourages lower sales costs through a competitive bidding process, while moving goods quickly at lower cost to the seller than direct sales, catalogs, or offline auctions. The VLINX.com technology provides sellers with a communication and database infrastructure that encourages buyers and service providers to actively participate in sales processes conducted through the infrastructure, resulting in lower costs to sellers than are generally associated with more conventional sales processes.

Furthermore, parties to a conventional sales process pay varying markups or fees based on channel power, market segment, personal relationships or historical volume; in contrast, at VLINX.com, transaction costs are transparent to all parties online.

Part of the appeal of VLINX.com to sellers is the ability to fine tune inventory levels. Forecasting errors like overestimating the market's interest in a new product launch, competitive acts like vertical acquisitions that lock up sellers, or external factors like the weather or the Asian currency crisis can be fixed at lower costs.

As noted above, VLINX.com establishes long-term relationships with service providers involved in commodities trading transactions, including banks, insurance companies, escrow agents, shippers, inspectors, customs brokers. VLINX.com and these service providers, or "program partners", provide all of the infrastructure necessary to implement trade transactions, including services for: inspecting and rating goods for sale; facilitating payment through escrow arrangements, credit arrangements including credit lines and letters of credit, and opining on a party's businessworthiness including creditworthiness; tracking orders online, accounting for transactions, including providing detailed invoicing; and shipping goods hassle-free door-to-door. The VLINX.com central controller, or hub, directs and controls the activities of the program partners in a secure environment. The hub is a prerequisite to delivery of the painless, seamless, door-to-door service and also represents the key to the VLINX.com royalty revenue model since the program partners pay a proportion of their revenues to the hub. The functions of the program partners are as follows.

The escrow agent program partner provides security for buyers and sellers, in that purchase monies are not released and titles are not transferred unless and until a logistics program partner has verified completion of all purchase order conditions and so advised the hub and, through the hub, the escrow agent program partner.

The banking program partner's primary role is to opine on the businessworthiness of transacting parties, including securing payment from buyers and issuing letters of credit in favor of sellers. The process encourages more activity on the part of buyers and addresses a key seller requirement of guaranteed payment. The banks are also responsible for deduction of service charges from proceeds and payment of the service charges to VLINX.com and other program partners, thereby eliminating the risk or the need for receivable collections.

The insurance program partner provides cargo insurance on a global scale.

The shipping program partner either possesses or has access to a global network of logistics, and shipping companies, freight forwarders and customs brokers.

The inspection program partner inspects items offered for sale and plants and processes for producing items for sale, to establish that items meet agreed upon specifications or to establish what specification defines an item.

Once a buyer with a winning bid has been determined, the VLINX.com software promptly notifies each and every program partner of the salient transaction details and the machinery is set in motion, automatically, and efficiently, to advance and complete the transaction.

Because the VLINX.com hub pre-selects all these service providers and mandates standard contractual terms, buyers and sellers do not need to go through the laborious and expensive process of researching these kinds of providers and negotiating terms with them. VLINX.com has performed all of those tasks, thus greatly simplifying the process from the perspective of a buyer or seller. The VLINX.com system in effect presents a world of international trade possibilities to even the smallest business.

Because VLINX.com uses an auction approach, it is the market that determines pricing, dynamically and according to supply and demand and capacity on a global basis. Whereas one product may be overproduced or over supplied in one market, it may very well have a different value due to demand in another market. VLINX.com markets to business buyers willing to buy surplus, used, end-of-life, or refurbished items at a discount. These buyers, who have historically had restricted choices, are currently buying from liquidation brokers at a slight discount or from retailers selling refurbished goods at non-negotiable prices. VLINX.com customers, buying through the VLINX.com web site, have more control through competitive bidding and by eliminating the middleman.

In this regard, Figure 1 illustrates a communication network 100, according to one aspect of the present invention, for facilitating transactions between parties. The network 100 includes a plurality of nodes 102 arranged in hub and spoke topology. The nodes 102 include a controller 104 at the hub and at least one of each of a seller interface 106, a bidder interface 108, a financer interface 110, an insurer interface 112, a shipper interface 114, an inspector interface 116, and an escrow agent interface 118. The respective interfaces permit respective parties to a transaction to receive information about the transaction and to send information when prompted to do so.

In this embodiment, each node 102 includes a general purpose programmable digital computer, as will be discussed below in further detail with respect to Figure 2. Nevertheless, any node 102 might include instead or as well: a telephone including a cellular, radio, satellite, cordless, or other mobile telephone, a facsimile machine, a telex machine, a telephony device, an electronic mail terminal, a palmtop computing device, an appliance with embedded logic circuits, or a message receptacle such as a postal box or a receiving desk. In essence, each node 102 must provide for the timely receipt and transmission of messages.

The nodes 102 are connected together through a plurality of communication channels 120. In this embodiment, each communication channel 120 might include a portion of a public switched telephone network, a private voice or data network, a postal or courier route, or a transportation path such as a roadway, a railway, a waterway, or an airway. Each communication channel 120 might include electromagnetic or optical links, including twisted pair cable, coaxial cable, optical fibre, or radio paths of any frequency including for example microwave frequencies. The network 100 might include circuit- switched, packet-switched, or virtual circuit links.

In one embodiment, the network 100 is implemented using Transmission Control Protocol / Internet Protocol (TCP/IP). More specifically, the network 100 is implemented as a secure virtual private network within the Internet. ln essence, each node 102 provides a transacting party with a presence on the communication network 100 and the ability to exchange timely messages concerning transactions.

Implementation Figure 2 illustrates a node 102 in greater detail. In this embodiment, the node 102 includes a general purpose programmable digital computer 130, for example an IBM PC 300PL^® microcomputer sold by International Business Machines Corporation, of New Orchard Road, Armonk, New York, 10504, United States of America, (914) 499-1900. Those skilled in the art will appreciate that the choice of computer depends on the storage, processing, and communication requirements placed upon it, and that other choices would also be suitable. Thus, a node might instead include a network of computers, a server farm, one or more minicomputers, one or more mainframe computers, or one or more supercomputers to meet different requirements. There is no expectation that all the nodes 102 are identically specified.

Each computer 130 includes a main processor 132, in this embodiment a Pentium III^® processor sold by Intel Corporation, 2200 Mission College Blvd. Santa Clara, California, 95052-8119 United States of America, (408)-765-8080.

The main processor 132 is in bus communication with a random access memory (RAM) 134, a read only memory (ROM) 136, a synchronizing clock

138, a data storage device 140, an input interface 142, and an output interface 144 to provide the conventional functionality of a general purpose programmable digital computer 130. The data storage device 140 might include an electromagnetic or optical storage medium, might be single or arrayed, might be fixed or removable, and is desirably capable of both recording and retrieving data. An input device 146, for example a keyboard or a mouse, is in communication with the input interface 142. An output device 148, for example a video monitor or a printer, is in communication with the output interface 144. The main processor 132 is also in bus communication with a network interface 150 and a dedicated encryption processor 152, for example an MC68HC16 microcontroller sold by Motorola Inc., 1303 E. Algonquin Road, Schaumburg, Illinois, 60196, United States of America, (847) 576-5000. The network interface 150 is in communication with one of the communication channels 120. The encryption processor 152 is programmed with stored codes to manage encryption and decryption keys and to encrypt and decrypt data using the keys. Thus, with access to the network interface 150 and the encryption processor 152, the main processor 132 is enabled to encrypt and transmit signals to and receive and decrypt signals from other nodes 102 on the network 100. It will be appreciated that the functionality of the encryption processor 152 might also be implemented in the main processor 132. It will also be appreciated that some information relating to a transaction may not require encryption and that some parties to a transaction may not wish to use encryption. Thus, some embodiments of a node 102 may not include an encryption processor 152 or a main processor 132 programmed to implement the functionality of an encryption processor 152.

An operating system program is encoded in the computer 130 for directing the main processor 132 to interact with peripheral devices and interface components, including the random access memory (RAM) 134, the read only memory (ROM) 136, the clock 138, the data storage device 140, the input interface 142, the output interface 144, the network interface 150, and the encryption processor 152. The operating system program also provides an interface through which application software codes can direct the microprocessor to interact with the peripheral devices and interface components. Portions of the operating system program might be encoded in the RAM 134, the ROM 136, or the data storage device 140. In this embodiment, the operating system includes the Windows NT^® operating system, sold by Microsoft Corporation, One Microsoft Way, Redmond, Washington, 98052-6399, United States of America, (425) 882-8080. Those skilled in the art will appreciate that the Windows NT^® operating system includes network clients, including Internet Explorer^®, an Internet browser capable of transmitting signals to and receiving signals from the Internet. They will further appreciate that Internet Explorer^® implements a Java^® Virtual Machine to transmit, receive, and interpret codes in the Java" programming language propagated by Sun Microsystems, Inc., 901 San Antonio Road, Palo Alto, California 94303, United States of America, (800) 555-9786. It will appreciate, however, that the invention does not depend on the particular Internet browser implemented.

Figures 3 through 10 illustrate the configuration of the data storage device 140 in each of the controller 104, the seller interface 106, the bidder interface 108, the financer interface 110, the insurer interface 112, the shipper interface 114, the inspector interface 116, and the escrow agent interface 118 nodes respectively. These data storage devices are configured to include a plurality of databases, which are preferably created and maintained using a database management system. The databases record the information signaled between nodes 102 over the network 100. It will be appreciated that in a less advanced embodiment, the databases might be maintained on paper using file folders and indices.

The database system might be hierarchical, network, relational, object oriented, or object-relational; however, in the present embodiment, it is an object-oriented database management system, for example, GemStone/J® sold by GemStone Systems, Inc. 20575 NW von Neumann Drive, Beaverton, OR, 97006, United States of America, (503) 533-3000.

Focusing first on Figure 3, the controller 104 includes a data storage device 140 structured to include a seller database 150, a bidder database 152, a financer database 154, a shipper database 156, an inspector database 158, an insurer database 160, an escrow agent database 162, an encryption key database 164, a token database 166, an auction database 168, a bid database 170, a quotation consolidation database 172, an inspection database 174, a shipment database 176, a letter of credit database 178, an insurance database 180, a purchase agreement database 181 , and an audit database 182.

The seller database 150 maintains records concerning any entity connected to the network 100 through a seller interface 106. Such records include a unique record-key field, hereinafter referred to as a Seller-ID, as well as contact, business, and accounting fields as more fully discussed below with respect to the depiction in Figure 14 of a seller registration form.

The bidder database 152 maintains records concerning any entity connected to the network 100 through a bidder interface 108. Such records include a unique record-key field, hereinafter referred to as a Bidder-ID, as well as contact, business, and accounting fields as more fully discussed below with respect to the depiction in Figure 20 of a buyer registration form.

The financer database 154 maintains records concerning any entity connected to the network 100 through a financer interface 110. Such records include a unique record-key field, hereinafter referred to as a Financer-ID, as well as contact, business, and accounting fields as more fully discussed below with respect to the depiction in Figure 14 of a seller registration form, the depiction in Figure 20 of a buyer registration form, the depiction in Figure 29 of a quotation consolidation form, and the depiction in Figure 31 of an application for irrevocable letter of credit form.

The shipper database 156 maintains records concerning any entity connected to the network 100 through a shipper interface 114. Such records include a unique record-key field, hereinafter referred to as a Shipper-ID, as well as contact, business, and accounting fields as more fully discussed below with respect to the depiction in Figure 17 of a pre-bid shipping quotation form, the depiction in Figure 25 of an auction bid detail form, and the depiction in Figure 28 of a post-bid shipping quotation form. The inspector database 158 maintains records concerning any entity connected to the network 100 through an inspector interface 116. Such records include a unique record-key field, hereinafter referred to as an Inspector-ID, as well as contact, business, and accounting fields as more fully discussed below with respect to the depiction in Figure 18 of a inspection charge form.

The insurer database 160 maintains records concerning any entity connected to the network 100 through an insurer interface 112. Such records include a unique record-key field, hereinafter referred to as an Insurer-ID, as well as contact, business, and accounting fields as more fully discussed below with respect to the depiction in Figure 33 of an insurance cover note form.

The escrow agent database 162 maintains records concerning any entity connected to the network 100 through an escrow agent interface 118. Such records include a unique record-key field, hereinafter referred to as an Escrow- Agent-ID, as well as contact, business, and accounting fields

The encryption key database 164 maintains a record of the public-key associated with each entity connected to the network 100 at a node 102.

The token database 166 maintains a record of each token exchanged between nodes 102 on the network 100. Each record includes a unique record-key field, hereinafter referred to as a Token-ID. Tokens will be described in more detail below with respect to the depiction in Figure 11 of a token data structure diagram and the token database 166 will be described in more detail below with respect to the depiction in Figure 12 of a data structure diagram detailing the token database 166.

The auction database 168 maintains records for each auction of goods or services (collectively "items") offered by a seller interface 106 and authorized by the controller 104 node. Such records include a unique record-key field, hereinafter referred to as an Auction-ID, as well as fields detailing the items offered and the scope of the offer as more fully discussed below with respect to the depiction in Figure 16 of an auction configuration form. It must be understood that the word auction is used broadly in this sense to connote any form of trading or transaction.

The bid database 170 maintains records for each bid submitted in an auction through a bidder interface 108 and approved by the controller 104 node. Such records include a unique record-key field, hereinafter referred to as a Bid-ID, as well as fields detailing the bid submitted as more fully discussed below with respect to the depiction in Figure 25 of an auction bid detail form.

The quotation consolidation database 172 maintains records for each successful closing of an auction, when the controller 104 node determines that an auction has closed and a particular bid submitted by a bidder interface 108 was the highest bid submitted by the time that the auction closed. Such records include a unique record-key field, hereinafter referred to as a Consolidation-ID, as well as fields detailing consolidated purchase and fulfillment costs as more fully discussed below with respect to the depiction in Figure 29 of a quotation consolidation form. Essentially, the quotation consolidation form depicted in Figure 29 provides a buyer and a seller with a final opportunity to review, modify, and accept the details of a proposed transaction in which the successful bid is submitted as total consideration for both the offered item and all the actions that must be undertaken to deliver possession of and title in the offered item and the bid monies to the appropriate parties.

The inspection database 174 maintains records for each inspection of items conducted pursuant to an auction of the items. Such records include a unique record-key field, hereinafter referred to as an Inspection-ID, as well as fields detailing the inspection as more fully discussed below with respect to the depiction in Figure 18 of an inspection charge form. The shipment database 176 maintains records for each shipment quotation and shipment associated with items offered in an auction. Such records include a unique record-key field, hereinafter referred to as a Shipment- ID, as well as fields detailing shipment quotations, including customs duties and taxes, and shipment details as more fully discussed below with respect to the depiction in Figure 16 of an auction configuration form, the depiction in Figure 17 of a pre-bid shipping quotation form, the depiction in Figure 25 of an auction bid detail form, the depiction in Figure 27 of a post-bid request for quotation form, the depiction in Figure 28 of a post-bid shipping quotation form, and the depiction in Figure 29 of a quotation consolidation form.

The letter of credit database 178 maintains records for each letter of credit pledged toward items purchased in an auction. Such records include a unique record-key field, hereinafter referred to as a LofC-ID, as well as fields detailing the letter of credit as more fully discussed below with respect to the depiction in Figure 31 of an application for irrevocable letter of credit.

The insurance database 180 maintains records for each insurance policy insuring items purchased in an auction. Such records include a unique record-key filed, hereinafter referred to as a Policy-ID, as well as fields detailing the policy as more fully discussed below with respect to the depiction in Figure 33 of an insurance cover note form.

The purchase agreement database 181 maintains a library of templates of agreements. Depending on the jurisdictions governing the parties of a particular transaction, it may be necessary for certain understandings reached online to be formally documented by an executed agreement expressed in a particular format on paper. Thus the purchase agreement database 181 maintains a library of templates of such agreements, into which templates can be merged the necessary information relating to any particular transaction as recorded in the other databases described herein. A resulting agreement may then be communicated in electronic form to the appropriate node 102 on the network 100, for conversion into paper format using a printer, a facsimile machine, or a telex, for example. Once in paper format, the agreement can be duly executed as necessary to comply with the legal requirements of a particular jurisdiction governing some of the parties to the particular transaction.

The audit database 182 maintains records of all transactions relating respectively to each auction and completed transaction as may be necessary to evidence facts that would assist a court to determine fault or liability should a disputed loss occur. The audit database would maintain time-stamped copies of appropriate records or fields maintained by the databases and forms described above and would have significant access restrictions to increase the credibility of the database.

Those skilled in the art will appreciate that there are many ways to structure databases and that one might chose to store fields in different databases than described in this embodiment or might even chose to implement a different number of databases than described in this embodiment.

Such choices would not depart from the spirit of the invention.

The data storage device 140 further stores a collection of business objects 184, for example agents, which model the events and business processes that underlie the transactions conducted over the network 100. The business objects 184 describe attributes, relationships, and behaviors, and may include threads of artificial intelligence. In this embodiment, the business objects 184 are created and maintained using a software application called Visual Knowledge® sold by Big Server Software, Inc., 200 - 1682 West 7^th Avenue, Vancouver, British Columbia, Canada, V6J 4S6, (604) 730-0086. In general, the business objects 184 are dormant until a predetermined event occurs, at which occurrence they direct the main processor 132 to perform a predetermined function.

The business objects 184 will be better understood with reference to: Figure 13, which depicts a flowchart of a seller registration process transacted between the central controller 104, the seller interface 106 and the financer interface 110; Figure 15, which is a flowchart of an auction configuration process transacted between the central controller 104, seller interface 106, the shipper interface 114, and the inspector interface 116; Figure 19, which is a flowchart of a bidder registration process transacted between the central controller 104, the bidder interface 108, and the financer interface 110; Figure 21, which is a flowchart of an anonymous auction searching process transacted between the central controller 104 and the bidder interface108; Figure 22, which is a flowchart of a registered auction searching process transacted between the central controller 104 and the bidder interface 108; Figure 24, which is a flowchart of an auction bidding process transacted between the central controller 104, the seller interface 106, and a plurality of bidder interfaces 108; Figure 26, which is a flowchart of a post-bidding process transacted between the central controller 104, the seller interface106, a plurality of bidder interfaces 108, and the shipper interface 114; Figure 30, which is a flowchart of a first embodiment fulfillment - letter of credit issuance process transacted between the central controller 104, the seller interface 106, the bidder interface 108, a bidder-financer interface 110, and a seller-financer interface110; Figure 32, which is a flowchart of a first embodiment fulfillment - logistics process transacted between the central controller 104, the seller interface 106, the bidder interface 108, a bidder-financer interface 110, a seller- financer interface 110, shipper interface 114, insurer interface 112, and inspector interface 116; Figure 34, which is a flowchart of a second embodiment fulfillment - logistics process transacted between the central controller 104, the seller interface 106, the bidder interface 108, a seller- financer interface 110, a shipper interface 114, an insurer interface 112, an inspector interface 116, and an escrow interface 118; Figure 35, which is a flowchart of a first embodiment inspection process transacted between the seller interface 106 and an inspector interface 116; and Figure 36, which is a flowchart of a second embodiment inspection process transacted between the central controller 104, the seller interface 106, and an inspector interface 116. The databases 150, 152, 154, 156, 158, 160, 162, 164, 166, 168, 170, 172, 174, 176, 178, 180, 182 and the collection of business objects 184 may be implemented using software objects that are accessible from other nodes 102 on the network 100. To this end, the data storage device 140 further maintains an object request broker 186 compliant with the Object Management

Architecture and its subset, the Common Object Request Broker Architecture (CORBA), as propagated by the Object Management Group, Inc., Framingham Corporate Center, 492 Old Connecticut Path, Framingham, Massachusetts, 01701, United States of America, (508) 820-4300.

CORBA is a standard for communication between distributed objects. It provides a way to execute programs written in any language, residing at any location on a network, supported on any platform. CORBA is suited for complex systems built across widely distributed networks, where an event occurring in one location requires services to be performed in another.

In CORBA, a client makes a request to a common interface known as an object request broker. The object request broker directs the request to the appropriate server where the object resides and redirects the results back to the requesting client. The required object might also be located on the same machine as the client.

CORBA is often described as an "object bus" because it is a communications interface through which objects are located and accessed. In this regard, an object bus is a high-level protocol that rides on top of a lower- level transport protocol.

CORBA-compliant objects are defined by an interface definition language that describes the services each object performs and the way data is passed to it. The definitions are stored in an interface repository that can be queried by a client application to determine what functions (objects) are available on the object bus. Figures 4 through 10 illustrate the configuration of the data storage device 140 respectively in each of the seller interface 106, the bidder interface 108, the financer interface 110, the insurer interface 112, the shipper interface 114, the inspector interface 116, and the escrow agent interface 118 nodes. Each such data storage device 140 has a similar configuration, including an encryption key sub-database 190, a token sub-database 192, and an audit sub- database 194.

The encryption key sub-database 190 maintains a record of the public- key associated with each entity connected to the network 100 at a remote node 102 that the local node maintaining the encryption key sub-database 164 has communicated with in the past or is likely to communicate with in future.

The token sub-database 192 maintains a record of each token exchanged between remote nodes 102 on the network 100 and the local node maintaining the token sub-database 192. Each record includes a unique record-key field, hereinafter referred to as a Token-ID. Tokens will be described in more detail below with respect to the depiction in Figure 11 of a token data structure diagram and the token database 166 will be described in more detail below with respect to the depiction in Figure 12 of a data structure diagram detailing the token database 166.

The audit sub-database 194 maintains records of all transactions to which the local node 102 maintaining the audit sub-database 194 was a party. The records include such fields as may assist a court to determine fault or liability should a disputed loss occur. The audit database would maintain time- stamped copies of appropriate records or fields maintained by the databases and forms described above and would have significant access restrictions to increase the credibility of the database.

Those skilled in the art will appreciate that there are many ways to structure databases, and that one might chose to store fields in different databases than described in this embodiment or might even chose to implement a different number of databases than described in this embodiment. Such choices would not depart from the spirit of the invention.

Each respective data storage device 140 at respective remote nodes 102 also includes a collection of business objects 196, for example agents, that model the events and business processes that underlie the transactions conducted over the network 100. The business objects 196 describe attributes, relationships, and behaviors, and may include threads of artificial intelligence. In this embodiment, the business objects 196 are created and maintained using a software application called Visual Knowledge^® sold by Big Server Software,

Inc., 200 - 1682 West 7^th Avenue, Vancouver, British Columbia, Canada, V6J 4S6, (604) 730-0086. In general, the business objects 196 are dormant until a predetermined event occurs, at which occurrence they direct the main processor 132 to perform a predetermined function.

The business objects 196 will be better understood with reference to:

Figure 13, which depicts a flowchart of a seller registration process transacted between the central controller 104, the seller interface 106 and the financer interface 110; Figure 15, which is a flowchart of an auction configuration process transacted between the central controller 104, seller interface 106, the shipper interface 114, and the inspector interface 116; Figure 19, which is a flowchart of a bidder registration process transacted between the central controller 104, the bidder interface 108, and the financer interface 110; Figure 21, which is a flowchart of an anonymous auction searching process transacted between the central controller 104 and the bidder interface 108; Figure 22, which is a flowchart of a registered auction searching process transacted between the central controller 104 and the bidder interface 108; Figure 24, which is a flowchart of an auction bidding process transacted between the central controller 104, the seller interface 106, and a plurality of bidder interfaces 108; Figure 26, which is a flowchart of a post-bidding process transacted between the central controller 104, the seller interface 106, a plurality of bidder interfaces 108, and the shipper interface 114; Figure 30, which is a flowchart of a first embodiment fulfillment - letter of credit issuance process transacted between the central controller 104, the seller interface 106, the bidder interface 108, a bidder-financer interface 110, and a seller-financer interface 110; Figure 32, which is a flowchart of a first embodiment fulfillment - logistics process transacted between the central controller 104, the seller interface 106, the bidder interface 108, a bidder-financer interface 110, a seller- financer interface 110, shipper interface 114, insurer interface 112, and inspector interface 116; Figure 34, which is a flowchart of a second embodiment fulfillment - logistics process transacted between the central controller 104, the seller interface 106, the bidder interface 108, a seller- financer interface 110, a shipper interface 114, an insurer interface 112, an inspector interface 116, and an escrow interface 118; Figure 35, which is a flowchart of a first embodiment inspection process transacted between the seller interface 106 and an inspector interface 116; and Figure 36, which is a flowchart of a second embodiment inspection process transacted between the central controller 104, the seller interface 106, and an inspector interface 116.

Figure 11 illustrates the structure of a token 200 exchanged between the nodes 102 on the network 100. The token 200 may be or include one or more communication packets or one or more software objects. In less automated embodiments, some tokens 200 might include letters, couriered packages, facsimile transmissions, telexes, electronic mail, telephone calls, voice messages, or any other form of communication having the necessary characteristics of security and timeliness. There is no expectation that all tokens 200 will be of the same kind.

A token 200 generally includes a unique identifier, hereinafter referred to as a Token-ID 202, a type designator 204, a signature code 206, a script 208, and a payload 210.

The Token-ID 202 uniquely identifies each token 200 exchanged on the network 100.

The type designator 204 classifies each token 200 to enable business objects 184, 196 to respond to the mere receipt at a node 102 of a particular type of token 200.

The signature code 206 authenticates that a token 200 has been issued, modified, or received by a particular node 102 or combination of nodes 102 on the network 100 and that the contents of the token 200 have not been tampered with. The signature code is encrypted by the encryption processor 152 of a sending node 102 and decrypted via the encryption processor 152 at an authorized receiving node 102.

The script 208, if present in a particular token 200, interacts with the digital computer 130 at the receiving node 102. In one embodiment, the script 208 is written in the Java® programming language propagated by Sun Microsystems, Inc., 901 San Antonio Road, Palo Alto, California 94303, United States of America, (800) 555-9786. In this regard, the script 208 may include

Java® codes, Java Script® codes, Javabeans® codes, Java® applet codes, and Java® byte codes. In an alternate embodiment, the script 208 is written in the Active-X® programming language propagated by Microsoft Corporation, One Microsoft Way, Redmond, Washington, 98052-6399, United States of America, (425) 882-8080. In yet another embodiment, the script 208 is written in the Hypertext Markup Language (HTML) propagated and standardized by the World Wide Web Consortium, Massachusetts Institute of Technology, Laboratory for Computer Science, 545 Technology Square, Cambridge, MA 02139, United States of America, (617) 253-2613.

The script 208 is coded to interact with the Java^® Virtual Machine implemented by the Internet browser resident at a receiving node 102, to direct the Java^® Virtual Machine to perform specified functions. For example, a script 208 might direct the Java^® Virtual Machine to cause the Internet browser to present and manipulate data entry forms and thus the underlying associated databases 150, 152, 154, 156, 158, 160, 162, 164, 166, 168, 170, 172, 174, 176, 178, 180, 182 or sub-databases 190, 192, 194 stored in the data storage devices 140 at respective nodes 102. Such forms will be discussed in greater detail below with reference to Figure 14, which depicts a seller registration form;

Figure 16, which depicts an auction configuration form; Figure 17, which depicts a pre-bid shipping quotation form; Figure 18, which depicts an inspection charge form; Figure 20, which depicts a bidder registration form; Figure 23, which depicts an auction search screen form; Figure 25, which depicts an auction bid detail form; Figure 27, which depicts a post-bid request for quotation form; Figure 28, which depicts a post-bid shipping quotation form; Figure 29, which depicts a purchase form; Figure 31 , which depicts an application for irrevocable letter of credit form; and Figure 33, which depicts an insurance cover note form.

Those skilled in the art will appreciate that the functionality ascribed above to a script 208 might instead be coded into a business object 184, 196 resident at a node 102 receiving a token 200.

The payload 210 might include codes representing data and/or behavior. In this regard, the payload 210 might include one or more software objects, or pointers or references thereto, representing information stored in the databases

150, 152, 154, 156, 158, 160, 162, 164, 166, 168, 170, 172, 174, 176, 178, 180, 182 or the sub-databases 190, 192, 194, including the forms described above. The behavior might be either a request that the computer 130 at the receiving node 102 perform a particular function, a command that the computer 130 at the receiving node 102 perform a particular function, or an action performable on at least some of the data encoded in the payload 210. Those skilled in the art will appreciate that such behavior might instead be coded into a business object 184, 196 resident at a node 102 receiving a token 200.

In one particular embodiment, an electronic mail message forms the basis of implementation for a complemental pair of tokens 200. The first token of the pair is an electronic mail message issued by the controller 104 to one of the peripheral nodes 102, which provides a human recipient at the peripheral node 102 with information, for example a request or an instruction. The electronic mail message also includes a hyperlink that permits the recipient to address the Internet browser operating at the peripheral node 102 to part of a database maintained at the controller data storage device 140. The hyperlink and the browser session desirably provide a secure channel and predetermined access rights to the database, thereby allowing the recipient to interact with the database, for example providing information, authorization, funds, or promises necessary to advance a transaction. Thus the hyperlink and browser session may be seen to implement the second token 200 of the complemental pair.

Such complemental pairs of tokens 200 facilitate an arrangement whereby the controller 104 can send an electronic mail message to a recipient at a peripheral node 102, instructing or reminding the recipient to perform certain tasks and whereby the recipient can address the Internet browsers operating at the peripheral node 102 to a browsable page view into the databases maintained at the controller data storage device 140. The page view might be configured to present an action or to-do list for the recipient, either generally or specifically directed to a particular auction transaction. By extension, a static or dynamic instance of the page could be contained in the original electronic mail message to the recipient.

Figure 12 illustrates in greater detail the structure of the token database 166, and thus the token sub-databases 192. The token database 166 includes a plurality of logs 220, each log being respectively associated with an auction being conducted over the network 100. Each log 220 is a data structure, for example a record or an object, having a unique identifier 222 and a plurality of entries 224, each entry comprising an action 226, an actor 228, a completion status 230, and a status time 232. ln this embodiment, the unique identifier 222 corresponds to an Auction- ID, which it will be recalled uniquely identifies each auction, as was described above with reference to the auction database 168.

Each entry 224 corresponds to an important step in the course of the auction, which either has been completed or is yet to be completed. Thus, in a particular entry 224, an action 226 might include bidding, closing bidding, inspecting an item, insuring an item, shipping an item, issuing a letter of credit, and so forth. The corresponding actor 228 would be the specific node 102 responsible for performing the action 226. The completion status 230 signifies whether or not an action 226 has been performed and the completion time 232 signifies when completion occurred. The completion status 230 references a Token-ID to evidence which token 200 is the basis for asserting the completion status. Thus, the log 220 forms both an audit trail and a to-do list for each auction, which log 220 may be consulted and modified by nodes 102 associated with an auction.

Operation

The operation of embodiments of the apparatus, system, and method for facilitating transactions will now be described in further detail with reference to Figures 13 through 37. The embodiments presented are highly automated ones implemented using general purpose programmable computers 130 configured to communicate over a network 100, more particularly a secure virtual private network within the Internet. Those skilled in the art will appreciate that many if not all of the actions and functions herein described could also be implemented with less automation or less advanced technology, for example as described variously above. In particular, those skilled in the art will appreciate that, as described above, an exchange of complemental pairs of tokens 200 might be alternately implemented through an exchange of electronic mail messages having hyperlinks for directing an Internet browser to an HTML page linked into a database for example. Additionally, some exchanges of tokens 200 might be implemented via telephone conversations, facsimile transmissions, or couriers.

Figures 13 through 37 variously illustrate a seller registration process, an auction configuration process, a bidder registration process, an anonymous auction searching process, a registered auction searching process, an auction bidding process, a post-bidding process, a fulfillment letter of credit issuance process, a fulfillment logistics process, an inspection logistics process, and a supervisory process. In this regard, Figures 14, 16, 17, 18, 20, 23, 24, 25, 27, 28, 29, 31 , and 33 depict data entry form views into the databases 150, 152, 154, 156, 158, 160, 162, 164, 166, 168, 170, 172, 174, 176, 178, 180, 182 and the sub-databases 190, 192, 194 described above. Furthermore, Figure 13, 15, 19, 21 , 22, 26, 30, 32, 34, 35, 36, and 37 depict flowcharts that illustrate the process interaction between the business objects 184, 196 resident at each of the nodes 102.

Figures 13 and 14 illustrate a seller registration process. Before a seller can offer an item for sale on the network 100, he must register to obtain a Seller-ID to gain access to a seller interface 106 on the network 100.

Figure 13 depicts the process flows of a seller registration business object 250 resident at the node 102 of the seller applicant, a controller registration business object 252 resident at the controller 104, and a financer registration business object 254 resident at a financer interface 110.

At block 256, the seller registration business object 250 issues a seller application token 200a to the central controller 104, which is detected and processed by the controller registration business object 252. The seller application token 200a is designated by its type designator 204; its payload 210 includes seller application data as detailed in Figure 14, which depicts a seller registration form generally illustrated at 258, which is a view into the seller database150. With reference to Figure 14, it will be seen that the seller registration form 258 includes seller contact information generally illustrated at 260, seller accounting information generally illustrated at 262, seller business information generally illustrated at 264, seller export information generally illustrated at 266, and seller banking information generally illustrated at 268.

At block 270, the controller registration business object 252 processes the seller application token 200a to validate the application for registration. As part of the validating process, the controller registration business object 252 issues an authorization request token 200b to a financer interface 110, for example the financial institution specified by the seller banking information 268 in the seller registration form 258. The authorization request token 200b is designated by its type designator 204 and includes in its payload 210 sufficient information extracted from the seller registration form 258 to identify the applicant seller.

At the financer interface 110, the authorization request token 200b is detected and processed by the financer registration business object 254. At block 272, the financer registration business object 254 analyzes the businessworthiness of the applicant seller, implementing a credit check for example. At block 274 the financer registration business object 254 generates an authorization report, which it injects into the payload portion of an authorization report token 200c issued to the central controller 104. The authorization report may be no more than a mere approval or rejection.

At the central controller 104, the controller registration business object 252 detects and processes the authorization report token 200c. At block 276, based upon the information contained or referenced in the seller application token 200a and the authorization report token 200c, the controller registration business object 252 determines whether or not to register the applicant seller. If not, then the controller registration business object 252 issues an application rejection token 200d to the applicant seller, which is detected by the seller registration business object 250 and processed at block 278. Alternatively, if so, then the controller registration business object 252 issues an application acceptance token 200e to the applicant seller, which is detected by the seller registration business object 250 and processed at block 278. The application acceptance token 200e includes in its payload portion 210 a Seller-ID and a password for future use by the now registered seller to access the network 100 through a seller interface 106.

Figures 15, 16, 17, and 18 illustrate an auction configuration process. Before a seller can offer an item for sale on the network 100, he must submit an auction configuration to the controller 104 to obtain an Auction-ID.

Figure 15 depicts the process flows of an seller auction configuration business object 290 resident at a seller interface 106, an controller auction configuration business object 292 resident at the controller 104, an shipper auction configuration business object 294 resident at a shipper interface 114, and an inspector auction configuration business object 296 resident at an inspector interface 116.

At block 298, the seller auction configuration business object 290 issues an auction request token 200f to the central controller 104, which is detected and processed by the controller auction configuration business object 292. The auction request token 200f is designated by its type designator 204; its payload 210 includes auction configuration data as detailed in Figure 16, which depicts an auction configuration form generally illustrated at 300, which is a view into the auction database168. With reference to Figure 16, it will be seen that the auction configuration form 300 includes export information generally illustrated at 302, restriction information generally illustrated at 304, goods for auction information generally illustrated at 306, shipping information generally illustrated at 308, and documentation information generally illustrated at 310. It will be further noted that a Seller-ID is necessary to submit the auction configuration form 300 and that the seller must be in good standing as will be further described below. At block 312, the controller auction configuration business object 292 processes the auction configuration token 200f to validate the configuration. As part of the validating process, the controller auction configuration business object 292 issues a pre-bid logistics request for quotation token 200g to a shipper interface 114 and a pre-bid inspection request token 200h to an inspector interface 116. These tokens 200g, 200h are designated by their type designators 204 and include in their respective payloads 210 sufficient information extracted from the auction configuration form 300 to enable a shipper to quote on delivery and duty charges and an inspector to locate the offered goods for inspection.

At block 314, the shipper auction configuration business object 294 detects and processes the pre-bid logistics request for quotation token 200g. In response, at block 316 it issues a pre-bid logistics quotation token 200i to the controller 104. The pre-bid logistics quotation token 200i is designated by its type designator 204; its payload 210 includes pre-bid logistics quotation data as detailed in Figure 17, which depicts a pre-bid shipping quotation form 318 generally illustrated at 300, which is a view into the auction database168 and the shipment database 176. With reference to Figure 17, it will be seen that the pre-bid shipping quotation form 318 includes export information generally illustrated at 320, pre-bid quotation information generally illustrated at 324, goods for auction information generally illustrated at 326, restriction information generally illustrated at 328, shipping information generally illustrated at 330, and documentation information generally illustrated at 332. It will be further noted that a Seller-ID and an Auction-ID identify this information.

In parallel, at block 334, the inspector auction configuration business object 296 detects and processes the pre-bid inspection request token 200h. In response, the inspector arranges an inspection of the goods and, upon successful completion of the inspection, at block 336 the inspector auction configuration business object 296 issues an inspection report and invoice token 200j to the controller 104. The inspection report and invoice token 200j is designated by its type designator 204; its payload 210 includes inspection report and invoice data as detailed in Figure 18, which depicts an inspection charge form generally illustrated at 338, which is a view into the auction database 168 and the inspection database 174. With reference to Figure 18, it will be seen that the inspection charge form 338 includes export information generally illustrated at 340, inspection charge information generally illustrated at 342, goods for auction information generally illustrated at 344, restriction information generally illustrated at 346, shipping information generally illustrated at 348, and documentation information generally illustrated at 350. It will be further noted that a Seller-ID and an Auction-ID identify this information.

At blocks 352 and 354, the controller auction configuration business object 292 respectively receives and processes the pre-bid logistics quotation token 200i and the inspection report and invoice token 200j, which it analyses along with the auction configuration token 200f at block 356 to determine whether or not to authorize the requested auction. If not, then the controller auction configuration business object 292 issues to the seller interface 106 an auction refused token 200k, which is detected and processed at the seller auction configuration business object 290 at block 358. Alternatively, if so, then the controller auction configuration business object 292 opens the auction at block 360 and issues to the seller interface 106 an auction confirmation token

200I, which is detected and processed at the seller auction configuration business object 290 at block 358. The auction confirmation token 200I includes in its payload portion 210 the Auction-ID.

Figures 19 and 20 illustrate a bidder registration process. Before a bidder can bid on an item for sale on the network 100, he must register to obtain a Bidder-ID to gain access to a bidder interface 108 on the network 100.

Figure 19 depicts the process flows of a bidder registration business object 370 resident at the node 102 of the bidder applicant, a controller registration business object 372 resident at the controller 104, and a financer registration business object 374 resident at a financer interface 110.

At block 376, the bidder registration business object 370 issues a bidder application token 200m to the central controller 104, which is detected and processed by the controller registration business object 372. The bidder application token 200m is designated by its type designator 204; its payload 210 includes bidder application data as detailed in Figure 20, which depicts a bidder registration form generally illustrated at 378, which is a view into the bidder database 152. With reference to Figure 20, it will be seen that the bidder registration form 378 includes bidder contact information generally illustrated at 380, bidder accounting information generally illustrated at 382, bidder business information generally illustrated at 384, bidder import information generally illustrated at 386, and bidder banking information generally illustrated at 388.

At block 390, the controller registration business object 372 processes the bidder application token 200m to validate the application for registration. As part of the validating process, the controller registration business object 372 issues an authorization request token 200n to a financer interface 110, for example the program partner financial institution specified by the bidder banking information 388 in the bidder registration form 378. The authorization request token 200n is designated by its type designator 204 and includes in its payload 210 sufficient information extracted from the bidder registration form 378 to identify the applicant bidder.

At the financer interface 110, the authorization request token 200n is detected and processed by the financer registration business object 374. At block 392, the financer registration business object 374 analyzes the businessworthiness of the applicant bidder, implementing a credit check for example. A block 394 the financer registration business object 374 generates an authorization report, which it injects into the payload portion of a authorization report token 200o issued to the central controller 104. The authorization report may be no more than a mere approval or rejection.

At the central controller 104, the controller registration business object 372 detects and processes the authorization report token 200o. At block 396, 5 based upon the information contained or referenced in the bidder application token 200m and the authorization report token 200o, the controller registration business object 372 determines whether or not to register the applicant bidder. If not, then the controller registration business object 372 issues an application rejection token 200p to the applicant bidder, which is detected by the bidder o registration business object 370 and processed at block 398. Alternatively, if so, then the controller registration business object 372 issues an application acceptance token 200q to the applicant bidder, which is detected by the bidder registration business object 370 and processed at block 398. The application acceptance token 200q includes in its payload portion 210 a Bidder-ID and a s password for future use by the now registered bidder to access the network 100 via a bidder interface 108.

Figures 21 , 22, and 23 illustrate two processes for searching the auction database 168 for auctions of specific interest, namely a search process conducted by an anonymous searcher and a search process conducted by a o registered bidder.

Figure 21 depicts the process flows in an anonymous search of a bidder anonymous search business object 390 resident at a bidder interface 108 and a controller anonymous search business object 392 resident at the controller 104.

5 At block 394, the bidder anonymous search business object 390 issues a search request token 200r to the central controller 104, which is detected and processed by the controller anonymous search business object 392. The anonymous search token 200r is designated by its type designator 204; its payload 210 includes search criteria data as detailed in Figure 23, which depicts an auction search screen form generally illustrated at 396, which is a view into the auction database 168. With reference to Figure 23, it will be seen that the auction search screen form 396 includes search criteria information generally illustrated at 398, and search results information generally illustrated at 400. The search criteria information might include for example: a keyword, a category, a country of origin, a per item or per unit price, and a remaining duration before an auction expires. The terms "per item price" and "per unit price" have subtly different meanings. The former means a price per physical item, for example toaster; the latter means a price per unit of measurement, for example kilogram of flour. However, for the purposes of describing and defining this invention, the terms may be used interchangeably.

At block 402, the controller anonymous search business object 392 processes the search request token 200r to locate auctions in the auction database 168 that are consistent with the search criteria information 398. In response, at block 404 the controller anonymous search business object 392 issues a search results token 200s to the bidder interface 108, which is detected by the bidder anonymous search business object 390 and processed at block 406 for viewing the search results. The search results token 200s is designated by its type designator 204 and includes in its payload 210 a list of auctions and auction details from the auction database 168 that were consistent with the search criteria information 398.

At block 408, the bidder anonymous search business object 390 gives the searcher the opportunity to search the auction database 168 again, either with the same search criteria information 398 to refresh the search results information 400 or with different search criteria information 398 to refine the search results information 400. The searcher indicates his choice by activating a refresh search button 408 or a refine search button 410 on the auction search screen form 23. Figure 22 depicts the process flows in a registered auction search of a bidder registered search business object 420 resident at a bidder interface 108 and a controller registered search business object 422 resident at the controller 104.

At block 424, the bidder registered search business object 420 issues a logon token 200t to the central controller 104, which is detected and processed by the registered-search controller-business object 422. The logon token 200t is designated by its type designator 204; its payload 210 includes a Bidder-ID and password previously assigned to the registered user of the bidder interface 108.

The controller registered search business object 422 processes the logon token 200t at block 426 and responds at block 428 by issuing to the bidder interface 108 a search results token 200s, which is detected by the bidder registered search business object 420 and processed at block 430 for viewing the search results. The search results token 200s is designated by its type designator 204 and includes in its payload 210 a list of auctions and auction details from the auction database 168 that were consistent with the search criteria information 398 most recently previously submitted under the Bidder-ID.

At block 432, the bidder registered search business object 420 gives the searcher the opportunity to search the auction database 168 again, either with the same search criteria information 398 to refresh the search results information 400 or with different search criteria information 398 to refine the search results information 400. The searcher indicates his choice by activating a refresh search button 408 or a refine search button 410 on the auction search screen form 23.

Should the searcher activate either the refresh search button 408 or the refine search button 410, at block 434 the bidder registered search business object 420 issues a search request token 200r to the central controller 104, which is detected and processed by the controller registered search business object 422. The search request token 200r is designated by its type designator 204; its payload 210 includes search criteria data as detailed in Figure 23, which depicts the auction search screen form generally illustrated at 396, which is a view into the auction database 168.

At block 436, the controller registered search business object 422 processes the search request token 200r to locate auctions in the auction database 168 that are consistent with the search criteria information 398. In response, at block 438 the controller registered search business object 422 issues a search results token 200s to the bidder interface 108, which is detected by the bidder registered search business object 420 and processed at block 440 for viewing the search results. The search results token 200s is designated by its type designator 204 and includes in its payload 210 a list of auctions and auction details from the auction database 168 that were consistent with the search criteria information 398.

Further examination of the auction search screen form 396 in Figure 23 shows that each auction listed in the search results information 400 includes a bid button 442 and a remove 444. The bid button 442 enables a registered bidder to bid on the corresponding auction. The remove button 444 removes the corresponding auction from the search results information 400.

Figures 24 and 25 illustrate an auction bidding process in greater detail. To this end, Figure 24 depicts the process flows of a plurality of bidder bidding business objects 450 resident at a plurality of bidder interfaces 108, a controller bidding business object 452 resident at the controller 104, and a seller bidding business object 454 resident at a seller interface 106.

At block 456, a bidder bidding business object 450 issues a bidding token 200u to the central controller 104, which is detected and processed by the controller bidding business object 452. The bidding application token 200u is designated by its type designator 204; its payload 210 includes bidding data as detailed in Figure 25, which depicts an auction bid detail form generally illustrated at 458, which is a view into the auction, seller and shipment databases 168, 160, 176. With reference to Figure 25, it will be seen that the auction bid detail form 458 includes seller information generally illustrated at 460, auction information generally illustrated at 462, goods for auction information generally illustrated at 464, bid information generally illustrated at 466, shipping charges information generally illustrated at 468, auction restriction information generally illustrated at 470, and documentation information generally illustrated at 472. Desirably, the auction bid detail form 458 includes information regarding both a total delivered cost of the complete lot 469 and a per unit or per item delivered cost 471.

At block 474, the controller bidding business object 452 processes the bidding token 200u to determine whether it is superior to the current bid, in which case it becomes the current bid. In one embodiment, the controller bidding business object 452 propagates the bidding token 200u to at least one of the bidder bidding business objects 450 associated with a prior bid in order to announce the current bid and to encourage further bidding. This propagated bidding token 200u might be modified to remove confidential information, for example the identity of the bidder of the current bid. Conveniently, the propagated bidding token 200u might be implemented as an electronic mail message.

At block 476, the controller bidding business object 452 determines whether the auction has expired. If not, then it continues to accept bidding tokens 200u from bidder interfaces 108. Alternatively, if the auction has expired, then at block 478 the controller bidding business object 452 identifies the successful registered bidder as a buyer. Thereafter, at block 480 the controller bidding business object 452 notifies the buyer and the seller that they are parties to a completed auction by issuing a completion token 200v to both of the seller interface 106 associated with the Auction-ID and the bidder interface 108 associated with the Bidder-ID of the successful bidder. The completion token 200v is designated by its type designator 204 and includes in its payload 210 information describing the auction and the successful bid. At the respective seller and bidder interfaces 106, 108, the completion token 200v is detected and processed by the respective seller bidding business object 454 and bidder bidding business object 450 at blocks 482 and 484 respectively.

For completeness, at block 480 the controller bidding business object 452 may also notify each unsuccessful bidder that the auction has completed and that the unsuccessful bidder was outbid. Such notification would be implemented by issuing an outbid token 200v^* to each bidder interface 108 associated the Bidder-ID of an unsuccessful bid. The outbid token 200v* is designated by its type designator 204 and includes in its payload 210 information describing the auction. At the respective bidder interfaces 108, the completion token 200v* is detected and processed by the respective bidder bidding business object 450 at block 486.

It will be observed that bids for items may be expressed on a per unit or per item basis. Therefore, the controller 104 might accept bids for either the total quantity of items comprising a complete lot or less than the total quantity of items comprising a complete lot. Thus, an auction might be successfully completed when multiple bidders bid sufficient per item prices for sufficient quantities of items to exceed minimum price and quantity limitations established by the seller. In a multiple-successful-bidder embodiment, the controller 104 would be programmed to analyze both the price and quantity of each bid to determine which combination of bids provided the seller with the maximum return. Upon expiration of the auction, each of the successful bidders would be notified. If at the closing of the auction, less than the full quantity of items were sold, then a new auction might be initiated either manually or automatically.

Figures 26, 27, 28, and 29 illustrate an auction post-bidding process. To this end, Figure 26 depicts the process flows of a plurality of bidder post-bidding business objects 500 resident at a plurality of bidder interfaces 108, a controller post-bidding business object 502 resident at the controller 104, a seller post- bidding business object 504 resident at a seller interface 106, and a shipper post-bidding business object 506 resident at a shipper interface 114.

At block 508, in response to receipt at the seller interface 106 of an auction completion token 200v, the seller post-bidding business object 204 issues to the central controller 104 either a sale acceptance token 200w or a sale rejection token 200x depending upon input from the seller, the sale acceptance token 200w and the sale rejection token 200x being designated by their respective type designators 204 and their payloads 210 including data identifying the seller and the auction at issue.

Either the sale acceptance token 200w or the sale rejection token 200x is detected and processed by the controller post-bidding business object 502 at block 510. At block 512, the controller post-bidding business object determines whether the seller has accepted or rejected the successful bid. If the successful bid is rejected, then the controller post-bidding business object 502 issues to the seller interface 106 a delisting token 200y, which is detected and processed by the seller post-bidding business object 504 at block 514. The delisting token 200y is designated by its type designator 204 and includes in its payload 210 data indicating that the seller's Seller-ID has been cancelled. Alternatively, the controller post-bidding business object 502 may maintain a seller infraction counter associated with each Seller-ID, such that a predetermined number of infractions may be committed before a Seller-ID is cancelled. In this alternative, the seller infraction counter would be incremented should a successful bid be improperly rejected. Alternatively, if the successful bid has been accepted, then at block 516 the controller post-bidding business object 502 issues to the bidder interface 108 associated with the successful bidder a prepare request for shipping quotation token 200z, which is detected and processed by the bidder post- bidding business object 500 at block 518. The prepare request for shipping quotation token 200z is designated by its type designator 204 and includes in its payload 210 post-bid request for quotation data as detailed in Figure 27, which depicts a post-bid request for quotation form generally illustrated at 458, which is a view into the auction, bidder and shipment databases 168, 162, 176. With reference to Figure 27, it will be seen that the post-bid request for quotation form 520 includes buyer delivery information generally illustrated at 522, and import information generally illustrated at 524.

Thereafter, at block 526 the bidder post-bidding business object 500 generates a request for shipping quotation token 200aa for issuance to the shipper interface 114 either directly at block 528 or indirectly via the central controller 104 through block 530. The request for shipping quotation token 200aa is designated by its type designator 204 and includes in its payload 210 post-bid request for quotation data as detailed in Figure 27. In general, the payload 210 data in the request for shipping quotation token 200aa is a fusion of data input by the buyer at block 526 into the post-bid request for quotation form 520 and the payload 210 data of the prepare request for shipping quotation token 200z received from the controller 104.

The request for shipping quotation token 200aa is ultimately received at the shipper interface 114 and detected and processed by the shipper post- bidding business object 506 at block 528, whereafter at block 532 the shipper post-bidding business object 506 issues a shipping quotation token 200ab to the controller 104, which is detected and processed by the controller post- bidding business object 502 at block 534. The shipping quotation token 200ab is designated by its type designator 204; its payload 210 includes post-bid shipping quotation data as detailed in Figure 28, which depicts a post-bid shipping quotation form generally illustrated at 536, which is a view into the auction, seller, bidder, and shipment databases 168, 160, 162, 176. With reference to Figure 28, it will be seen that the post-bid shipping quotation form 536 includes shipping information generally illustrated at 538, import information generally illustrated at 540, goods for auction information generally illustrated at 542, auction restriction information generally illustrated at 544, and documentation information generally illustrated at 472.

At block 534, the control post-bidding business object 502 produces a quotation consolidation token 200ac for issuance to the bidder interface 108 associated with the successful bidder, where it is detected and processed by the bidder post-bidding business object 500 at block 548. To produce the quotation consolidation token 200ac, the control post-bidding business object 502 processes the shipping quotation token 200ab and fulfillment preferences expressed by the bidder post-bidding business object 500, for example in the request for shipping quotation token 200aa. In this regard, fulfillment preferences generally relate to inspection and insurance. The quotation consolidation token 200ac is designated by its type designator 204; its payload 210 includes quotation consolidation data as detailed in Figure 29, which depicts a quotation consolidation form generally illustrated at 548, which is a view into the auction, and shipment databases 168, 176. With reference to

Figure 29, it will be seen that the quotation consolidation form 548 includes payment information generally illustrated at 550. Desirably, the quotation consolidation form 548 includes information regarding both a total delivered cost of the complete lot 549 and a per unit or per item delivered cost 551.

At block 552, the bidder post-bidding business object 500 determines whether the buyer is satisfied with the quotation consolidation. If not, then the bidder post-bidding business object 500 returns to block 526 to issue a revised request for shipping quotation token 200aa. Alternatively, if so, then at block 554 the bidder post-bidding business object 500 determines whether the buyer is satisfied with his purchase. If not, then the bidder post-bidding business object 500 issues a purchase rejection token 200ad to the central controller 104. Alternatively, if so, then the bidder post-bidding business object 500 issues a purchase acceptance token 200ae to the central controller 104. The purchase rejection token 200ad and the purchase acceptance token 200ae are respectively designated by their respective type designators 204 and their respective payloads 210 include data identifying the buyer, the successful bid, and the auction at issue.

Either the purchase rejection token 200ad or the purchase acceptance token 200ae is detected and processed by the controller post-bidding business object 502 at block 556. At block 558, the controller post-bidding business object 502 determines whether the buyer has accepted or rejected the purchase. If the purchase has been accepted, then block 560 directs the controller post-bidding business object to begin the purchase fulfillment process.

Alternatively, if the purchase has been rejected, then the controller post- bidding business object 502 notifies the next highest bidding bidder and the seller that they are parties to a completed auction by issuing a completion token 200v to both of the seller interface 106 associated with the Auction-ID and the bidder interface 108 associated with the Bidder-ID of the next highest bidder. At the respective seller and bidder interfaces 106, 108, the completion token

200v is detected and processed by the respective seller post-bidding business object 504 and bidder post-bidding business object 500 at blocks 562 and 564.

If the purchase has been rejected, the controller post-bidding business object 502 may also cancel the Bidder-ID associated with the improperly rejected purchase. In this arrangement, the controller post-bidding business object 502 issues to that bidder interface 108 a delisting token 200y, which is detected and processed by the bidder post-bidding business object 500 at block 564. The delisting token 200y is designated by its type designator 204 and includes in its payload 210 data indicating that the buyer's Bidder-ID has been cancelled. Alternatively, the controller post-bidding business object 502 may maintain a bidder infraction counter associated with each Bidder-ID, such that a predetermined number of infractions may be committed before a Bidder- ID is cancelled. In this alternative, the bidder infraction counter would be incremented should a purchase be improperly rejected.

Figures 30 and 31 illustrate a first embodiment of a payment fulfillment process, namely a letter of credit issuance process. To this end, Figure 30 depicts the process flows of a plurality of bidder payment business object 580 resident at a bidder interface 108, a bidder's-financer payment business object 582 resident at a financer interface 110, a controller payment business object

584 resident at the controller 104, a seller's-financer payment business object 586 resident at a second financer interface 110, and a seller payment business object 588 resident at a seller interface 106.

At block 590, in response to the controller post-bidding business object 502 invoking the purchase fulfillment process at block 560, the controller payment business object 584 issues a letter of credit application token 200af to the bidder interface 108 associated with the successful bidder, which is detected and processed by the bidder payment business object 580 at block 596. The letter of credit application token 200af is designated by its type designator 204 and includes in its payload 210 a letter of credit application, including data identifying the successful bidder, the successful bid, the completed auction, and the seller of the auctioned lot. The letter of credit application token 200af may thus be understood as a letter of credit application that the controller payment business object 584 has initiated.

At block 602, the bidder payment business object 580 completes the letter of credit application included in the payload 210 of the letter of credit application token 200af received from the controller payment business object 584. The bidder payment business object 580 then issues an executed letter of credit application token 200ai to the financer interface 110 associated with the successful bidder, which token is detected and processed by the bidder's- financer payment business object 582 at block 604. The executed letter of credit application token 200ai is designated by its type designator 204 and includes in its payload 210 an executed letter of credit application as detailed in Figure 31 , which depicts an application for irrevocable letter of credit form generally illustrated at 606, which is a view into the letter of credit database 178. With reference to Figure 31, it will be seen that the application for irrevocable letter of credit form 606 includes both letter of credit details generally illustrated at 608 and letter of credit terms generally illustrated at 610 such that, when executed, the application for irrevocable letter of credit form

606 would become a fully binding legal document in its own right.

At block 614, the bidder payment business object 580 issues a full payment token 200aj to the financer interface 110 associated with the successful bidder, which is detected and processed by the bidder-financer payment business object 582 at block 616. The full payment token 200aj is designated by its type designator 204 and includes in its payload 210 data identifying the successful bidder, the successful bid, and the completed auction, as well as full payment in satisfaction of the successful bid, for example via an electronic funds transfer. Those skilled in the art will appreciate that the executed letter of credit application token 200ai and the full payment token

200aj might be combined into one token.

At block 618, in response to receiving the executed letter of credit application token 200ai and the full payment token 200aj, the bidder's-financer payment business object 582 issues a letter of credit token 200ak to the controller 104, which is detected at block 620 by the controller payment business object 584. The letter of credit token 200ak is designated by its type designator 204 and includes in its payload 210 a fully binding letter of credit identified as pertaining to the subject buyer, seller, and auction. The letter of credit token 200ak is passed from the controller payment business object 584 at block 620 to the seller's-finance payment business object 586 at block 622, and on to the seller payment business object 588 at block 624. At block 626, upon receiving the letter of credit token 200ak, the seller payment business object 588 issues a letter of credit receipt token 200al to the controller 104, which is detected and processed at block 628.

Figures 32 and 33 illustrate a first embodiment of a logistics fulfillment process. To this end, Figure 32 depicts the process flows of a bidder logistics business object 650 resident at a bidder interface 108, a bidder's-financer logistics business object 652 resident at a financer interface 110, a controller logistics business object 654 resident at the controller 104, a shipper logistics business object 656 resident at a shipper interface 114, an inspector logistics business object 658 resident at an inspector interface 116, an insurer logistics business object 660 resident at an insurer interface 112, a seller's-financer logistics business object 662 resident at a second financer interface 110, and a seller logistics business object 664 resident at a seller interface 106.

At block 674, in response to the controller post-bidding business object 502 invoking the purchase fulfillment process at block 560, the controller logistics business object 654 issues an inspection request token 200ao to the inspector interface 116 associated with the inspection service designated in the selected logistics token 200an. A copy of the inspection request token 200ao is also issued to the shipper interface 106 for detection and processing by the shipper logistics business object 664 at block 676 to ensure that the items will be available for inspection. The inspection request token 200ao is designated by its type designator 204 and includes in its payload 210 data identifying the completed auction and the location and description of the items to be inspected.

The inspection request token 200ao is detected and processed by the inspector logistics business object 658 at block 678 to enable the inspector to arrange to inspect the items. Thereafter, at block 680, the inspector logistics business object issues an inspection report token 200ap to the controller 104 and the seller interface 106, where it is respectively detected and processed by the controller logistics business object 654 and the seller logistics business object 664 at blocks 682 and 684. The inspection report token 200ap is designated by its type designator 204 and includes in its payload 210 data identifying the completed auction and the results of the item inspection.

In parallel to the process of arranging for inspection, the controller logistics business object 654 at block 686 issues an insurance request token 200aq to the insurer interface 112 associated with the insurer designated in the selected logistics token 200an. The insurance request token 200aq is designated by its type designator 204 and includes in its payload 210 insurance policy data as detailed in Figure 33, which depicts an insurance cover note form generally illustrated at 606, which is a view into the insurance database 180. With reference to Figure 33, it will be seen that the insurance cover note form

688 includes both insurance details generally illustrated at 690 and policy terms generally illustrated at 692 such that, when executed, the insurance cover note 688 would become a fully binding legal document in its own right.

At block 694, the insurer logistics business object 660 detects and processes the insurance request token 200aq, arranging for the specified insurance.

At block 698 the controller logistics business object 654 issues an insurance cover note token 200ar to the bidder interface 108 associated with the successful bidder, where it is detected and processed by the bidder logistics business object 650 at block 700. The insurance cover note token 200ar is designated by its type designator 204 and includes in its payload 210 data a binding insurance policy covering the transfer of possession and ownership of the auctioned items from the seller to the buyer. It will thus be appreciated that in this embodiment, the controller 104 is empowered to bind the insurer into an insurance contract.

The controller logistics business object 654 at block 702 issues a shipping order token 200as to the shipping interface 114 associated with the shipper designated in the selected logistics token 200an. The shipping order token 200as is designated by its type designator 204 and includes in its payload 210 shipping details such as pickup and delivery locations, mode of transport, and import/export matters.

The shipping order token 200as is detected and processed at block 704 by the shipping logistics business object 656, which in response at block 706 issues a bill of lading token 200at to the seller interface associated with the auctioned goods. The bill of lading token 200at is designated by its type designator 204 and includes in its payload 210 shipping details such as pickup and delivery locations, mode of transport, and import/export matters. The seller logistics business object 664 detects and processes the bill of lading token

200at at block 708. In turn, the bill of lading token 200at is successively passed to the seller's-financer logistics business object 662 at blocks 710, 712, on to the bidder's-financer logistics business object 652 at blocks 714, 716, and finally on to the bidder logistics business object 650 at blocks 718, 720. Upon receipt of the bill of lading token 200at by the bidder logistics business object

650, the buyer receives the legal authority to claim ownership and possession in the auctioned items.

In parallel, as the shipper moves the items, it issues tracking tokens to the controller 104 so that the items can be tracked in transit. In this regard, the shipper logistics business object 656 issues an items received token 200au at block 722, an items in transit token 200uv at block 724, a duty paid token 200aw at block 726, and an items delivered token 200ax at block 728. These tracking tokens are respectively detected and processed by the controller logistics business object 654 at blocks 730, 732, 734, and 736. When title in the auctioned items has been transferred to the buyer, as evidenced by receipt of the bill of lading token 200at by the bidder logistics business object 650, at block 738 the bidder's-financer logistics business object 652 issues a payment token 200ay to the financer interface 110 associated with the seller's-financer logistics business object 662. The payment token

200ay is designated by its type designator 204 and includes in its payload 210 codes for enacting a transfer of funds between the bidder's-financer logistics business object 652 and the seller's-financer logistics business object 662. To this end, payment token 200ay is detected and processed by the seller's- financer logistics business object 662 at block 740.

In turn, at block 742 the seller's-financer logistics business object 662 issues a settlement token 200az to the seller interface 106 associated with the seller of the auctioned items, which is detected and processed by the seller logistics business object 664 at block 744. The settlement token 200az is designated by its type designator 204 and includes in its payload 210 codes for enacting a transfer of funds between the seller's-financer logistics business object 662 and the seller logistics business object 664.

In parallel, at block 746 the bidder's-financer logistics business object 652 issues a toll token 200ba to the controller 104. The toll token 200ba is designated by its type designator 204 and includes in its payload 210 codes for enacting a transfer of funds between the bidder's-financer logistics business object 652 and the controller logistics business object 654 in satisfaction of the administrative services provided by the controller 104 during the auction. To this end, toll token 200ba is detected and processed by the controller logistics business object 654 at block 748.

Thereafter, at block 750 the controller logistics business object 654 issues subcontractor tokens 200bb to each of the shipper logistics business object 656, the inspector logistics business object 658, and the insurer logistics business object 660, which respectively detect and process the subcontractor tokens 200bb at blocks 752, 754, and 756. The subcontractor tokens 200bb are designated by their type designator 204 and include in their payloads 210 codes for enacting a transfer of funds between the controller logistics business object 654 and each of the shipper logistics business object 656, the inspector logistics business object 658, and the insurer logistics business object 660 in satisfaction of the services provided by each during the auction.

Finally, at block 758 the controller logistics business object 654 issues report tokens 200bc to each of the shipper logistics business object 656, the inspector logistics business object 658, and the insurer logistics business object 660, which respectively detect and process the report tokens 200bc at blocks

760, 762, and 764. The report tokens 200bb are designated by their type designator 204 and include in their payloads 210 codes representing predetermined aspects of the transactions that each has participated in.

Figure 34 illustrates a second embodiment of a logistics fulfillment process. To this end, Figure 34 depicts the process flows of a bidder logistics business object 800 resident at a bidder interface 108, an escrow logistics business object 802 resident at an escrow interface 118, a controller logistics business object 804 resident at the controller 104, a shipper logistics business object 806 resident at a shipper interface 114, an inspector logistics business object 808 resident at an inspector interface 116, an insurer logistics business object 810 resident at an insurer interface 112, a seller's-financer logistics business object 812 resident at a financer interface 110, and a seller logistics business object 814 resident at a seller interface 106.

At blocks 816 and 818, in response to the controller post-bidding business object 502 invoking the purchase fulfillment process at block 560, the bidder and seller logistics business objects 800, 814 each issue an escrow acceptance token 200bd to the controller interface 104, which is detected and processed by the controller logistics business object 804 at block 820. Each escrow acceptance token 200bd is designated by its type designator 204 and includes in its payload 210 data identifying the completed auction. Each escrow acceptance token 200bd signifies that the issuing business object accepts an escrow fulfillment transaction as opposed to a letter of credit transaction.

At block 822, the controller logistics business object 804 issues an escrow initiation token 200be respectively to the seller and bidder interfaces 106, 108 associated with the auction and to an escrow interface 118 selected for participation in the auction. The escrow initiation token 200be is detected and processed by the respective seller, bidder, and escrow logistics business objects 814, 800, 802 at blocks 824, 826, 828. The escrow initiation token

200be is designated by its type designator 204 and includes in its payload 210 data identifying the completed auction, the selected escrow agent, and the shipping, inspection, and insurance services selected for fulfillment of the auction.

At block 830, the bidder logistics business object 800 issues an escrow pay-in token 200bf to the escrow interface 118 associated with the escrow agent designated in the escrow initiation token 200be. The escrow pay-in token 200bf is detected and processed by the escrow logistics business object 802 at block 832. The escrow pay-in token 200bf is designated by its type designator 204 and includes in its payload 210 an electronic transfer of funds to the escrow agent in satisfaction of the full purchase price, including all charges and taxes, associated with the instant auction. A copy of the escrow pay-in token 200bf is also issued to controller interface 104 for detection and processing by the controller logistics business object 804 at block 834 to confirm payment into escrow. In less automated implementations, a buyer would pay monies into escrow according to more conventional arrangements and when the escrow agent received such monies, the escrow logistics business object 802 would issue the escrow pay-in token 200bf to the controller logistics business object 804 and the bidder logistics business object 800. ln response to receipt of the escrow pay-in token 200bf, at block 836 the controller logistics business object 804 issues an inspection request token

200ao to the inspector interface 116 associated with the inspection service designated in the escrow initiation token 200be. The inspection request token 200ao is detected by the inspector logistics business object 808 at block 838.

A copy of the inspection request token 200ao is also issued to the shipper interface 106 for detection and processing by the shipper logistics business object 814 at block 840 to ensure that the items will be available for inspection.

The inspection request token 200ao is designated by its type designator 204 and includes in its payload 210 data identifying the completed auction and the location and description of the items to be inspected.

The inspection request token 200ao is detected and processed by the inspector logistics business object 808 at block 838 to enable the inspector to arrange to inspect the items. Thereafter, at block 842, the inspector logistics business object issues an inspection report token 200ap to the controller interface 104 and the seller interface 106, where it is respectively detected and processed by the controller logistics business object 804 and the seller logistics business object 814 at blocks 844 and 846. The inspection report token 200ap is designated by its type designator 204 and includes in its payload 210 data identifying the completed auction and the results of the item inspection.

In parallel and also in response to receipt of the escrow pay-in token 200bf, the controller logistics business object 804 at block 848 issues an insurance request token 200aq to the insurer interface 112 associated with the insurer designated in the escrow initiation token 200be. The insurance request token 200aq is designated by its type designator 204 and includes in its payload 210 insurance policy data as detailed in Figure 33, which depicts an insurance cover note form generally illustrated at 688, which is a view into the insurance database 180. With reference to Figure 33, it will be seen that the insurance cover note form 688 includes both insurance details generally illustrated at 690 and policy terms generally illustrated at 692 such that, when executed, the insurance cover note 688 would become a fully binding legal document in its own right.

At block 850, the insurer logistics business object 810 detects and processes the insurance request token 200aq, arranging for the specified insurance.

At block 854 the controller logistics business object 804 issues an insurance cover note token 200ar to the bidder interface 108 associated with the successful bidder, where it is detected and processed by the bidder logistics business object 800 at block 856. The insurance cover note token 200ar is designated by its type designator 204 and includes in its payload 210 data a binding insurance policy covering the transfer of possession and ownership of the auctioned items from the seller to the buyer. It will thus be appreciated that in this embodiment, the controller 104 is empowered to bind the insurer into an insurance contract.

In parallel and also in response to receipt of the escrow pay-in token 200bf, the controller logistics business object 804 at block 858 issues a shipping order token 200as to the shipping interface 114 associated with the shipper designated in the escrow initiation token 200be. The shipping order token 200as is designated by its type designator 204 and includes in its payload 210 shipping details such as pickup and delivery locations, mode of transport, and import/export matters.

The shipping order token 200as is detected and processed at block 860 by the shipping logistics business object 806, which in response at block 862 issues a bill of lading token 200at to the seller interface 106 associated with the auctioned goods. The bill of lading token 200at is designated by its type designator 204 and includes in its payload 210 shipping details such as pickup and delivery locations, mode of transport, and import/export matters. The seller logistics business object 814 detects and processes the bill of lading token 200at at block 864. In turn, at block 866 the seller logistics business object 814 forwards the bill of lading token 200at to the appropriate bidder interface 108 for detection and processing by the bidder logistics business object 800 at block 868.

In parallel, as the shipper moves the items, it issues tracking tokens to the controller 104 so that the items can be tracked in transit. In this regard, the shipper logistics business object 806 issues an items received token 200au at block 870, an items in transit token 200uv at block 872, a duty paid token 200aw at block 874, and an items delivered token 200ax at block 876 when the items have been delivered to the buyer. These tracking tokens are respectively detected and processed by the controller logistics business object 654 at blocks 878, 880, 882, and 884.

When the buyer has received the goods, the bidder logistics business object 800 at block 886 issues a decision token 200bg to the escrow agent interface 118 associated with the escrow agent designated in the escrow initiation token 200be. The decision token 200bg is detected and processed by the escrow logistics business object 802 at block 888. The decision token 200bg is designated by its type designator 204 and includes in its payload 210 an indication of whether the buyer has accepted or rejected the items delivered.

If the decision token 200bg indicates that the buyer has rejected the items, then as indicated by block 890, the escrow fails and the outcome is determined by the controller 104. Potential outcomes include returning the items to the seller, offering the items to the next highest bidding bidder, fining the rejecting buyer, incrementing the infraction counter for the rejecting buyer, and delisting the rejecting buyer.

Alternatively, if at block 888 the decision token 200bg indicates that the buyer has accepted the items, then at block 892 the escrow logistics business object 802 issues a payment token 200ay to the financer interface 110 associated with the seller's-financer logistics business object 812. The payment token 200ay is designated by its type designator 204 and includes in its payload 210 codes for enacting a transfer of funds between the escrow logistics business object 802 and the seller's-financer logistics business object

812. To this end, payment token 200ay is detected and processed by the seller's-financer logistics business object 812 at block 894.

In turn, at block 896 the seller's-financer logistics business object 812 issues a settlement token 200az to the seller interface 106 associated with the seller of the auctioned items, which is detected and processed by the seller logistics business object 814 at block 898. The settlement token 200az is designated by its type designator 204 and includes in its payload 210 codes for enacting a transfer of funds between the seller's-financer logistics business object 812 and the seller logistics business object 814.

In parallel, at block 900 the escrow logistics business object 802 issues a toll token 200ba to the controller 104. The toll token 200ba is designated by its type designator 204 and includes in its payload 210 codes for enacting a transfer of funds between the escrow logistics business object 802 and the controller logistics business object 804 in satisfaction of the administrative services provided by the controller 104 during the auction. To this end, the toll token 200ba is detected and processed by the controller logistics business object 804 at block 902.

Thereafter, at block 904 the controller logistics business object 804 issues subcontractor tokens 200bb to each of the shipper logistics business object 806, the inspector logistics business object 808, and the insurer logistics business object 810, which respectively detect and process the subcontractor tokens 200bb at blocks 906, 908, and 910. The subcontractor tokens 200bb are designated by their type designator 204 and include in their payloads 210 codes for enacting a transfer of funds between the controller logistics business object 804 and each of the shipper logistics business object 806, the inspector logistics business object 808, and the insurer logistics business object 810 in satisfaction of the services provided by each during the auction.

Finally, at block 912 the controller logistics business object 804 issues report tokens 200bc to each of the shipper logistics business object 806, the inspector logistics business object 808, and the insurer logistics business object 810, which respectively detect and process the report tokens 200bc at blocks 914, 916, and 918. The report tokens 200bc are designated by their type designator 204 and include in their payloads 210 codes representing predetermined aspects of the transactions that each has participated in.

Figure 35 illustrates a first embodiment of an inspection process. To this end, Figure 35 depicts the process flows of an inspector inspection business object 930 resident at an inspector interface 116 and a controller inspection business object 932 resident at the controller 104. The inspector inspection business object 930 is invoked in response to the inspector auction configuration business object 296 detecting and processing a pre-bid inspection request token 200h at block 334 in Figure 15. This first embodiment inspection process contemplates an inspection of a seller's plant to determine if its processes are sufficient to reliably produce items of suitable quality. In this regard, the inspection is akin to an ISO900X inspection directed to process rather than product.

Thus, at block 934, the inspector inspection business object 930 parses the payload 210 of the pre-bid inspection request token 200h to determine the particulars of the requested inspection and as a result an inspector attends at the seller's premises to conduct a plant inspection.

After the inspection has been completed, an inspection report is generated and at block 936 the inspector inspection business object 930 issues a plant inspection report token 200bh to the controller 104. The plant inspection report token 200bh is designated by its type designator 204 and its payload 210 includes data evaluating the plant of a particular seller identified by a Seller-ID.

At block 938, the controller inspection business object 932 detects and processes plant inspection report token, extracting salient data from the payload 210. At block 940 the controller inspection business object 932 cross- references the extracted data both to the seller identified by the specified Seller-ID and auctions submitted by the identified seller.

Figure 36 illustrates a second embodiment of an inspection process. To this end, Figure 36 depicts the process flows of a controller inspection business object 950 resident at the controller 104, a seller inspection business object 952 resident at a seller interface 106, and an inspector inspection business object

954 resident at an inspector interface 116.

At block 956, the seller inspection business object 952 acquires from a seller associated with the seller interface 106 both an HS class and specifications for the item that the seller wants to auction. At block 958, the seller inspection business object 952 issues an inspection RFQ token 200bi to the inspector interface 116, which is detected and processed by the inspector inspection business object 954 at block 960. The inspection RFQ token 200bi is designated by its type designator 204 as a request for quotation on an inspection and includes in its payload 210 data identifying and describing the seller and the items to be auctions, including the HS class and the item specifications.

At block 962, the inspector inspection business object 954 responds by issuing an inspection quotation and methodology token 200bj to the seller interface 106, which is detected and processed by the seller inspection business object 952 at block 964. The inspection quotation and methodology token 200bj is designated by its type designator 204 and includes in its payload

210 data identifying the cost, scope, and methodology of the proposed inspection.

At block 966, the seller inspection business object 952 queries the seller to determine whether the cost, scope, and methodology of the proposed inspection are acceptable. If not, then the seller may return to block 958 to issue a modified request for quotation. Alternatively, if the cost, scope, and methodology of the proposed inspection are acceptable to the seller, then at block 968 the seller inspection business object 952 issues an inspection acceptance token 200bk to the inspector interface 116, which is detected and processed by the inspector inspection business object 954 at block 970. The inspection acceptance token 200bk is designated by its type designator 204 and includes in its payload 210 data confirming the cost, scope, and methodology of the proposed inspection.

Thus, at blocks 972 and 974, the inspector inspection business object 954 parses the payload 210 of the inspection acceptance token 200bk to determine the particulars of the inspection and to respectively arrange for an inspector to attend at the seller's premises to conduct an on-site inspection and arrange for an inspector to remove from the seller's premises appropriate samples for analysis away from the seller's premises. After the inspection has been completed, an inspection report is generated and at block 976 the inspector inspection business object 954 issues an inspection report token 200bl to the seller interface 106. The inspection report token 200bl is designated by its type designator 204 and its payload 210 includes data evaluating the items associated with a particular auction as identified by an Auction-ID.

At block 978, the seller inspection business object 952 detects and processes the inspection report token 200bl and presents it to the seller. At block 980, the seller inspection business object 952 queries the seller to determine whether the seller wishes the inspection report to be published on the network 100, for example as data related or associated with the auction identified by the Auction-ID. If so, then the seller inspection business object 952 issues an inspection publication token 200bm to the controller 104, which is detected and processed by the controller inspection business object 950 at block 982. The inspection publication token 200bm is designated by its type designator 204 and its payload 210 includes data evaluating the items associated with the particular auction identified by an Auction-ID.

Thereafter at block 984, the controller inspection business object 950 links or otherwise incorporates the data in the payload 210 of the inspection publication token 200bm into the auction identified by the Auction-ID.

Figure 37 illustrates a first supervisory process transacted between the controller 104 and any one of the other interfaces at the peripheral nodes 102. Generally, the supervisory process ensures that each of the processes described above progresses and progresses at a reasonable pace. The controller 104 is responsible for ensuring that the steps of a transaction occur in a predetermined order and at a predetermined rate. In this regard, the controller 104 issues tokens 200 according to a particular schedule and requires that it receive tokens 200 back from peripheral interfaces 200 according to the particular schedule. In this way, the controller 104 is able to regulate and control all transactions on the network 100.

The supervisory process is transacted between a controller supervisory business object 990 and a supervised peripheral business object 992, which may in actuality any one of the business objects 196 resident at a peripheral node 102 that interact with the controller 104 through any of the processes described above.

The supervisory process is initiated at block 994 when a business object 184 resident at the controller 104 issues a token 200 to a peripheral node 102 interface. After a reasonable delay that may depend upon the nature of the token 200 originally issued, block 996 directs the controller supervisory business object 990 to determines whether a token 200 has been returned by the supervised peripheral business object 992. If so, then the supervisory process terminates normally. Alternatively, if not, then block 998 directs the controller supervisory business object 990 to issue a first reminder token 200bn to the supervised peripheral business object 992.

After a reasonable delay that may depend upon the nature of the token 200 originally issued, block 1000 directs the controller supervisory business object 990 to determines whether a token 200 has been returned by the supervised peripheral business object 992. If so, then supervisory process terminates normally. Alternatively, if not, then block 1002 directs the controller supervisory business object 990 to issue a second reminder token 200bo to the supervised peripheral business object 992.

After a reasonable delay that may depend upon the nature of the token 200 originally issued, block 1004 directs the controller supervisory business object 990 to determines whether a token 200 has been returned by the supervised peripheral business object 992. If so, then supervisory process terminates normally. Alternatively, if not, then block 1006 directs the controller supervisory business object 990 to invoke an error handler. The error handler is desirably programmed to cause the controller 104 to issue appropriate tokens 200 either to keep the transaction moving forward or to cancel the transaction without unduly harming the parties involved. Specific actions include alerting a human administrator resident at the controller 104, appointing a new program partner at another peripheral node 102 to fulfill the unsatisfied obligations, and canceling the network 100 access of the delinquent party.

It will be appreciated that in an alternate embodiment the supervisory business object 990 may be incorporated into any of the business objects resident at the controller 104 instead of being a freestanding business object.

Figure 38 illustrates a second supervisory process transacted between the controller 104 and more than one of the other interfaces at the peripheral nodes 102, in this instance two of the peripheral nodes 102. The second supervisory process is very similar to the first supervisory process except that it supports a communication relationship between controller 104 and peripheral nodes 102 in which the controller 104 issues a token 200 to a first peripheral node 102 but receives a back a corresponding token 200 from a second peripheral node 102 instead of the first peripheral node 102.

Generally, the second supervisory process also ensures that each of the processes described above progresses and progresses at a reasonable pace.

The controller 104 is responsible for ensuring that the steps of a transaction occur in a predetermined order and at a predetermined rate. In this regard, the controller 104 issues tokens 200 according to a particular schedule and requires that it receive tokens 200 back from peripheral interfaces 200 according to the particular schedule. In this way, the controller 104 is able to regulate and control all transactions on the network 100.

The second supervisory process is transacted between a controller supervisory business object 990 and first and second supervised peripheral business object 992a, 992b, which may in actuality any two of the business objects 196 resident at two peripheral nodes 102 that interact with the controller 104 through any of the processes described above. It will be appreciated that supervisory business object 990 could the identify the first and second supervised peripheral business object 992a, 992b with reference either to the originally issued token 200 or the databases maintained in the storage device 140.

The second supervisory process is initiated at block 994 when a business object 184 resident at the controller 104 issues a token 200 to a peripheral node 102 interface. After a reasonable delay that may depend upon the nature of the token 200 originally issued, block 996 directs the controller supervisory business object 990 to determine whether a token 200 has been returned by either of the first and second supervised peripheral business object 992a, 992b. If so, then the supervisory process terminates normally. Alternatively, if not, then block 998 directs the controller supervisory business object 990 to issue a first reminder token 200bn to one or both of the first and second supervised peripheral business object 992a, 992b.

After a reasonable delay that may depend upon the nature of the token 200 originally issued, block 1000 directs the controller supervisory business object 990 to determines whether a token 200 has returned by either of the first and second supervised peripheral business object 992a, 992b. If so, then supervisory process terminates normally. Alternatively, if not, then block 1002 directs the controller supervisory business object 990 to issue a second reminder token 200bo to one or both of the first and second supervised peripheral business object 992a, 992b.

After a reasonable delay that may depend upon the nature of the token 200 originally issued, block 1004 directs the controller supervisory business object 990 to determines whether a token 200 has been returned by either of the first and second supervised peripheral business object 992a, 992b. If so, then supervisory process terminates normally. Alternatively, if not, then block 1006 directs the controller supervisory business object 990 to invoke an error handler. The error handler is desirably programmed to cause the controller 104 to issue appropriate tokens 200 either to keep the transaction moving forward or to cancel the transaction without unduly harming the parties involved.

Specific actions include alerting a human administrator resident at the controller 104, appointing a new program partner at another peripheral node 102 to fulfill the unsatisfied obligations, and canceling the network 100 access of the delinquent party.

Thus it will be seen that the foregoing discloses an efficient way to coordinate interactions between trading parties. In particular, there is described a method, system and apparatus for presenting an offer by a group of at least two parties to provide a lot comprising at least one item comprising at least one of a product and a service; selecting at least one winning bid received from at least one winning bidder, selected from at least one bid received from at least one bidder bidding consideration in satisfaction of the offer presented; and fulfilling the offer and the at least one winning bid by arranging for the group to receive the consideration that was bid in the at least one winning bid and for the at least one winning bidder to receive the lot.

One embodiment of the invention includes a network 100 interconnecting several computers 130 operable by parties and potential parties to a trading transaction. Each computer 130 has a main processor 132 that is programmed to implement functionality of the invention. To this end, each processor 132 may be programmed by codes provided by a computer medium, such as a CD-ROM, a diskette, or an EPROM, for example. Alternatively, or in addition, such codes may be provided by code segments of a signal embodied in a carrier wave and may be received by downloading from a server on the Internet or other communications network, for example.

While specific examples have been used for purposes of illustration, many modifications may be made by those skilled in the art without departing from the core of the invention, which is defined in the claims below.

Claims

Claims What is claimed is:

1. A method comprising:

(a) presenting an offer by a group of at least two parties to provide a lot 5 comprising at least one item comprising at least one of a product and a service;

(b) selecting at least one winning bid received from at least one winning bidder, selected from at least one bid received from at least one bidder bidding consideration in satisfaction of the offer presented; o and

(c) fulfilling the offer and the at least one winning bid by arranging for the group to receive the consideration that was bid in the at least one winning bid and for the at least one winning bidder to receive the lot. s

2. The method claimed in claim 1 , wherein presenting comprises presenting an offer by a group that comprises at least one member selected from the list: seller, insurer, shipper, inspector, financer, and escrow agent.

3. The method claimed in claim 2, wherein presenting comprises o presenting an offer by a group that comprises at least one member selected by a controller and not by either a seller or the at least one bidder.

4. The method claimed in claim 3, wherein presenting comprises receiving payment from the at least one member selected by the controller.

5 5. The method claimed in claim 1 , wherein presenting comprises presenting an offer that comprises terms dependent on the at least one bid received.

6. The method claimed in claim 5, wherein presenting comprises presenting an offer that comprises terms dependent on the at least one o bid received, dependent terms comprising the membership of the group.

7. The method claimed in claim 6, wherein presenting comprises presenting an offer that comprises terms dependent on at least one of a characteristic and a preference of the at least one bidder bidding consideration in satisfaction of the offer presented. 5

8. The method claimed in claim 1, wherein presenting the offer comprises validating the group.

9. The method claimed in claim 8, wherein validating the group comprises assessing the businessworthiness of at least one member of the group.

10. The method claimed in claim 8, wherein validating the group comprises 0 monitoring infractions by a member of the group, an infraction comprising an occasion when a member failed to meet an obligation as offered.

11. The method claimed in claim 1 , wherein presenting the offer comprises validating the offer.

5 12. The method claimed in claim 11 , wherein validating the offer comprises requesting an inspection of the lot.

13. The method claimed in claim 12, wherein presenting the offer comprises reporting results of the inspection of the lot.

14. The method claimed in claim 1 , wherein presenting the offer comprises o presenting costs for inspecting the lot.

15. The method claimed in claim 1 , wherein presenting the offer comprises presenting costs for fulfilling, comprising at least one of shipping costs, inspection costs, customs costs, taxation costs, duty costs, insurance costs, escrow costs, credit costs, and commission costs. s

16. The method claimed in claim 1 , wherein presenting the offer comprises presenting the total cost to deliver the lot to the at least one bidder bidding consideration in satisfaction of the offer presented.

17. The method claimed in claim 1 , wherein presenting comprises presenting a plurality of offers. o

18. The method claimed in claim 17, wherein presenting a plurality of offers comprises presenting a subset of the plurality of offers in response to a search request.

19. The method claimed in claim 18, wherein presenting a subset comprises presenting a subset in response to identifying a submitter of a previously 5 . submitted search request.

20. The method claimed in claim 1 , wherein presenting the offer comprises presenting the total cost to deliver the lot to the at least one bidder bidding consideration in satisfaction of the offer presented divided by a number of items in the lot to yield a per item cost. o

21. The method claimed in claim 20, wherein selecting at least one winning bid comprises selecting from at least one bid received from at least one bidder bidding consideration in satisfaction of less than the number of items in the lot.

22. The method claimed in claim 21 , wherein selecting at least one winning 5 bid comprises selecting at least one bid expressed in a per item cost and a quantity of items for less than the total number of items in the lot.

23. The method claimed in claim 22, wherein selecting at least one winning bid comprises selecting a plurality of bids expressed in per item cost and quantity of items such that the combined quantity of items for all of the o plurality of bids selected is less than or equal to the number of items in the lot.

24. The method claimed in claim 1 , wherein fulfilling comprises arranging for at least one of: full payment for the lot, a letter of credit pledged for the lot, and escrowing the lot and the payment for the lot.

25. The method claimed in claim 24, wherein fulfilling comprises arranging for at least one of: inspection of the lot, delivery of the lot, and insurance of the lot.

26. The method claimed in claim 1 , further comprising coordinating at least one of presenting, selecting, and fulfilling by exchanging a token between a plurality of nodes in a network comprising a central controller and a plurality of peripheral processors in communication with the central controller, each peripheral processor respectively operable by at least one of the group or the at least one bidder.

27. The method claimed in claim 26, wherein exchanging the token comprises securely signing the token at at least one of the plurality of nodes.

28. The method claimed in claim 27, wherein exchanging the token comprises exchanging data between the token and at least one of the plurality of nodes.

29. The method claimed in claim 28, wherein exchanging data comprises exchanging a request that another one of the plurality of nodes perform an action.

30. The method claimed in claim 28, wherein exchanging data comprises performing an action at at least one of the plurality of nodes in response to the data exchanged.

31. The method claimed in claim 27, further comprising presenting a database entry form mapped to the exchanged data at at least one of the plurality of nodes.

32. The method claimed in claim 27, further comprising maintaining a database comprising a list of prior token exchanges.

33. The method claimed in claim 32, wherein maintaining a database comprises maintaining a database comprising a list of planned token exchanges.

34. The method claimed in claim 33, wherein exchanging the token comprises exchanging at least a portion of the database between the token and a node.

35. A computer readable medium for providing codes for directing a processor to:

(a) present an offer by a group of at least two parties to provide a lot comprising at least one item comprising at least one of a product and a service;

(b) select at least one winning bid received from at least one winning bidder, selected from at least one bid received from at least one bidder bidding consideration in satisfaction of the offer presented; and

(c) fulfill the offer and the at least one winning bid by arranging for the group to receive the consideration that was bid in the at least one winning bid and for the at least one winning bidder to receive the lot.

36. A signal embodied in a carrier wave, the signal having code segments for directing a processor, the signal comprising:

(a) a first code segment directing the processor to present an offer by a group of at least two parties to provide a lot comprising at least one item comprising at least one of a product and a service;

(b) a second code segment directing the processor to select at least one winning bid received from at least one winning bidder, selected from at least one bid received from at least one bidder bidding consideration in satisfaction of the offer presented; and (c) a third code segment directing the processor to fulfill the offer and the at least one winning bid by arranging for the group to receive the consideration that was bid in the at least one winning bid and for the at least one winning bidder to receive the lot.

37. An apparatus, comprising: (a) means for presenting an offer by a group of at least two parties to provide a lot comprising at least one item comprising at least one of a product and a service;

(b) means for selecting at least one winning bid received from at least one winning bidder, selected from at least one bid received from at least one bidder bidding consideration in satisfaction of the offer presented; and

(c) means for fulfilling the offer and the at least one winning bid by arranging for the group to receive the consideration that was bid in the at least one winning bid and for the at least one winning bidder to receive the lot.

38. An apparatus, comprising:

(a) a processor;

(b) a communication port operable to connect the processor to a communication network for communication with a group of at least two parties and at least one bidder; and

(c) a memory storing codes for directing the processor to:

(i) present an offer by the group of at least two parties to provide a lot comprising at least one item comprising at least one of a product and a service; (ii) select at least one winning bid received from at least one winning bidder, selected from at least one bid received from the at least one bidder bidding consideration in satisfaction of the offer presented; and

(iii) fulfill the offer and the at least one winning bid by arranging for the group to receive the consideration that was bid in the at least one winning bid and for the at least one winning bidder to receive the lot.

39. The apparatus claimed in claim 38, wherein the codes for directing the processor to present comprise codes for directing the processor to present an offer by a group that comprises at least one member selected from the list: seller, insurer, shipper, inspector, financer, and escrow agent.

40. The apparatus claimed in claim 39, wherein the codes for directing the processor to present comprise codes for directing the processor to present an offer by a group that comprises at least one member selected by the processor and not by either a seller or the at least one bidder.

41. The apparatus claimed in claim 40, wherein the codes for directing the processor to present comprise codes for directing the processor to receive payment from the at least one member selected by the controller.

42. The apparatus claimed in claim 38, wherein the codes for directing the processor to present comprise codes for directing the processor to present an offer that comprises terms dependent on the at least one bid received.

43. The apparatus claimed in claim 42, wherein the codes for directing the processor to present comprise codes for directing the processor to present an offer that comprises terms dependent on the at least one bid received, dependent terms comprising the membership of the group.

44. The apparatus claimed in claim 43, wherein the codes for directing the processor to present comprise codes for directing the processor to present an offer that comprises terms dependent on at least one of a characteristic and a preference of the at least one bidder bidding consideration in satisfaction of the offer presented.

45. The apparatus claimed in claim 38, wherein the codes for directing the processor to present comprise codes for directing the processor to validate the group.

46. The apparatus claimed in claim 45, wherein the codes for directing the processor to validate comprise codes for directing the processor to assess the businessworthiness of at least one member of the group.

47. The apparatus claimed in claim 45, wherein the codes for directing the processor to validate comprise codes for directing the processor to monitor infractions by members of the group, an infraction comprising an occasion when a member failed to meet an obligation as offered.

48. The apparatus claimed in claim 38, wherein the codes for directing the processor to present comprise codes for directing the processor to validate the offer.

49. The apparatus claimed in claim 48, wherein the codes for directing the 5 processor to validate the offer comprise codes for directing the processor to request an inspection of the lot.

50. The apparatus claimed in claim 49, wherein the codes for directing the processor to present comprise codes for directing the processor to report results of the inspection of the lot. o

51. The apparatus claimed in claim 38, wherein the codes for directing the processor to present the offer comprise codes for directing the processor to present costs for inspecting the lot.

52. The apparatus claimed in claim 38, wherein the codes for directing the processor to present the offer comprise codes for directing the s processor to present costs for fulfilling the offer, comprising at least one of shipping costs, inspection costs, customs costs, taxation costs, duty costs, insurance costs, escrow costs, letter of credit costs, and commission costs.

53. The apparatus claimed in claim 38, wherein the codes for directing the o processor to present the offer comprise codes for directing the processor to present the total cost to deliver the lot to the at least one bidder bidding consideration in satisfaction of the offer presented.

54. The apparatus claimed in claim 38, wherein the codes for directing the processor to present the offer comprise codes for directing the 5 processor to present a plurality of offers.

55. The apparatus claimed in claim 54, wherein the codes for directing the processor to present a plurality of offers comprise codes for directing the processor to:

(a) receive a search request; and 0 (b) present a subset of the plurality of offers in response to the search request.

56. The apparatus claimed in claim 55, wherein the codes for directing the processor to present a subset comprise codes for directing the processor to: 5 (a) identify a submitter of a previously submitted search request; and

(b) present a subset in response to identifying the submitter of a previously submitted search request.

57. The apparatus claimed in claim 38, wherein the codes for directing the processor to present the offer comprise codes for directing the 0 processor to present the total cost to deliver the lot to the at least one bidder bidding consideration in satisfaction of the offer presented divided by a number of items in the lot to yield a per item cost.

58. The apparatus claimed in claim 57, wherein the codes for directing the processor to select at least one winning bid comprise codes for directing the processor to select from at least one bid received from at least one bidder bidding consideration in satisfaction of less than the number of items in the lot.

59. The apparatus claimed in claim 58, wherein the codes for directing the processor to select at least one winning bid comprise codes for directing the processor to select at least one bid expressed in a per item cost and a quantity of items less than the number of items in the lot.

60. The apparatus claimed in claim 59, wherein the codes for directing the processor to select at least one winning bid comprise codes for directing the processor to select a plurality of bids expressed in per item cost and quantity of items such that the combined quantity of items for all of the plurality of bids selected is less than or equal to the number of items in the lot.

61. The apparatus claimed in claim 38, wherein the codes for directing the processor to fulfill comprise codes for directing the processor to arrange for at least one of: full payment for the lot, a letter of credit pledged for the lot, and escrowing the lot and the payment for the lot.

62. The apparatus claimed in claim 61 , wherein the codes for directing the processor to fulfill comprise codes for directing the processor to arrange for at least one of: inspection of the lot, delivery of the lot, and insurance of the lot.

63. The apparatus claimed in claim 38, wherein the memory further stores codes for directing the processor to coordinate at least one of presenting, selecting, and fulfilling by communicating a token via the communication port, communicating including at least one of transmitting a token to the communication port and receiving a token from the communication port.

64. The apparatus claimed in claim 63, wherein the codes for directing the processor to coordinate comprise codes for directing the processor to perform a function including at least one of associating a secure signature to a token transmitted to the communication port and validating a secure signature associated with a token received from the communication port.

65. The apparatus claimed in claim 64, wherein the codes for directing the processor to coordinate comprise codes for directing the processor to exchange data with the token, comprising at least one of recording data into the token and retrieving data from the token.

66. The apparatus claimed in claim 65, wherein the codes for directing the processor to exchange data with the token comprise codes for directing the processor exchange a request with the token, comprising at least one of recording into the token a request that a token recipient perform an action or retrieving from the token a request to perform an action from a token transmitter.

67. The apparatus claimed in claim 66, wherein the codes for directing the processor to exchange data with the token comprise codes for directing the processor to present a database entry form mapped to the exchanged data.

68. The apparatus claimed in claim 38, wherein the codes for directing the processor to coordinate comprise codes for directing the processor to maintain a database comprising a list of prior token exchanges.

69. The apparatus claimed in claim 38, wherein the codes for directing the processor to coordinate comprise codes for directing the processor to maintain a database comprising a list of planned token exchanges.

70. The apparatus claimed in claim 38, wherein the codes for directing the processor to coordinate comprise codes for directing the processor to maintain a database and to exchange at least a portion of the database with the token, wherein exchanging at least a portion of the database with the token includes at least one of recording data from the database into the token and retrieving data from the token for recordation in the database.

71. A bidder interface apparatus operable to communicate with the apparatus of claim 38 via the communication network, comprising:

(a) a processor;

(b) a communication port operable to connect the processor to the communication network; and (c) a memory storing codes for directing the processor to communicate a token via the communication port, communicating including at least one of transmitting a token to the communication port and receiving a token from the communication port, such that the bidder interface is operable to transmit a token to the apparatus and to receive a token from the apparatus.

72. A seller interface apparatus operable to communicate with the apparatus of claim 38 via the communication network, comprising:

(a) a processor;

(b) a communication port operable to connect the processor to the communication network; and

(c) a memory storing codes for directing the processor to communicate a token via the communication port, communicating including at least one of transmitting a token to the communication port and receiving a token from the communication port, such that the seller interface is operable to transmit a token to the apparatus and to receive a token from the apparatus.

73. An insurer interface apparatus operable to communicate with the apparatus of claim 38 via the communication network, comprising:

(a) a processor;

(c) a memory storing codes for directing the processor to communicate a token via the communication port, communicating including at least one of transmitting a token to the communication port and receiving a token from the communication port, such that the insurer interface is operable to transmit a token to the apparatus and to receive a token from the apparatus.

74. A shipper interface apparatus operable to communicate with the apparatus of claim 38 via the communication network, comprising:

(i) a processor; (ii) a communication port operable to connect the processor to the communication network; and

(iii) a memory storing codes for directing the processor to communicate a token via the communication port, communicating including at least one of transmitting a token to the communication port and receiving a token from the communication port, such that the shipper interface is operable to transmit a token to the apparatus and to receive a token from the apparatus.

75. An inspector interface apparatus operable to communicate with the apparatus of claim 38 via the communication network, comprising:

(i) a processor;

(ii) a communication port operable to connect the processor to the communication network; and

(iii) a memory storing codes for directing the processor to communicate a token via the communication port, communicating including at least one of transmitting a token to the communication port and receiving a token from the communication port, such that the inspector interface is operable to transmit a token to the apparatus and to receive a token from the apparatus.

76. An escrow agent interface apparatus operable to communicate with the apparatus of claim 38 via the communication network, comprising:

(i) a processor;

(ii) a communication port operable to connect the processor to the communication network; and (iii) a memory storing codes for directing the processor to communicate a token via the communication port, communicating including at least one of transmitting a token to the communication port and receiving a token from the communication port, such that the escrow agent interface is operable to transmit a token to the apparatus and to receive a token from the apparatus.

77. A financer interface apparatus operable to communicate with the apparatus of claim 38 via the communication network, comprising: (i) a processor;

(iii) a memory storing codes for directing the processor to communicate a token via the communication port, communicating including at least one of transmitting a token to the communication port and receiving a token from the communication port, such that the financer interface is operable to transmit a token to the apparatus and to receive a token from the apparatus.

78. A system, comprising a central controller having a network interface operable:

(a) to communicate with a seller interface apparatus and to receive from the seller interface apparatus an offer to provide an item including at least one of a product and a service; (b) to communicate with a bidder interface apparatus and to receive from the bidder interface apparatus a bid in satisfaction of the offer;

(c) to communicate with a shipper interface apparatus and to receive from the shipper interface apparatus particulars for shipping the item from a seller associated with the seller interface apparatus to a bidder associated with the bidder interface apparatus; and

(d) to communicate with an insurer interface apparatus and to receive from the insurance interface apparatus particulars of insurance coverage for shipping the item from the seller to the bidder.

79. A system as claimed in Claim 78, further comprising a seller interface apparatus in communication with the network interface.

80. A system as claimed in Claim 79, further comprising a bidder interface apparatus in communication with the network interface.

81. A system as claimed in Claim 80, further comprising a shipper interface apparatus in communication with the network interface.

82. A system as claimed in Claim 81, further comprising an insurer interface apparatus in communication with the network interface.

83. A system as claimed in Claim 78, wherein the network interface is further operable to communicate with an inspector interface apparatus to receive from the inspector interface apparatus particulars of an inspection of the item.

84. A system as claimed in Claim 83, further comprising an inspector interface apparatus in communication with the network interface.

85. A system as claimed in Claim 78, wherein the network interface is further operable to communicate with a financer interface apparatus and to receive from the financer interface apparatus particulars of trade facilities extended to the bidder.

86. A system as claimed in Claim 85, further comprising a financer interface apparatus in communication with the network interface.

87. A system as claimed in Claim 78, wherein the network interface is further operable to communicate with an escrow agent interface apparatus and to receive from the escrow agent interface apparatus particulars of an escrow established between the bidder and the seller pertaining to the item.

88. A system as claimed in Claim 81 , further comprising an escrow agent interface apparatus in communication with the network interface.

89. A server running a program for a web-based service for buyers to enter into at least one of national and international trade transactions with sellers, in which a number of additional participants can potentially participate, the additional participants being selected from the following list: (a) insurers;

(b) financial institutions offering trade facilities to buyers

(c) escrow agents for holding funds submitted by buyers;

(d) logistics co-ordinators, comprising shippers and freight forwarders; and (e) inspectors of goods or production processes; in which at least one of the additional participants which actually participates in a given transaction is not selected by either of the buyers or sellers but instead has been previously selected by a central coordinating authority prior to the transaction.

90. The server of claim 89 in which at least one of the additional participants pays a fee to the central co-ordinating authority to participate in a given transaction.

91. The server of claim 90 in which a buyer bids an amount for goods of interest based on a per unit price, rather than a price for a complete consignment of goods, with a buyer being able to bid successfully for a part only of a single consignment, with the goods being shipped or otherwise transported once other buyers have successfully bid for the remaining items in a consignment.

92. The server of claim 90 in which the server stores substantially all of the information required for all participants to fully participate in a transaction.

93. A server running a program for a web-based service for buyers to enter into trade transactions with sellers, in which a potential buyer can select items of goods for sale from one or more sellers, and cause a list only of the selected items to be displayed for viewing by that particular potential buyer at his client device.