WO2001044994A2 - Procede, systeme et appareil de transactions - Google Patents

Procede, systeme et appareil de transactions Download PDF

Info

Publication number
WO2001044994A2
WO2001044994A2 PCT/CA2000/001189 CA0001189W WO0144994A2 WO 2001044994 A2 WO2001044994 A2 WO 2001044994A2 CA 0001189 W CA0001189 W CA 0001189W WO 0144994 A2 WO0144994 A2 WO 0144994A2
Authority
WO
WIPO (PCT)
Prior art keywords
token
processor
directing
interface
codes
Prior art date
Application number
PCT/CA2000/001189
Other languages
English (en)
Other versions
WO2001044994A8 (fr
Inventor
Kombiz O. Eghdami
Alton Ing
Duncan Westby Phillips
Original Assignee
Vlinx.Com, Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Vlinx.Com, Inc. filed Critical Vlinx.Com, Inc.
Priority to AU77664/00A priority Critical patent/AU7766400A/en
Publication of WO2001044994A2 publication Critical patent/WO2001044994A2/fr
Publication of WO2001044994A8 publication Critical patent/WO2001044994A8/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/04—Trading; Exchange, e.g. stocks, commodities, derivatives or currency exchange

Definitions

  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • a method and corresponding apparatus for facilitating trade there is provided.
  • 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.
  • financer 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.
  • 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.
  • 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.
  • exchanging the token comprises exchanging at least a portion of the database between the token and a node.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • a signal embodied in a carrier wave 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the server stores substantially all of the information required for all participants to fully participate in a transaction.
  • 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.
  • 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.
  • 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 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.
  • 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.
  • VLINX.com 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.
  • VLINX.com 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.
  • 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 opening 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.
  • 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.
  • 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.
  • 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.
  • FIG. 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.
  • 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.
  • 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.
  • 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.
  • TCP/IP Transmission Control Protocol / Internet Protocol
  • Implementation Figure 2 illustrates a node 102 in greater detail.
  • 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.
  • 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.
  • 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
  • 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.
  • 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.
  • 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.
  • the functionality of the encryption processor 152 might also be implemented in the main processor 132.
  • some information relating to a transaction may not require encryption and that some parties to a transaction may not wish to use encryption.
  • 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.
  • 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.
  • Windows NT ® operating system includes network clients, including Internet Explorer ® , an Internet browser capable of transmitting signals to and receiving signals from the Internet.
  • 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.
  • 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.
  • 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.
  • 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
  • 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.
  • a Seller-ID unique record-key field
  • 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.
  • a Bidder-ID unique record-key field
  • 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.
  • Insurer-ID a unique record-key field
  • 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.
  • a Bid-ID unique record-key field
  • 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.
  • 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.
  • a Shipment- ID a unique record-key field
  • 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.
  • LofC-ID unique record-key field
  • 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.
  • 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.
  • 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.
  • 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.
  • Figure 13 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 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.
  • the data storage device 140 further maintains an object request broker 186 compliant with the Object Management
  • CORBA Common Object Request Broker Architecture
  • 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.
  • 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.
  • 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.
  • 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.
  • the business objects 196 are created and maintained using a software application called Visual Knowledge ® sold by Big Server Software,
  • 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.
  • 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
  • FIG 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.
  • 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.
  • 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.
  • the script 208 may include
  • 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.
  • 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.
  • HTML Hypertext Markup Language
  • 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.
  • 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
  • Figure 33 which depicts an insurance cover note form.
  • the payload 210 might include codes representing data and/or behavior.
  • the payload 210 might include one or more software objects, or pointers or references thereto, representing information stored in the databases
  • 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.
  • 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.
  • 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.
  • a static or dynamic instance of the page could be contained in the original electronic mail message to the recipient.
  • FIG 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • FIGS 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.
  • 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.
  • 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.
  • 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.
  • the authorization request token 200b is detected and processed by the financer registration business object 254.
  • the financer registration business object 254 analyzes the businessworthiness of the applicant seller, implementing a credit check for example.
  • 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.
  • the controller registration business object 252 detects and processes 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.
  • FIGS 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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
  • 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.
  • 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.
  • 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.
  • 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.
  • the authorization request token 200n is detected and processed by the financer registration business object 374.
  • 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.
  • the controller registration business object 372 detects and processes 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.
  • 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.
  • 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.
  • 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.
  • the terms may be used interchangeably.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the propagated bidding token 200u might be implemented as an electronic mail message.
  • 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.
  • 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.
  • 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.
  • the completion token 200v* is detected and processed by the respective bidder bidding business object 450 at block 486.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the post-bid request for quotation form 520 includes buyer delivery information generally illustrated at 522, and import information generally illustrated at 524.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the completion token 200v 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.
  • 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.
  • the controller post-bidding business object 502 may also cancel the Bidder-ID associated with the improperly rejected purchase.
  • 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.
  • 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.
  • 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
  • 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.
  • 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.
  • 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
  • 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.
  • 200aj might be combined into one token.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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
  • the insurer logistics business object 660 detects and processes the insurance request token 200aq, arranging for the specified insurance.
  • 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
  • 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.
  • the bidder logistics business object Upon receipt of the bill of lading token 200at by the bidder logistics business object
  • the buyer receives the legal authority to claim ownership and possession in the auctioned items.
  • 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.
  • 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.
  • 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.
  • 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.
  • toll token 200ba is detected and processed by the controller logistics business object 654 at block 748.
  • 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.
  • 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
  • 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.
  • 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.
  • 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 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.
  • 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.
  • 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
  • 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.
  • 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.
  • 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.
  • 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
  • the insurer logistics business object 810 detects and processes the insurance request token 200aq, arranging for the specified insurance.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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
  • payment token 200ay is detected and processed by the seller's-financer logistics business object 812 at block 894.
  • 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.
  • 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.
  • the toll token 200ba is detected and processed by the controller logistics business object 804 at block 902.
  • 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.
  • 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.
  • 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.
  • the inspection is akin to an ISO900X inspection directed to process rather than product.
  • 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.
  • 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.
  • the controller inspection business object 932 detects and processes plant inspection report token, extracting salient data from the payload 210.
  • 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
  • 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.
  • 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.
  • 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
  • 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.
  • 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.
  • 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.
  • the seller inspection business object 952 detects and processes the inspection report token 200bl and presents it to the seller.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the foregoing discloses an efficient way to coordinate interactions between trading parties.
  • 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.
  • 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.
  • 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.

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • Engineering & Computer Science (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Strategic Management (AREA)
  • Technology Law (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

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.
PCT/CA2000/001189 1999-12-15 2000-10-06 Procede, systeme et appareil de transactions WO2001044994A2 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU77664/00A AU7766400A (en) 1999-12-15 2000-10-06 Transaction method, system, and apparatus

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US46428099A 1999-12-15 1999-12-15
US09/464,280 1999-12-15

Publications (2)

Publication Number Publication Date
WO2001044994A2 true WO2001044994A2 (fr) 2001-06-21
WO2001044994A8 WO2001044994A8 (fr) 2001-11-15

Family

ID=23843261

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CA2000/001189 WO2001044994A2 (fr) 1999-12-15 2000-10-06 Procede, systeme et appareil de transactions

Country Status (2)

Country Link
AU (1) AU7766400A (fr)
WO (1) WO2001044994A2 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2018096501A1 (fr) * 2016-11-24 2018-05-31 Diversify Finance Limited Système et procédé destiné au traitement d'un jeton d'authentification de requête

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
No Search *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2018096501A1 (fr) * 2016-11-24 2018-05-31 Diversify Finance Limited Système et procédé destiné au traitement d'un jeton d'authentification de requête

Also Published As

Publication number Publication date
AU7766400A (en) 2001-06-25
WO2001044994A8 (fr) 2001-11-15

Similar Documents

Publication Publication Date Title
US7162458B1 (en) System and method for process mining
Rao et al. How buyers' expected benefits, perceived risks, and e-business readiness influence their e-marketplace usage
US6141653A (en) System for interative, multivariate negotiations over a network
US6338050B1 (en) System and method for providing and updating user supplied context for a negotiations system
US6332135B1 (en) System and method for ordering sample quantities over a network
US6336105B1 (en) System and method for representing data and providing electronic non-repudiation in a negotiations system
US7363271B2 (en) System and method for negotiating and providing quotes for freight and insurance in real time
US20020099611A1 (en) Formation of horizontal, vertical and diagonal databases in an extranet based e-commerce platform
US20080147516A1 (en) Systems, methods and apparatuses for a payment facilitation engine
US20020138400A1 (en) Buying and selling goods and services using automated method and apparatus
US7536336B1 (en) Multi-party electronic transactions
US20050187866A1 (en) Method and system for executing financial transactions via a communication medium
US20010056395A1 (en) Internet bargaining system
WO2000039729A1 (fr) Procede et systeme de traitement et de transmission de donnees electroniques de mise aux encheres inversees
WO2002001468A2 (fr) Systeme de gestion de relations entre partenaires
JP2006500696A (ja) 取引に基づく税金を計算するシステムと方法
Koorn et al. E-procurement and Online Marketplaces
US20020198805A1 (en) Method and apparatus for optimizing taxes in a transaction
Limthanmaphon et al. An agent-based negotiation model supporting transactions in electronic commerce
WO2014071447A1 (fr) Perfectionnements dans le commerce électronique
WO2001044994A2 (fr) Procede, systeme et appareil de transactions
JP2003076777A (ja) 国際電子・決済・物流・取引保証を行うビジネスプラン
WO2000029976A1 (fr) Systeme integre de conception d'un site web a distance
WO2002069074A2 (fr) Systeme et procede destines a un systeme d'enregistrement automatise
KR20020005549A (ko) 인터넷을 기반으로 하는 1차산업 생산 상품의 경매와 물류운송 관리 시스템.

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CR CU CZ DE DK DM DZ EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
AK Designated states

Kind code of ref document: C1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CR CU CZ DE DK DM DZ EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: C1

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

D17 Declaration under article 17(2)a
REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase in:

Ref country code: JP