Source: https://patents.google.com/patent/US20020107786A1/en
Timestamp: 2019-04-26 08:25:22+00:00

Document:
A peer-to-peer application program is employed in a computer network of users where each user has an established business relationship with at least one other user in the network. The present invention software executed in this network provides an open market trading of goods which takes advantage of the preexisting business relationships.
This application claims the benefit of U.S. Provisional Application No. 60/253,339, filed on Nov. 28, 2000, and U.S. Provisional Application No. 60/250,093, filed on Nov. 30, 2000. The entire teachings of the above applications are incorporated herein by reference.
A computer may transmit a confirmation package that traverses the exact node path of an originally confirmed request package. The confirmation package may be transmitted for billing purposes. The constraints may be configured independently via an interface on each computer in the plurality.
FIG. 5 is a block diagram of a quantity filter employed in the software system of FIG. 3.
As stated above, Applicants take advantage of the peer-to-peer applications programming paradigm in a computer network of users where each user has an established business relationship with at least one other user in the network. The present invention software  19 (FIG. 1) executed in this network provides an open market trading of goods which takes advantage of the preexisting business relationships. These preexisting business relationships are reflected in configuration of the apparatus to communicate with a corresponding apparatus owned by each of the related parties. Thus the relationships form a logical network operating over a physical network layer for the following request and response communications. This allows each participant in the network to control the flow of information through their systems, and to set and control prices of goods transacted through their systems.
Referring to FIG. 1, a first party transmits a request package  21 a from his node 11 to that of a trusted second party with whom there is an existing (and perhaps long standing) business relationship. The request package 21 a includes (i) asking price of a good that the first party is trying to sell or a bid of a good that the first party is looking to buy, and (ii) limitations or constraints on the request being made (e.g., number of subsequent nodes the request may be transmitted to).
The second party's node  13 receives the request package 21 a and generates rules 23 (FIG. 2) in accordance with the limitations/constraints included in the request package. The second party user in response prepares and transmits another request package 21 b to his business contacts that would likely accommodate the original request (i.e., that of the first party's). In the second party generated request package 21b are (i) a modified asking price or bid of the original request goods (i.e., the original asking price or bid plus a commission for the second party) and (ii) limitations or constraints placed by the first and second parties.
The generated nodes  23 at each communication level govern the received and next generated request packages 21. As such, the present invention 19 provides dynamic rules-based management of requests.
The second party generated request package  21 b is received at respective receiver's nodes 15 a, b, c as designated by the second party and processing continues similarly.
Return responses  17 a, b, c, d are likewise transmitted from the receiving party to the sending party and processed accordingly. For example, the second party receives at his node responses 17 a, b, c from his business contacts in receipt of the second party generated request package 21 b. He accepts the best response 17 given the constraints of the original request package 21 a from the first party. He in turn transmits a reply 17 d to the first party based on the accepted response from the second party's business contacts.
Similarly a buyer indicates his bid orders through the trading room screen view of FIG. 3. The system assigns each buyer a unique ID and stores the buyer's bid orders in the database  304 indicating buyer by his ID. The buyer's bid order indicates a kind of goods that the buyer is desiring to purchase. This is unlike online auctions in which the buyer is bidding on a specific individual item. In the buyer's order, the buyer indicates quantity, preferences (if any) of features and attributes of the kinds of goods desired and price that he is willing to pay (termed “bid”). The buyer also states the terms at which he is willing to pay a higher bid price such as with a larger quantity so that a more economical per unit price is obtained or to increase his price as a function of time because the buyer is wanting to complete the transaction by a certain ending date/time and thus willing to increase his bid price. From these buyer stated terms, the system generates rules that are stored in the database 304 along with the buyer's orders.
In the preferred embodiment the database  304 stores the buyer's orders in respective records. For each record there are fields corresponding to the features and aspects and other details of the buyer's order (i.e., quantity, bid price . . . ). The buyer specified rules are stored in the corresponding record or linked thereto, or likewise associated therewith.
Referring to FIG. 3, the end user views a trading room screen  306 which shows for a certain kind of goods, the buyer's orders (bids) and seller's orders (asks) of that kind of goods as stored in records in the database. It is through this screen that transactions of open market trading occur. The screen view is updated by the supporting modules, namely the commodity filter, quantity filter and matching subsystem discussed next.
The commodity filter  400 is at the lowest level of the system 31 and parses users' preferences to generate a custom dynamic marketplace (trading room). This in effect allows end users to view non-identical items as commodities. Market trading rooms are defined only as broad categories based on the least common denominator, so a steel trading room will be distinct from a copper trading room. The commodity filter 400 allows users to configure a custom market from both goods specific attributes (such as item specifications) and market specific attributes (such as delivery location, commitment date, shipment and payment terms). Users' preferences might only partially overlap with one another, which under prior art circumstances would create an inefficiency in the market trading. The commodity filter eliminates that inefficiency and guarantees that at all times a user will see his desired market in the “trading room” screen views. This facilitates better trading, which leads to increased liquidity.
In other words, if a small computer parts retailer is purchasing DIMM memory chips on a distressed inventory trading site and does not care whether he purchases 8 ns or 10 ns modules, he can configure his viewing of the DIMM market with one mouse click in the present invention  31 so that chips of both speeds appear as a single commodity in a true bid-ask market format (the system trading room).
The commodity filter may also parse all goods of a kind based on a “minimum quality” rating system. The system  31 prompts to end user with a numerical “minimum quality” of a particular attribute, and will return matching items that meet that minimum criteria. For example, if a user wishes to specify a bid for a computer processor with a “minimum quality” on the attribute “speed”, he may do so. If he specifies a rating of “100 Mhz”, the system will show him a listing of items that match that criteria, but also items that are an improvement (faster than 100 Mhz). This functionality can be enabled for any attribute that can be ranked on a qualitative scale.
A preferred embodiment of the commodity filter is detailed in FIG. 4 and U.S. Provisional Application No. 60/253,339, filed on Nov. 28, 2000, and U.S. Provisional Application No. 60/250,093, filed on Nov. 30, 2000, the contents of which are incorporated herein by reference in their entirety. Referring to FIG. 5, the Commodity Filter  400 is a system that allows multiple non-fungible items to be traded within an exchange as fungible, depending on the user's preference for certain category-specific criteria. The Commodity Filter dynamically generates a market for each user and allows only those items which the user designates as within his scope of indifference to appear in the market.
The treatment of bids and asks in this system is necessarily different. Bids, by their nature, are placed for an item with a minimum set of criteria. For some people's bids, certain characteristics will be specified, for other bids, those characteristics will be left blank and others will be specified. For asks, in general, all characteristics must be fully specified, as the ask describes a particular item. The market view  402, 404, 406 always corresponds to bids and asks that are compatible (i.e., the bids and asks could be matched to each other at a certain price) Bids are searched in the opposite manner as asks are: the bit strings must be checked to see that the bids are less specific than the parameters the user has selected for the view, whereas asks must be searched to see that the ask characteristics are at least as specific (match at least to the extent that is specified by the user).
A view is generated by retrieving all the possible entries from the database, using a call to the commodity filter  400 with the view settings and the skew parameter database entry as arguments. The commodity filter selection function in turn makes the calls to the BITWISE_SUBSET and BITWISE_SUPERSET functions, and does preprocessing and postprocessing to arrive at a final TRUE or FALSE boolean value describing whether the given bid or ask matches the marketplace view as described by the user's view parameters.
Once the view of the market is determined, a quantity filter  500 handles the number of items in that market. Again, the system is designed to allow the end user at all times to view the optimal market, no matter how many or few of a good that user wishes to transact. A buyer of 10,000 lbs. of hot rolled steel might normally (in prior art systems) find that sellers are only offering lots of 2,000 lbs. However, in the present invention system 31 the quantity filter automatically aggregates five such offers to create a custom virtual offer of 10,000 lbs. specifically for that buyer. Should the buyer accept the offer, the system automatically clears and routes the five separate transactions seamlessly and quickly. On the other hand, if a wheat buyer is only interested in purchasing a small lot of 100 bushels, the invention system displays offers of that size wherever possible. The quantity filter also behaves as an averaging mechanism and allows natural market forces to take effect quickly. As long as the total amount of a group of buyers' bids equals the amount of one or more seller(s) asks, the system will clear the transaction. The breakdown of those bids does not matter to the invention system where the supporting database enables itemized tracking of bids in a group that have been combined by the system.
The preferred embodiment of the quantity filter is detailed in FIG. 5 and U.S. Provisional Application No. 60/253,339, filed on Nov. 28, 2000, and U.S. Provisional Application No. 60/250,093, filed on Nov. 30, 2000, the contents of which are incorporated herein by reference in their entirety. Referring to FIG. 5, the Automatic Quantity Filtering and Aggregation System is a component of a bid-ask market exchange system for quantity-limited trading goods, consumer-oriented or otherwise. The Quantity Filter  500 dynamically generates, through both aggregation and filtering, a bid-ask market for a specified number of items. The system synthetically creates this market by automatically aggregating and filtering bids and asks, across multiple users if necessary, and presenting the optimal sets of orders compatible with the market viewer's desired preferences. This system eases and speeds the purchasing of large numbers of goods in such a system, in which individual orders may be of differing sizes and available quantities from different parties may vary, or be too small to fulfill a desired order size.
With reference to FIG. 3, the Market Hunter portion  302 of the system moves the marketplace beyond the boundaries of the immediate on line trading room. It works alongside the STMS to facilitate a seamless online exchange by interfacing with previously static buy-side requisitioning systems and sell-side catalogs to import bids and asks into the current trading room/marketplace. The displayed bids and asks are thus further updated by the same external systems and the STMS is able to then match and clear those orders—opening up the possibility for a completely automatic marketplace that requires minimal human interaction. In addition, if the system detects a limited number of active buyer bids or seller asks in a particular trading room, the Market Hunter 302 searches the address book portion of the database for appropriate participants (buyers and sellers). The buyers/sellers are indexed in the database by kind of goods usually dealt with, frequency/seasonal participation and the like. The results of the Market Hunter search of the database is a subset of buyers and sellers not currently participating in the displayed trading room. The Market Hunter immediately contacts the subset of buyers and/or sellers and automatically generates RFP's (request for proposals) and/or RFQ's (requests for quotes) in an attempt to draw dormant participants into the current trading room. Their responses may then be automatically entered into the trading room and once again create a custom user specific marketplace.
Referring to FIG. 1 and FIG. 2, in a preferred embodiment, the invention system requires that users only connect directly to other trusted users. A trusted user is another known and identified organization running the invention application  19 (FIG. 1). Before the application 19 connects to a trusted user, that remote user is authenticated in one of several ways (certificate, digital key, etc.). Once a connection has been established, users can send and receive “bids” (offers to buy) and “asks” (offers to sell).
Users may at any time issue primary order  21 a FIG. 1—bids or asks for items available to be traded in the marketplace. Primary orders 21 a are sent to all approved trusted users that are connected to the issuing user. (All users can decide which external parties receive primary orders.) In addition to being broadcast to the marketplace network, users keep a local record of all issued primary orders so that the invention client 19 can accurately update external clients 19 requesting a current marketplace overview.
Orders  21 (FIG. 2) may also be relayed in the system, following rules 23 (FIG. 2) for how the relaying gets performed. A relayed order 21 is one that is received from an external user and passed along to one or more other users. Relayed orders 21 may be passed along either with identification (so the original sender is identified) or without identification (so the order appears to come from only the immediate relaying user).
In addition to basic routing, orders  21 may also be specifically marked up (either by a specified percentage of price or by a specific currency value). This effectively allows trusted intermediaries (brokers) to effortlessly pass along order information (thus creating a larger network and increasing the chance of making a buyer-seller match) while still being compensated for their resources (in this case, the relationship).
Each time an order  21 is passed from a user to another user, its hop count is increased. For example, when an order 21 is sent to an external trusted user, its hop count is 1. If that user relays the order 21 to another set of users, the hop count is 2, and so on. A user issuing a primary order 21 a (FIG. 1) may specify as a constraint/limitation the maximum number of hops allowed. Once the specified maximum hop count is reached for an order 21, even if a relaying user allows orders to be relayed, the order 21 will not be relayed.
in a computer receiving the request package, the processor routine generating rules according to the constraints in the received request package, such that the request packages enable open market trading of goods among users of the computers, each user having at least one other user as a prior established business contact.
2. The apparatus as described in claim 1 wherein a computer receiving a request package has an inventory of the local goods available for selling and the processor routine modifies the rules dependent on the inventory to reflect seller preferences in product availability.
3. The apparatus as described in claim 2 wherein the processor routine in the computer receiving the request package compares the bid to the inventory and attempts to match supply and demand when permitted by the rules.
an interface in a computer sending the request package which allows specification of demand parameters for the desired good and reports back results from a request package traversal of the plurality.
5. The apparatus as described in claim 1 wherein a computer transmits a confirmation package that traverses the exact node path of an originally confirmed request package.
6. The apparatus as described in claim 5 wherein the confirmation package is transmitted for billing purposes.
7. The apparatus as described in claim 1 wherein the constraints are configured independently via an interface on each computer in the plurality.
in a computer receiving the request package, the means for generating and transmitting generating rules according to the constraints in the received request package, such that the request packages enable open market trading of goods among users of the computers, each user having at least one other user as a prior established business contact.
9. The apparatus as described in claim 8 wherein a computer receiving a request package has an inventory of the local goods available for selling and the means for generating and transmitting modifies the rules dependent on the inventory to reflect seller preferences in product availability.
10. The apparatus as described in claim 9 wherein the means for generating and receiving in the computer receiving the request package compares the bid to the inventory and attempts to match supply and demand when permitted by the rules.
interface means in a computer sending the request package which allows specification of demand parameters for the desired good and reports back results from a request package traversal of the plurality.
12. The apparatus as described in claim 8 wherein a computer transmits a confirmation package that traverses the exact node path of an originally confirmed request package.
13. The apparatus as described in claim 12 wherein the confirmation package is transmitted for billing purposes.
14. The apparatus as described in claim 8 wherein the constraints are configured independently via an interface on each computer in the plurality.
generating rules according to the constraints in the received request package in a computer receiving the request package, such that the request packages enable open market trading of goods among users of the computers, each user having at least one other user as a prior established business contact.
16. The method as described in claim 15 wherein a computer receiving a request package has an inventory of the local goods available for selling and the processor routine modifies the rules dependent on the inventory to reflect seller preferences in product availability.
17. The method as described in claim 16 wherein the processor routine in the computer receiving the request package compares the bid to the inventory and attempts to match supply and demand when permitted by the rules.
transmitting a confirmation package for billing purposes that traverses the exact node path of an originally confirmed request package.
20. The method as described in claim 15 wherein the constraints are configured independently via an interface on each computer in the plurality.

References: Application No. 60
 Application No. 60
 Application No. 60
 Application No. 60
 Application No. 60
 Application No. 60