Method and system for grouping merchandise, services and users and for trading merchandise and services

[0001] This application is entitled to the benefit of Provisional Patent Application Ser. No. 60/708,755, originally filed on Aug. 17, 2005.

[0002] This application also contains two copies of CDs, which are identical to each other. It contains the computer source code for the demo algorithm and demo web site. The CD also contains transact-SQL script to re-build the database necessary for running the demos and CSV files that contains the dummy data for the demo database tables. A live demo can be found at http://www.profpro.com/PPA_WEB.

[0003] The CD is compatible with PC and Microsoft Windows/MAC OS/UNIX system. The following directory list is also included on the CD as TOC.txt. This list was generated with DOS dir command.

[0004]

LIST OF ALL FILES ON THIS CD
	Date and Time
	(YY-MM-DD hh:mm) Notes Size(Byte) File (Folder) Name
	---------------+--------+---------+-------------------------
	Directory of F:\USPTO CD
	05-02-15	01:14	<DIR>	.
	05-02-15	01:14	<DIR>	..
	06-02-15	10:25	<DIR>	ASP
	06-02-15	10:27	<DIR>	Matlab
	06-01-15	00:17	37	autorun.inf
	06-01-15	00:29	708	README.html
	06-02-15	11:40	12060	TOC.txt
	3 File(s)	12805	bytes

[0005] Not applicable.

[0006] The apparatus and methods disclosed herein reveal a new e-commerce business model and its possible embodiment in a promising but yet to be developed sector of the Internet Economy. By designing a new infrastructure of e-Commerce, this new model will greatly improve and integrate the current price comparison service with the merchandise trading system. Trading of common merchandise (the term “merchandise” can refer to actual merchandise items or services) is now on a “grouped” basis but no longer on an “instance” basis.

[0007] Firstly, a new encoding method is designed to categorize merchandises into sub-groups and identify each subgroup with a unique Merchandise Group ID (MGID). MGID works like a stock ticker. It enables also categorized subgroups of bidders/askers, who are identified by their User Group IDs (UGID), to put bid/ask offers on the above said merchandise subcategories and to trade merchandise like trading stocks. This invention provides a new infrastructure and interface to connect and organize consumer merchandise, multiple askers (sellers) and multiple potential bidders (buyers).

[0008] Secondly, the new model will create a new marketplace that enable shipping service carriers, such as FedEx, UPS, DHL or USPS, to compete on shipping services in a brand new way. Shipping services are materialized. The shipping service carriers can influence the merchandise market sales by competing on shipping cost for the transportation of merchandise. A lower cost on the shipping service market will boost the transaction on the merchandise market, and vice versa. For this reason, the shipping service carriers will also be referred to as cAsker hereafter. These carriers will be fully integrated and be able to play more active roles in the new trading system.

[0009] Thirdly, the new platform will make the market more transparent for common users (e.g., buyers, sellers, shippers—but can be construed as other users of the merchandise trading system). It provides user-friendly interface and tools to help its users to make reasonable price offers and purchasing decisions much easier than what they have to do now through current existing e-Commerce platforms.

[0010] Lastly, this new business model will also help to reduce or even prevent non-payment fraud.

[0011] The present invention is in the field of doing e-commerce. It groups users (buyers, sellers, shippers) to trade grouped merchandise (merchandise items or services) in the way of trading stocks. It facilitates a better interface between multiple askers (sellers) and multiple bidders (buyers). More specifically, instead of being a pure “auction” platform or a “reverse auction” platform, the model will create a true merchandise “trading” platform. The system makes merchandise market operating like the stock market. It groups its users as well as merchandise and identify each group with a group ID (GID). In addition, the model will provide the shipping service carriers with a larger stage to level in the final merchandise transactions by competing shipping fees with each other in an auction-like manner. All the above mentioned features are integrated thus it make the new trading platform more versatile and flexible than any other prior arts.

[0012] The prior arts (the dominant ways of trading merchandise online) are either an “auction” model such as eBay.com, uBid.com and Amazon.com, or a “reverse auction” model such as Priceline.com. All of the above mentioned models failed to provide means to establish efficient communication channels between multiple askers and multiple bidders. Neither can those prior arts fully integrate shipping into their system. They are confronted with at least one or even several of following problems:

• • [0013] 1) Only asker (seller) can list an item, buyer can't list if there is no seller for that item;
  • [0014] 2) Each single piece of identical products (or services) is repeatedly listed without grouping, resulting in identical (or essentially identical) items listed repeatedly by different users or even by the same user. Users are overwhelmed with pages of repetitive useless information;
  • [0015] 3) Users are lack of the freedom of withdrawing (cancel) their offers even though they have changed their mind before the deal is closed and a contract is bound;
  • [0016] 4) Non-payment fraud that bother the sellers a lot;
  • [0017] 5) Asymmetric information. It is difficult for individual users, especially those inexperienced occasional users, to find the true value of merchandise. They may end up with mis-evaluating the current market price for the listed items. As a result, unless he spends lots of time doing research, inexperienced user may face the risk of buying something overpriced or sell something undervalued;
  • [0018] 6) Users have to jump back and forth among pages to calculate additional expenses such as a shipping and handling (S/H fee), insurance fees, commission fees and tax fees. Furthermore, they may still miss some hidden charges due to the fact that the prior arts do not provide users with the “Total Final” cost (for buyer) or profit (for seller). Users may end up with engaging in a disadvantaged trade based on the above said incomplete information;
  • [0019] 7) Carriers (shipping service providers) do not play a strong and active role in the trading system (game) as they should. They exist rather as passive and supportive players. In fact, change in prices of shipping services would have great effect on merchandise trading. In fact, the shippers are not offered the opportunity to bid on shipping arrangements. The prior arts fail to provide the shipping carriers with the platform that the current invention will offer;
  • [0020] 8) All prior arts are static. They do not use the full extent of today's computer power and database technology. As a result, they fail to provide an efficient dynamic trading platform that can reflect the market in real time.
  • [0021] 9) Users' contact information is not hidden to their counterparties, so they might contact and make deals outside of the server thus make service provider sites lose their income.
  • [0022] 10) Sellers can cheat in many ways. He can cheat on price by bidding his own items. He can also cheat on his rating by selling item to himself while without shipping out, after which he can leave himself positive rating and feedback.

[0023] To address all of these shortcomings of those prior arts, the present invention disclosed herein has the following objectives and advantages:

[0024] This new system is a real real-time “trading” platform but not just limited to an ‘auction’ platform nor a “reverse auction” platform. Merchandise would be grouped by MGID (PID plus other properties) and traded in this system freely like trading stocks at stock exchange. All involved users of the system will also be grouped and then matched to their counterparties who can accept each other. It will greatly improve the logistic and exchanging of both new and used merchandise; it will benefit the manufactures, shipping carriers, sellers and its end users.

[0025] A more detailed and universal information about merchandise and the market will be revealed to users for them to browse, search, compare and to make their decision of purchasing.

[0026] No more repeatedly listed items. All identical/similar instances of products will be combined into one group. This will enable multiple bidders/askers to bid/ask on the merchandise more easily. For each product (PID), offers from all users will first be grouped by MGID/BGID/AGID/CGID into subgroups of candidate offers list by prescreening with introducer routine which would be mentioned in the following text. Within subgroup offers of each PID, offers are compared against each other within the group and sorted by their final gap in prices and in other parameters such as total value of orders, time of offers, etc. Sorted offer queue are then be converted to orders which will bind a contract between the asker (seller), bidder (buyer) and carrier (shipper/cAsker).

[0027] When matched offers are found, a deal is made. The transaction can be cleared via common payment method, such as credit cards, wiring, e-check, check or other 3rd party payment services. Payment process should follow the agreement they reached during the bid/ask offers.

[0028] Transaction can be first secured by optionally downpaying a portion of the full payment. This amount would be a fixed amount or a certain percentage of the total. Payment should be cleared later in full payment using the above mentioned payment method. This deposit would benefit both seller and buyer.

[0029] Bidder and askers bear no obligations on making/modifying/canceling their offers as long as at that time there is no matched deal and the contract is not generated in the trading system. They would therefore be offered the full freedom of entering and leaving the market anytime they want.

[0030] Users would have more tools on making their offers, such as by using “market order”, “limit order”, “stop order”. Like those in the stock market. By using the market order, the user is guaranteed to get the current best deal available without bothering to do any research and price comparison. He can also use some scored “percentage price” to avoid offering too much while keep himself a good position of winning the deal.

[0031] Bidders can provide sufficient fund to cover partial of the full payment of their bid and authorize to pay the rest to payees right after the deal reached. By paying this security deposit, these bidders are given a special tag by the system, which would be reflected in their BGID. These buyers then can get a higher chance of wining the bid over other bidders who don't provide pre-located deposit funds. This deposit payment also benefits the asker by reducing their risk of non-payment bidders. Askers can adjust their preference of their acceptable risk level and then modify the weight of this priority.

[0032] The new system is a dynamic open system where the bid/ask price are no longer constant nor monotonically rising or falling. Instead, the price of certain merchandise can fluctuate up and down like what happens in a stock exchange. The price change reflects the real market value on the fly.

[0033] The user can even customize the exercise (execution) time of the transactions to a later time so to get it at a lower cost. They can even bid on some rain checks or coupons like options. This makes people can trade regular merchandise as trading options in the financial market.

[0034] Calculate Shipping Handling Fee automatically and dynamically. Driven by database engine, all related fees can be calculated and included automatically in the final offer price. Thus users can make their comparison based on the real cost. Users don't need to find out and calc the hidden fees themselves. This makes our merchandise market place more user-friendly and fair to everyone.

[0035] By involving the carriers into the trading system as independent game players, our platform makes it more difficult for the sellers (askers) to cheat on their feedback rating. Because they can no longer sell items to themselves without shipping it out. They now have to pay the real carriers plus commission. If he doesn't ship items out, he will get bad rating from both our system and the carriers, which will result in degrading their AGID_key (rating as an asker).

[0036] At the same time of benefiting the bidders and askers of the merchandise market, the shipping dynamic calculation also creates a new online market of shipping services for all carriers. At this shipping service market, they can compete on the shipping fee for predefined grouped shipping service.

[0037] This invention also benefits the manufactures or service providers whose products (such as a computer, car, furniture, tickets) or services (such as travel package, service packages, etc) have lots of customizable features. Based on this trading platform, any manufacture can establish its own direct sale system very easily.

[0038] Establish an algorithm to match bid/ask offers not solely based on price difference, but also matching more generally by the bidder/asker/carrier's grouping information and by other information such as previous trading behaviors and feedback rating. The ranking system takes into consideration not only their counter party's feedback but also the statistics from the trading server. The ranking will reflect itself in the user or merchandise's GIDs. GID is assigned to users and maintained by the system server. For these reasons, our system can help user to find whatever they want more precisely and more easily.

[0039] It is a 24/7 fulltime and global market place. The market is always open and never close. There is neither New York Exchange nor London Exchange, the market use one timing system and time zone independent.

[0040] There will be no ending time of a listed item. As long as there is recent trade/offer on that item, it is considered active and won't be removed.

[0041] Last trading information (price and volume etc.) for each item can be provide in the format of charts, figures, tables or streamers to the users for further references. Other statistic info, trends and analysis may also be provided.

[0042] A certain amount of service fee might be taken from the involved parties of the transaction. It can from the either the asker, bidder or both sides. The charge could be a fixed amount or a percentage of the total transaction. The charge will also be included and reflected in the real final price.

[0043] An integrated, multi-criteria, double-ranked, and following-up rating system are used. This new rating system can reflect the users' opinions on merchandise or their counter parties much better than current rating system.

[0044] The soul of merchandise trading is to build efficient interaction gateways between all the involved parties, namely: merchandise, askers, bidders, and cAskers (shipment carriers). As shown in FIG. 1A01, there are at least four components in the business chain. Merchandise flows from sellers to buyers via shipping carriers. Each of the four parties is essential for making a transaction go through. Furthermore, although every instance of merchandise (and user) has their unique properties, they all have something in common at the population level, by which they can be categorized into certain groups. Accordingly, the objectives and advantages of the current invention are to establish a new commercial infrastructure that provides sufficient ways to organize the trading transactions by grouping and matching.

[0045] Our new infrastructure, instead of trading each instance of merchandise between an instance bidder and an instance asker, trades grouped merchandise between grouped bidders and grouped askers. In addition, the new platform will enable the grouped shipping service carriers to get involved as an independent player to fulfill the final transaction. The invention will change the current “static instance trading” models into a “dynamic group trading” platform.

[0046] The current invention would fulfill our goals by:

[0047] 1) Categorizing and grouping merchandise and services for easier browsing, searching and comparison;

[0048] 2) Grouping users (bidders/askers/cAskers) into different asker/bidder/carrier categories by evaluating their common properties, qualifications, and their trading behavior history. The evaluation results can then be used as fingerprints (grouping criterion) of that user group, and will be further encoded (integrated) and used for the bidder/asker/cAsker categorization (grouping). All instances within one subgroup can eventually be considered as identical regarding to those grouping criteria.

[0049] 3) Calculating Shipping Handling Fee automatically and dynamically. Driven by database engine, the new invention will automatically reflect the related shipping service fees in the final offer price. By providing the real final costs to buyers and final profit to sellers, the new invention makes the merchandise market place more transparent, convenient, users friendly and fair.

[0050] 4) At the same time of benefiting the bidders and askers, the new invention also creates a market of shipping services where shipping carriers can compete on the shipping fees against their peers by bidding for a certain grouped shipping service. In some countries, like USA, the law requires bigger shipping carriers to maintain same rates to all customers and be post on a tariff to limit their liability. These carriers' offers can be obtained by retrieving their real-time quotes through their current existing API, Web Services or other third party Web Services. The returned quote can then be used as their “bidding”. The dynamics provided here will enable the carriers' leverage on the deal-matching between askers and bidders when carriers' rate changes. It can enable carriers compete against each other, as well as letting local small carriers or courier service's to compete with major carriers.

[0051] 5) The new invention benefits manufactures and service providers. Products (such as a car, computer, furniture, air plane ticket) and services (such as travel package or room services) have lots of features that can be customized. Based on this platform, any manufacture or service provider can build its own direct sale system for their predefined and categorized product/service very easily.

[0052] 6) Automatically calculating all fees. Include SH fees, tax and commissions into costs to provide the bidder/asker the real FINAL cost/profit. Thus the users can make comparison based on the real price without the need of putting extra effort in calculating on their own. In addition, they no longer have the risk of make wrong purchasing decision because of the failure of revealing some hidden charges. This feature benefits all users (asker/bidder/carrier) who are unfamiliar with the market

[0053] 7) Price is only one of the factors that lead to a purchase transaction. Other factors such as creditability are also essential. People don't like to do business with bad counterparty even their offered price is better. This invention establishes an algorithm to match bid/ask offers not solely based on price differences but also on the bidder/asker/carrier's grouping information. Grouping information reflects its group members' common properties such as their location, method of payment, previous trading behaviors, feedback ratings left by their counterparty and statistics rating from the trading system. The new trading system matches the user groups first, pool those matched groups of users who are willing to deal with each other together, and then perform the price match within the matched groups. This ranking/grouping system helps to convert individual “instances” to “groups” and make the matching more efficient.

[0054] 8) By providing a deposit (down payment) option in the payment parts, the new platform benefits both askers and bidders. Bidder who pays higher percentage of deposit gets better position in the matching queue. Payees can lower their risk of losing money from non-payers, while payers can increase their chance of wining the bid.

[0055] 9) Users will have more freedom by put their offer by using “market order”, “limit order”, “stop order” like those used in stock trading nowadays. Users are free to withdraw their offer any time before a deal is reached and contract is generated.

[0056] 10) User will have more freedom on and control over the practice (execution) time of their order transaction like trading options and futures on financial market. By choosing a future execution time of their offer, they can get better price on the same item than acquire the delivery right away. This kind of order will also help the manufactures or service providers to schedule their production plans well ahead of time.

[0057] 11) Basically, unlike eBay or any other current auction service sites, there is no time limit for a listing, as long as there are trading activities on it. However, if an item has been inactive (which means there has been no order transaction or even no new bid/ask offers) for a period of time (for example, two months), the item will be removed from the listings (the user can re-list it again though). The new trading mechanism will also differ from the current stock/future exchange because what is being traded is real commodity merchandise and the trading service is 24 hr by 7 day (so there is neither market open nor market close). The users can place offers anytime. The server will use relative timing (to current) as its system timing. For example: the system will record timing like “This merchandise was last traded 36 minutes ago and a new bid offer for it was received 10 minutes ago”. In this way, the server time can become a globalize time standard, and our international users at different location do not need to worry about calculate the time zone.

[0058] 12) Benefit from the grouping technology, all grouped users will interact with their counterparties as a member from a certain user group. This will give our trading server the option and ability to hide the identity of each individual user, so to prevent/reduce their direct communications that bypasses our server, which will hurt income.

[0059] 13) Compared with the ungrouped data/information, grouped info will result in a smaller page size at the server end. This can reduce both the server's load and network bandwidth requirement to communicate between the server and client terminals. This will further lead to at least three benefits: fasten the data transmission of current users, and bring new users from lower-speed connections (such as dial-up) from other application/protocols such as WAP (WML) and from devices with limited display ability (such as cell phone).

[0060] 14) Due to the facts of using merchandise's group ID (MGID) and no limit of listing time, it saves lots of users' homework to input/read the description of the listed item. For example, if someone is going to sell some thing that already had been listed by others, he can simply refer to that group ID (such as by its UPC bar code) without the pain of re-entering all information regarding that item again. Same for buyer.

[0061] 15) Since the shipping is chosen and performed by carriers independently, it would be difficult and costly for the sellers to cheating on price by bidding his own listing, or to cheat the feedback rating by selling item to themselves without really mailing it out.

[0062] 16) Grouped users and information are often more attractive to their counterparties. The invention can generate “wholesale” transaction from “retail” transactions by organizing and combine individual asker/bidder/cAsker into corresponding user groups.

[0091] FIG. 1A. Illustration of the trading system's framework. Illustrate the function and component of the trading system embodiment. Top(1A01): System function: for a merchandise to arrive to the end consumer, there must be a seller and a shipping service carrier to connect them. Bottom panel (1A02). System structure: the platform server consists of database and database server, central application server and interface server (such as web server) with proper security protections. Each knot of the server can be one computer or a group of computers. Users (asker/bidder/carrier) can communicate with central server via internet or other network such as cable network, satellite network, telephone network, etc. User can use a variety of client interface terminals such as computer, phones, PDA or interactive TV. Detail of the four sub-database component is illustrated in FIG. 1B.

[0092] FIG. 1B. Illustration of database relationship. Show the sample of key component tables and mutual relationship of the merchandise database, user database, offer/order database and shipping package database. Each database consists of several tables that interact with each other and with other databases. Shiping_package_selector routine will be used to map a MGID to an appropriate packing method thus make a link between these two databases. “AM” means Acceptance Mask. Screenshot follows MS-Acess conventions, such as bold fields are primary keys.

[0093] FIG. 2. Sample property page used for merchandise categorization. Merchandise properties are grouped into columns of option lists. There are simple property selection columns (with only one column) and complex selection columns (with more than one column, as framed in the grey background box). Those Applicable items of the property options list are checked.

[0094] FIG. 3. sample property page of asker(seller) categorization

[0095] FIG. 4. sample property page of bidder(buyer) categorization

[0096] FIG. 5A. flowchart of procedure to encode property page into GID. Encoder routine is as illustrated in FIG. 5B. Auto-upgrade routine is shown in FIG. 6.

[0097] FIG. 5B. Demo of two algorithms for the encoder routine. Demonstrate encoding property page into GID with two types of encoder. Encoder 1 just lists the selected options within each column section. Encoder 2 will use 0 to stand for unchecked options and 1 for checked options. By list all checked and unchecked options, encoder 2 can handle more detailed information and would be especially useful when more than one option are applicable within a single section. GID generated by encoder 2 will allow later matching between key and acceptance mask. Encoder 1 is simpler, but can only handle single selection properties.

[0098] FIG. 6. GID's Exact Match vs. Auto Upgrade. When encoder generates GID from property pages, it can use either Exact Match or Auto Upgrade. Exact match is using the options directly. When encoding the property page of requirement, user can use Auto upgrade. It will automatically add other matched options before doing the encoding. For example, 61, 62, 63, 64 are four columns of property page. 61 is look for something with 3-star rating. By auto upgrade, both 4-star and 5-star are added. Item without any rating may also be added according to user's preference. 62 require a USPS delivery, and when using auto upgraded, FedEx is also acceptable. Same for 64 where seller requires a 50% deposit. By auto upgrade, full payment also be added to the acceptance list. Auto upgrade routine is smart, it will not add something inappropriate, such as since 63 is looking for something that is antique, it will keep that way. The upgraded property page is always subject to user's review, modification and confirm before being encoded into GID.

[0099] FIG. 7. Matching between Key and Acceptance Mask. Illustrate how Introducer matches user parties. Keys, the GID of provider, are those white boxes. Acceptance Masks, GID of receiver, are those gray boxes. Arrows show matched pair of Key and Acceptance mask. And a cross mark show failed match. Introducer routine uses Bitwise AND operation on each GID section. Only when result of all GID sections are non-zero, the records could be considered matched. Otherwise, any zero result of any GID section will fail the match. Top (701) is a matched pair because all three GID sections are matched. Middle (702) failed because the 2nd section (MGID) failed to match. Bottom (703) also failed because its 2nd section (MGID) fails to match.

[0100] FIG. 8A. Total fees, final price and gap. Whether the deal can go through not only depend on the asker's priceAsk and bidder's priceBid, it also depends on extra fees such as shipping and handling fee, tax, etc, which make the real total fee. When an asker asks for a priceAsk, the bidder need to pay the priceAsk plus the above said real total fee. And the final bidding price for the asker should be the priceBid minus the real total fee. The equation for the gap is at the bottom of the page. SH: Shipping & Handling fee; TC: Tax & Commissions; O: Other fees.

[0101] FIG. 8B. fee_calculation routine which based on database tables. It could be a lookup table, a fixed rate or some routine. Its input would be the askID, bidID and merchandise's GID. Its output is the total fees such as shipping and handling fee. Etc.

[0102] FIG. 9. Grouping merchandise and users by GIDs. It shows grouping of merchandise, bidders and askers. Clouds of askers/bidders/merchandise instances (identified by askerID/bidderID/MID) now have been grouped to asker/bidder/merchandise groups. So the interaction between individual seller, individual buyer and individual merchandise has been changed into interaction between grouped sellers, grouped buyers and grouped merchandise. Groups are represented by different symbols in the figure. For the MGID, the first two sections (012345678905-1) identify the merchandise by a bar code and image code. The rest part (****) is used to define further subgroups. In this sample case, all bidders are divided into 3 bidder groups, and all askers are divided into 2 asker groups. Pre-filtering by an introducer routine is performed at the group level before doing any deal matching at the instance level.

[0103] FIG. 10. Competing and peers. FIG. 10 shows how bidders compete with other peer bidders. Given the following scenario: There are three bidders (1011,1012,1013) on the market bidding for same item from two askers (1001,1002). Bidder 1011 offers $16.00 for it, and the offer would show at both askers. He has two peers (1012,1013) at asker 1001's list. At asker 1002, because the GID mask and key matching reason, only bidder 1013 is left to compete with 1011. Notice the SH are all different due to different asker/bidder locations and other properties. At asker 1001, bidder 1012 has the highest Final bid, which is 13.25 (1022). To bidder 1011, this means he has to place a bid of 13.25+4.25=$17.50 to over bid bidder 1012 from asker 1001. For the same reason, at asker 1002, the highest final bid would be 14+3=$17.00. So the highest bid on the whole market for Bidder 1011 would be equivalent to $17.5. Which is $1.50 above the bidder 1011's current $16.00 offer.

[0104] FIG. 11. Threshold. Illustrate how the number of potential deals depends on the price of ask. The lower the asker's priceAsk, the more the number of potential bidders can meet that price. By tools that provide such information, the asker will be able to make better decision of if he should decrease the priceAsk to increase volume, thus to increase the total dollars of sales.

[0105] FIG. 12. Demo interface in front of a bidder (buyer). Show a demo interface the bidder may see from computer screen. The top box shows merchandise the bidder is looking for, the asker (seller)'s information and the shipping information. It also contains link to other information pages and buttons that allow bidder to modify the acceptance mask of the merchandise/asker/cAsker (1201,1202,1203,1204). The middle box will hold information from the bidder himself. Left side is the bidder's BGID, and right side is the shipping information needed for the shipping carriers to calculate the shipping cost and for tax calculation. There are buttons that allow bidder to change the BGID (1205) and shipping location (1206). The bottom area contains statistics number/table/chart for the item watched, and also the bidder's action and current auction status (position). This part also contains link and buttons that lead to other further pages.

[0106] FIG. 13. Demo interface of bidder, of FIG. 12 continued. This figure shows those pages where the bidder of FIG. 12 will see after the bidder click the buttons on FIG. 12. Box 1301 is the web page a bidder will see when he click button 1201 in FIG. 12. This box will let user to search and identify the item he wants by select a universal bar code and the merchandise's image (or image group). Box 1302 is the web page bidder will see when he click button 1202 in FIG. 12. This box will let user to modify the merchandise's acceptable condition/status that he is willing to buy. Box 1303 is the web page a bidder will see when he click button 1203 in FIG. 12. This box will let user to determine the sellers from whom he is willing to purchase from. Box 1304 is the web page a bidder will see when he click button 1204 in FIG. 12. This box will let user to set the requirement for the shipping/delivery service. Box 1305 is the web page bidder will see when he click button 1205 in FIG. 12. This box will let user to modify his own information of payment as a bidder. Please notice information on the left side (circled by doted line) is from system statistics result and can't be change by bidder. Bidder can modify the right side within the box for which method and how much deposit he would like to pay where radio button is provided thus let the bidder to make selections. After finished reviewing and modify the information in the above web page, the bidder can confirm and return to main interface web page shown in FIG. 12.

[0107] FIG. 14. Gap price formula showing two ways the shipping carriers (and other roles) can involve themselves in the merchandise trading. Shipping carriers can do their business on the platform in two ways. (1) the new way: They can create a new cAsk offer queue which offer the cost of shipping for all possible deal between each bidder and asker pair. This is illustrated at the top. (2) the old way: They don't need to put any cAsk offer. Instead, they can list their service and fee in a lookup table or even provided a flat rate. In this case, the shipping fee would be included as part of the total-fee returned by another fee_calculator routine. This is illustrated at the bottom. Database tables are from offer/order sub-database, which is illustrated in FIGS. 1A & 1B.

[0108] FIG. 15. Pre-filtering of large list of candidate offers by SQL command. This can reduce the queue size be removing unqualified offers before going forward to do deal match.

[0109] FIG. 16. screen snapshot from the demo website pages “Default.aspx”

[0110] FIG. 17. screen snapshot from the demo website pages “Asks.aspx”

[0111] FIG. 18. screen snapshot from the demo website pages “Bids.aspx”

[0112] FIG. 19. screen snapshot from the demo website pages “cAsks.aspx”

[0113] FIG. 20. screen snapshot from the demo website pages “product.aspx”

[0114] FIG. 21. screen snapshot from the demo website pages “add_new_product.aspx”

[0115] FIG. 22. screen snapshot from the demo website pages “GID_Encoder.aspx”

[0116] FIG. 23. screen snapshot from the demo website pages “offerMatcher.aspx”

[0117] FIG. 24. screen snapshot from the demo website pages “admin.aspx”

[0118] FIG. 25. screen snapshot from the demo website pages “packingMethodSelector.aspx”

[0119] Our invention will do the following things: group users and merchandise, identify each group by assigning a group ID (GID), matching GIDs to “pool” together counterparties who are interested to each other, calculate the real final price within each “pool”, do the price match within previously matched groups. Now we will describe them below:

User Grouping and UGID

[0120] All users will be individually identified by a User ID (UID). UID are given to them when they register. The UID allows them to uniquely identify themselves, authenticate themselves and login in to the trading system server.

[0121] User roles of our platform would be the Asker (merchandise sellers), Bidder (merchandise buyer) and CAsker (or Carrier, refer to a package shipper agency). One user can have different roles such as being an asker, bidder, carrier or any combination of them. Then they are categorized into corresponding bidder/asker/carrier groups, and will be further assigned a User Group ID (UGID). These UGID will then be an Asker Group ID (AGID), Buyer Group ID (BGID) or Carrier Group ID (CGID) according to the user's role. The UGID is automatically assigned to a user, linked with his UID and maintained by the trading system when the user picks his role. It represents the grouping information for a user (as asker/bidder/carrier). The grouping information could be but not limited to permission/priority and counterparty feedback. This grouping information could reflect user membership levels, location (Zip code), payment methods and also based on statistics ratings of their previous transaction history, which including number of transaction, total sales, average unit prices per sale, etc. Property pages that define an AGID are different from that to define BGID. AGID page have fields related to sellers' warranty while BGID page has fields related to buyers' payment method. Demo of property page contains AGID and BGID components are illustrated in FIG. 3 and FIG. 4. CGID pages for cAsker (carrier) would be much simpler; it would be a list of properties of the shipping service it can provide, such as shipping methods, packing method, time of delivery, tracking availability, drop-off box, local service store info, etc.

Merchandise Grouping and MGID

[0122] Although each instance of merchandise is assigned with a Merchandise ID (MID) after been added into the trading system as individual, they are usually searched and matched by their category. When someone is searching for an item, it is not necessary to be that specific instance of item but rather the utility and properties provided by that item group (subgroup). For an example, one is looking for a 27 Apex Flat TV, one don't care about its serial number and who sell it, as long as the TV set he get can provide the functions and warranty he needs. For example, new TV sets with the same UPC bar code and carry same guarantee from manufactures and sellers. Thus, all TV sets instance that meet the user's requirement on the market from different sellers will be combined into one group of candidate TV group. All TV instance inside this group in eventually identical and they will compete against each other by other properties.

[0123] Merchandise will be grouped by Merchandise Grouping IDs (MGID). MGID is not simply a UPC bar code or ISBN. It describes NOT only what product the merchandise is, but also other extra information such as its image, status, consumer feedback (from our server or other 3rd party reviewer's site), warranty it carries, packing information, bulk information, delivery information, etc.

[0124] MGID is composed of several sections where each section contains variable length of detailed itemized properties.

[0125] The first section is the items universal (global) bar code and an image code used to identify the product. Bar codes could be an International Standard Serial Number (ISSN), International Article Number (EAC), UPC bar code or ISBN. Image code is a code refers to merchandise image or images group in case different items had the same SN in section one. (This should seldom likely to happen if their first section is from official global Series number. But sometime, for items that don't have any well accepted bar code, some customaries serial number (such as a store code plus the SKU number of the item in that store, or model number) could also be used by the website. Thus, we need the image code id to identify what product the merchandise is). User will choose the image or the group of images (show different specification of the same product) that best describe the product. This first section of the MGID (bar code plus image code) will be also referred to as Product ID (PID) in later part of this application.

[0126] The rest sections of MGID and option list within them will depend on the PID (MGID's first section, means bar code and image code). Different product would be described and categorized by different key features. After the item is identified by PID, the rest sections will describe, in an itemized way, its other key features that a bidder and asker ought to know. Such as for a wine, it will state where and when it is produced yet for a piece of furniture it would be its materials and dimensions. Basically, they would include the status, product ratings, packing information, delivery requirement, etc. Different item may have totally different list of properties fields to encode their MGID. A sample property page of MGID is illustrated in FIG. 2. Those columns related to delivery requirement may also be separated out from the MGID page as an independent carriers property page, which defines a CGID as Acceptance mask, which we will address in our later text.

[0127] In the above TV case, the PID (first section of MGID) will make sure the buyer get the type of TV he want, and the rest part of the MGID will be used to filtering and grouping all TV instance of the chosen PID on the whole market place. In brief, all merchandise with the SAME PID (same products) can be further divided into subgroups of the product by their MGID. MGID would identify all items with both same PID and same properties or status.

[0128] MGID can also be used to describe single piece of specific items instance when only one piece of instance can be categorized into that certain group. It happens for antique art collections. In this case, each asker (seller) already have been issued an unique askerID in our system, he can then issue a unique SKU ID number for that collection in his warehouse. The combination of the askerID and this SKU ID can be used as the MGID. When the bidder bid on this combined MGID, only one piece from the whole market can match all criteria since the askerID is unique, and the SKU ID is also unique for all items from that unique asker (seller).

[0129] Almost all services can also be traded as a regular merchandise by assigning the service with a MID and MGID. Services can be anything. They can be Internet ISP or CSP, cable/satellite TV program, room service, house keeping, repair, delivery, cell phone plan, travel package, vacation package, tour guide, designer, catering, dancer, convention receptions, ticket for movie/show/sports, advertisement, photograph or video service, music band, training courses, yoga program, insurance plan, consulting service (like law or financial), personal service such as hair, beauty, nutritionist, massage and bodyguard services, etc. As long as the service can be fully described by a list of itemized properties, the service provider can then register himself as an asker to sell the service to end consumers. One very special service among all these is the shipping (delivery) service provided by the shipping carriers. Almost every merchandise trading requires a shipping service to go through. The asker of the shipping service is called CAsker throughout this application.

GID Encoder

[0130] After the itemized property pages are defined, an encoder routine is used to encode those properties into GID (MGID and UGID) code. The GID will be used to category instance (user/merchandise) into groups and identify each group. There are lots of ways to encode the grouping information into a code. We will just list 2 of them as example.

[0131] FIG. 5 is a brief version of FIG. 2 (MGID) to show encoding of a MGID. Besides the SN, it has 4 simple selection columns (51, 52, 53 and 54) and one complex selection column (55). Each column has its lists of options. We can encode the item in FIG. 5 by either one of the follow two methods:

• • [0132] 1) Combining the index of selected options in each column. Since the first option in column 5A is selected, the code would be 1. Since the 3rd option is selected in column 2, the code for 2nd column would be 3. In this case, because the 511, 523, 531, 541, 5512 and 5523 are selected, the grouping code would be 131123.
  • [0133] 2) Listing all options within each column section, in a section by section order through the whole property page. In this case, the information is totally 3+6+4+8+7+6=34 bits in 6 sections. Assign value “I” for each selected option for each unselected option. You then get a series of “0”s and “1”s in 6 blocks. In this example, its binary code is 100-001000-1000-10000000-0100000-001000. (You can further convert these blocks of code regardless the sections info into other base for display purpose. Such as 211100808 in HEX, or 8876197896 in DEC, etc.) This above code would take 34 bit, or 6 bytes to save and will be used for bitwise operation in the later stages for finding matched groups.

[0134] Both encoding methods have their own usages, which we will refer to later in the following part of this application. Now we just follow the first encoding convention as an example: If the item's UPC code is 012345678905, then the MGID for the merchandise is 012345678905-1-31123. This MGID uniquely identify all merchandise with bar code as 012345678905 and image code as 1, and rest part of MGID as 31123 which means it have a 4 star rating, and in new conditions and price is in USD and will be delivered by UPS in 3-5 days. 012345678905-1 is also called PID as we said earlier. Thus all product with same PID can be divided into some smaller subgroups by the rest part of the MGID. Items within each subgroup are considered identical.

[0135] Similar method also applies to the encoding of user (asker/bidder/carrier)'s UGID (AGID/BGID/CGID).

Auto Upgrade of GID

[0136] The first encoding method seems simpler, but it is not powerful and convenient enough when there is more than one option applicable within a single column section. Let's consider the following situation: a bidder is searching for something without any bad user review. The example is illustrated in FIG. 6. In this case, bidder can auto upgrade the GOD's property page by add all options better than what the bidder would accepted in the option lists and then use the 2nd method for encoding. Figure's Top: The bidder is looking for an item with review-feedback better than 3 out of 5 (61), and would accept USPS for the shipment (62). The binary grouping code for this requirement is 001000-0100. What the Auto Upgrade routine does is to reject rating lower than 3 but adding rating 5, 4 and those with no rating (65); And in the delivery section, it will add FedEx to the option (66), since FedEx is assumed better than USPS. After the auto upgrade, radio buttons would be converted to check boxes, and property page will be refreshed for user to review, modify and confirm before going forward.

[0137] The 2nd encoding method would be perfect for this multiple selections situation. Now the new GID code would become 1110001-1100. The auto-upgrade routine is smart and making sense. It will not add “New” option to MGID if the thing being looked for is antique stuff, see FIG. 6 middle panel (63, 67). Same thing can also apply to upgrade and encoding a user GID, for example FIG. 6 bottom (64), a asker require the bidder pay 50% as deposit right after the deal match, of course that it should be welcome if the bidder will pay in full (68). For a scenario, a user is looking for a tickets for a show or travel or reserve an diner table, he choose his most preferred time to be 6 PM and set a time window of 2 hours, the auto-upgrade routine will put all tickets from 4 pm-8 pm on this users list.

Key, Acceptance Mask and Introducer Routine

[0138] Key is a GID where each of its sections contains only one selected options. Key is used to describe the precise properties that a merchandise or user can provide. Acceptance Mask is a GID that allows one or multiple options to be selected during one section. An Acceptance Mask is used to describe the range of properties the receiver can accept. Transaction provider/receiver can use the GID either as a Key or as an Acceptance Mask, respectively, to match each other. Receiver, the party that looks for something (merchandise, service or payment) from a transaction, can use the related GID as Acceptance Mask. But provider, the party who gives out the merchandise, service or payment, can only use the corresponding GID as Key. Acceptance Mask are used to find qualified candidate Keys in later stages of processing. In a transaction: for merchandise related properties, the bidder is receiver, for payment related thing, the asker is receiver; for shipment related thing, carrier is the provider of the shipping service and both asker and bidder are receivers. When a bidder is look for something, he will define a MGID mask and an AGID mask. These Acceptance Masks are used to find the merchandise he is interested and the askers (seller) he would like to get that merchandise from. He will also use his assigned BGID as Key to identify himself and to match the BGID mask the asker (seller) defined. As to the asker, he will use MGID and AGID as Keys to identify the merchandise and himself and to match bidder's Acceptance Masks. The asker also defines a BGID Acceptance Mask to filter bidder's BGID Keys. When carriers are involved, carriers would provide CGID Keys to identify their service, and both asker and bidder will define their own CGID Acceptance Masks to define their requirement for the shipping/carriers. In some cases, carriers may also define AGID mask or BGID mask to select/avoid certain asker/bidder. Carriers may also define MGID mask to define merchandise he would like to ship. Refer to fields of tables of user database in FIG. 1B.

[0139] One asker may want sell products only to certain groups of bidders. Bidders may also want to buy products from only limited asker group. All these needs can be satisfied with prescreening by comparing the Keys against Acceptance Masks (both are derived from GID). Asker find bidders, who would like to buy stuff from him, by using his AGID as Key to match the bidders' Acceptance Masks generated from bidders' required AGIDs. Asker also find bidders, who are interested in the merchandise he sells, by using the MGID as Key to match bidder's required Acceptance Masks of merchandise (MGIDs). Bidder also find askers, who would like to sell stuff to him, by using his BGID as Key to match askers Acceptance Masks generated from askers' required BGIDs. An example scenario is shown in FIG. 7. A 5-star-rated asker is trying to sell brand new merchandise to bidders rated at least 3-star. And a 4-star-rated bidder is looking for the same item of MINT condition from asker with over 4-star feedback. The top panel of FIG. 7 (701) shows how they can find each other by defining and matching the corresponding GID Acceptance Masks and Keys.

[0140] When an offer is placed, the system will load the Key and Acceptance Mask (AM), according to the user's role, from the user database as default value. For example, when a user sells something, the server will use the information in tbl_asker to define his property as a seller (AGID_key) and set the requirement for desired buyers (BGID_asker_AM) and shipping service providers (CGID_asker_AM). The user can modify the default values for that specific offer so he can customaries his warranty and counterparty's restriction for each offer. Refer to FIG. 1B.

[0141] Introducer is the server routine used to do prescreening to find matched GIDs using Bitwise AND operation (such as ‘&’ in C++). It compares Keys against Acceptance Masks bit by bit and then section by section. Within each single section, if the Bitwise AND result is non-zero, that section is matched. Only when the Bitwise AND results are non-zero for all of those sections (in this case their product would be non-zero), the overall result is considered a match, otherwise it failed. Since only one bit within each GID Key section could be “1” (the bit that represent the exact certain property), introducer (prescreener) can also just check that bit of section of the Acceptance Mask.

[0142] In FIG. 7, the top (701) has three sections: AGID, MGID and BGID. The bitwise AND results of these sections are 100000, 1000 and 010000, all of which are non-zero. So it is matched. The middle panel of FIG. 7 (702) is fail to match since the item for sale is used so the bitwise and for that section (MGID) is 0000. The User could decide if they like to use Exact Match or Auto Upgrade. The bottom (703) failed to match because the bidder does not use Auto Upgrade option for merchandise's MGID. Some restriction may apply while matching the mask and keys, such as if a “local pick up” option is chosen, the bidder and asker preferred have the adjacent locations judged by their zip code. Other wise it will not consider a match and give a warning notify to the users and require them to modify the options on the property pages.

[0143] By matching with GIDs, all users can be grouped and revealed to their counter parity by the GID of that user group. This could help to keep users anonymous from their counter parties. This approach will also help to protect server's income from commission.

Bidding, Asking and Lazy Traders

[0144] Offers of ask/bid on merchandise are submitted by askers/bidders independently, offer of asking shipping fees are submitted by, or quoted from, shipping carriers. These offers are received by server and save in database as tbl_asks, tbl_bids and tbl_cAsks. The offer from asker and bidder will contain MID, price and trading volume (quantity). The offer from carrier will contain package information which defined by the shipping requirement of the merchandise and quantity, locations of loading (pickup) and delivery (destination), and an asking prices, or quote, of shipping fee from different carriers. Major carriers in US do not do price match with their competitors, nor do they change their freight rates frequently (usually on a monthly basis by change of fuel surcharge). They are also required to provide same rate to all its customers to limit their liability down. This slow change and the “flat rate across customers” rules enable us to buffer their quote for each type of potential packages into a shipping fee database table. We can then provide a real-time-like quoting by query from our own buffered shipping database, provided that we use some routines to update the quotes in that database table from carriers at a regular basis (for example, every 15 minutes). This buffering approach will greatly speed up the shipping fee quoting and reduce the load and network traffic at the carriers' API server sides.

[0145] Bidder can choose a certain percentage of the offer, or a fixed amount of money, to be paid as down payment right after the deal is reached to secure the deal. To use this feature, the user is suggested to setup an account at our server. He must have sufficient pre-located fund or have valid credit card limit (pass credit check) linked to that account in order to cover the down payment of his current offers. Amount of this immediate down payment offer is also encode in the bidder's GID thus may increase his chance of wining the bid by giving him higher priority in the queue of offers. For a seller, he might want to require such feature to reduce the risk of meeting non-payment user.

[0146] Offers from asker/bidder can have other options like “all or none” if the quantity is greater than one. User can set his offering price by putting a “limit order”, “stop order” or “market order” at the server. The server will in charge of convert them into real offer at market time when the market price meets the user's preset requirement. This part of process could be done by modifying those arts performed in the stock trading industry. For example, a “market order” would take, for a bidder, the lowest asking price and, for an asker, the highest bidding price. Order with order volume greater than one will be converted into sub-orders with smaller volume unless “All-Or-None” option is required. Shipping packages could also allow “combined shipping” to lower the total cost.

[0147] The new system is so easy to use thus it will enable a trader to be as lazy as he wants. One can use the “market order” which will guarantee him to get the best of all current possible deals without doing extensive research or prices comparison. Another feature he can use is a “Relative Price”. This is a scoring sub-system like calculating the GRE score. He doesn't want to use market order but instead uses a percentage relative price which based on all offered current prices and/or historical price of that merchandise from his peers. For example, there are 100 bidders out there on the market who bid on the same subgroups of products, and you may use “90%” price by which the system will calculate an offer price which will probably put you near the position of the top 10% highest bidder from all your peers (for example, by priceMin+(priceMax−priceMin)*0.9) or the mean value of the 10th price and the 11th price, which will make you the new 11th highest bidder). You can also obtain a relative price by referring to the trading history, for example, the past one month's, highest and lowest deal price.

Candidate List

[0148] There will be full lists of all bids, asks and cAsks (asks from carriers). Each record in the list will be identified by unique bidIDs, askIDs or cAskIDs and saved into the database tables (tbl_asks, tbl_bids, tbl_cAsks in FIG. 1B). Introducer will find out those bidIDs/askIDs/cAskIDs with compatible (matched) Acceptance Masks and Keys. Those without any matched counter party will NOT be selected for further processing unless new offer is received and a match is found. As mentioned above, the price information is not considered by the introducer routine function in this prescreening, which only deals with matching GIDs representing properties of involved parties'. The introducer routine then divided these offers (identified by bidIDs/askIDs/cAskIDs) by the compare the merchandise's PID (the first section of MGID) into smaller subsets, where only one PID is involved within each subset offer records. Bid/ask information from multiple bidderIDs/askerIDs, together with the cAsk information from multiple shipping carriers for the same PID are accepted and make a candidates list for that PID, regardless of the 2nd section of MGID and the offers' price. Generally, bidders will use the MGID_bidder_AM as a mask to find matched merchandise (MGID_key from asker) on market (FIG. 1B). MIDBid is only useful when the bidder is bidding on a specific item, such as collection auctions, instead of trying to find a category of matched items with same functions and properties. In the latter case, the new system is well compatible with the prior arts, which is how the current auction web sites doing their business.

[0149] The SQL command to find candidate list of each PID would be something like:

[0150]

SELECT askID, bidID, cAskID, timeAsk, timeBid, timeCAsk INTO
table_candidate_offers_of_PID
FROM tbl_asks AS a, tbl_bids AS b, tbl_cAsks AS c
WHERE is_matched( a.askerID, b.bidderID, c.carrierID )=1
AND ( get_product_id(b.midBid)=PID AND
get_product_id(a.midAsk) =PID AND
c.shippingMethodID=get_shipping_method(a.midAsk, b.voluneBid) )

[0151] The returned (output) values of the above step are the askID, bidID and cAskID, which are combinations of IDs of candidate list of ask offers, bid offers and shipping offers, together with the time those offers are made. As the descriptive SQL command has illustrated above, the aim of this step is to find out from the whole records set of ask/bid/cAsk those records where: 1) the item the bidders bids is same as what the asker asks, and the shipper could provide a suitable package to pack and ship it; and 2) the asker/bidder/cAsker are compatible (acceptable) to each other.

[0152] Suppose there are m askers, n bidders and k shipping carriers (notice that fields of the tbl_cAsks not only contains carrierID, but also contains packageID from tbl_package, which in turn depends on the askerID and bidderID, see FIG. 1B). In fact, each single combination of askID and bidID, there will be k possible shipping fees. The dataset will be m*n possible permutation of askIDs and bidIDs, then each row of askID and bidID is combined with k different carriers, and get quotes of shipping from each of the carriers. Before matching, the record set would be in its maximum size of m*n*k rows, each of which represents a permutation of ask, hid and cAsk offer, in reality the real dataset should always be of a smaller size because some unmatched data are filtered out.

[0153] There are three subroutines involved in the above SQL commands. They are “get_product_id”, “get_shipping_method” and “is_matched”. The get_product_id routine is used to get the PID (product id, the first section of the MGID) by doing a simple query against thl_merchandise_detail table. The get_shipping_method routine is an application or database table that returns the desired and required packing method for a specific merchandise and quantity. For an example: if the merchandise is a book, the returned packing method might be an envelope; if the merchandise is a TV, the packing method would be a carton box of proper size and with proper stuffing. The information will help shipment carriers to decide the shipping fee. Please notice the merchandise is the one that asker sells but the volume is the one the bidder buys, and the address of asker and bidder could be, but is not necessary, included at this step. The is_matched routine is a prescreening application using the above said Introducer routine to see if all sections between all involved parties have matched keys and acceptance masks.

[0154] There are at least two major advantages to prescreening all records into candidate lists subsets by their PIDs. First, it limits the records set to same PID thus reduces the combination of ask orders and bid order to a manageable size. Second, this will allow server groups (multiple server computers) to share the tasks of handling the whole records set by process one or more subsets on a single server.

Convert Candidate listing to Final listing queue

[0155] After subset records of candidate list for a PID are generated through the prescreening, the rest parts of MGID (since the PIDs are always the same within each subset) and qualified AGIDs/BGIDs/CGIDs are also obtained through the relational database tables. See FIG. 9. By fingerprinting and grouping within all AGID/BGID/CGID, huge amounts of askers/bidders/carriers are combined into limited numbers of groups. These groups can provide better communication and evaluation channels between multiple askers/bidders on multiple items.

[0156] Prices and fees such as Shipping/Handling/Tax must also be taken into consideration before doing the final deal matching. Askers from different locations sell items to bidders at different locations. This difference will generate a whole variety combination of shipping fees and taxes. Similar reason for the handling fees between multiple bidders and multiple askers. Sometime other fees like commission may also involved. These fees could be calculated by some fee_calculator subroutines under a formula or get from a database lookup table of fees. Refer to FIGS. 8A and 8B.

[0157] After presorting the candidate list by MGID/BGID/AGID/CGID matching, the complexity of this combination would be reduced a lot to a manageable size. Further more, these candidate list can be further pre-filtered before grouping with considering the SH fees, by simple SQL command, as illustrated in FIG. 15. Unlike trading stocks, the gap in our system is not solely the difference between the prices of ask and bid. The “gap” formula here is (ask+FEE−bid). For each candidate list, the fee is not a constant but rather as a function of the askID, bidID and other related parties such as the shipping carrier. It could be either feed from a fee database table where information of asker/bidder/carrier would determine the total shipping and handling fee for each particular transaction; or be calculated by some equations defined by shipping carriers and policy makers. As demoed in FIG. 8A, the S/H fee may also extend to tax and commission. These fees may or may not be charged to the askers, bidder or both. Like another format of handling fee, if there was any commission fee or other extra fees, it could always be automatically calculated and includes itself in the total fees. The prices that bidders/askers see are always the final cost or profit.

[0158] The demo SQL command for catc total price with S/H fee considered would be something like:

[0159]

SELECT askID, bidID, cAskID, (priceAsk + shippingFee(askID, bidID,
carrrierID) + otherFee − priceBid) AS
	gapPrice, timeAsk, timeBid, timeCAsk
FROM table_candidate_offers_of_PID
WHERE gapPrice <=0
ORDER BY gap, priceBid DESC, other_order_param

[0160] The returned queue would be all records that could reach a possible deal (where the asker, bidder and carrier's gap price is less equal to zero). These records would then be sorted by some parameters. Sorting will be discussed below. The returned askID, bidID and cAskID would make a final list of queue for further deal matching. Please be reminded that a final list would be generated for each combination of matched GIDs (mGID/AGID/bGID/cGID) within a certain PID.

[0161] When new bid/ask/cAsk offers on this merchandise are received, they are inserted to the record queue of the corresponding final list and be given an Offer ID (OID). When an offer in queue is changed by the submitter, the information associated with its OID is simultaneously locked, modified and updated with the latest price and time of offer. When one offer is cancelled, all records corresponding to that OID is removed from the queue.

[0162] The market server would run 24 hr/7 day. It will do maintains during off-peak of market hours.

[0163] Basically there would be no time limit of listing merchandise on our platform as long as there is transaction on it. Like PK board of stock market, if some merchandise keeps being inactive, which means receiving no new bid nor ask on it, after a certain time period, it may be removed from the system queue.

[0164] When other extra fees applies (such as commission fee, tax, etc), formula would still be similar.

Derivative Market of Shipping Service for Carriers

[0165] As mentioned above, shipping fee plays an important role in calculation the final cost thus affects the gap price. Since the shipping fee is generated dynamically form database but not a prefixed price tag, carriers are given a stage in the market as well. In reality, all packages generated from the merchandise market are waiting to be shipped. This builds another market of shipping service where the transportation of these packages becomes the “merchandise”. For example, FedEx has got 1500 shipment orders at the flat cost of $6.00 within USA. Then FedEx can see if he could lower this rate to 5.75, he will get extra 500 orders than now. This is done by competing with other carriers such as UPS through our platform. Thus, every shipments carrier can also actively compete on the derivative market of shipping fee. This competition is in REAL TIME and no longer in a passive way. Major carriers in USA may not willingly to change the rates for some other concerns such as to limit their liability. Even in this case, they are still allowed to adjust the rate for fuel surcharge from time to time. And any price adjustment like this can bring new matched deals by changing the gap in a dynamic way. In another aspect, smaller carriers or local courier service providers can then be given the chances and playground to compete with major carriers. By offer competitive fee rates, these smaller carriers can grab some orders from the major carrier giants. By adjust their rates (cAsk) more frequently in an “asker-like” behavior, it gives them more flexibility. Our trading engine can monitor and track any change in their shipping rates in a real-time manner, and then in turn affect the deal matching on the merchandise market at once.

Derivative Direct Sale Channel for Manufactures

[0166] The most successful manufacture who use direct sale is DELL. With the help of our trading system's backbone, any manufacture can build its own direct sale channel very quick and easily. This market will also help the manufactures to plan their production well ahead of time. Manufacture can plan their production by category of the orders and by the differences in delivery time. They can even sell option like offers which executed at a later time.

Peers Bid and Peers Ask

[0167] Peers compete with each other. FIG. 10 shows how one bidder compete with other peer bidders. Given the following scenario: There are three bidders (1011, 1012, 1013) on the market bidding for one item from 2 askers (1001, 1002). Bidder 1 offers $16.00 for it and the offer would show at both askers. He has two peers at asker 1's list. At asker 2, because the GID mask and key matching reason, only the 3rd bidder competes with him. Notice the SH are all different due to different asker/bidder locations and other properties. At asker 1, bidder 2 has the highest Final bid, which is 13.25(1022). To bidder 1, this means he has to place a bid of 13.25+4.25=$17.50 to over bid bidder 2. Same at asker 2, the highest final bid would be 14+3=$17.00. So the highest bid on the whole market for Bidder 1 would be equivalent to $17.5. This is $1.50 more than what he current offers. Similar rules applies for the askers/carriers and their peers.

Gaps, Priority of Queue and Deal Matching

[0168] The trading system dynamically matches bid/ask/cAsk offers in a real time manner and pick out those offers whose gap price is either negative or zero. The queue of these offers within each said generated subset of records then needs to be sorted to according to priority to generate final orders. The sorting algorithm would be: smaller gap in price gets highest priority; earlier offer time gets higher priority, etc. The first criteria would be the gap price because a smaller gap price would infer either a higher bid price or a lower ask/cAsk price, which should be given privilege in the queue. When the gaps are same, we can give higher priceBid a higher priority because it is the total money being paid, which can produce more commissions for our service. Following could be the time when the offers are given. We can also customaries the priority in sorting, such as we can give user with higher rating a higher priority, associate with membership levels, etc. For example, a 4-star rated user and a 5-star rated user offer the same price at the same time. The system may decide to sell it to the 5-star user. User can even choose to overwrite the default sorting priority settings of his own offer buy use additional defined and customizable criteria for the matching algorithm such as they just prefer certain group of user even they do not offer the best price.

[0169] Gap is the difference between the need and supply. In our trading system, supplies is encoded into GID Keys while needs are encoded into GID Acceptance Masks. Thus, any difference in each segment of GID pairs of the Keys and the Acceptance Masks can be considered as a “gap” in GIDs. And these gaps in GID, which are pretty similar in function to the gapPrice, can also serve to be used as minor sorting criteria, which will provide cues (index) for sorting when the major criteria are all same. For example, the down payment percentage is encoded as one segment of GID, which can give serious bidder higher priority over others when other major “gaps” are same.

[0170] After the offers candidates are sorted, orders are generated from this sorted list of queue (one by one). Each order contains the askerID, bidderID, cAskerID, mID that the asker is selling and volume that the bidder is finally buying, which is usually the minimum value of the volumeAsk and volumeBid. The source code in Matlab (‘gap_matcher_demo.m’) and VB (‘offerMatcher.aspx.vb’) are attached to show how to find out matched deals from queue of candidate offers (with gap Price<=0) and to generate the final orders.

Advanced: Portal folio Deal Matching

[0171] This system is very versatile and flexible. User can make some portal folio bids and asks. They can set the priority and order for their portal folios to be executed. For example, a user wants to DIY a computer. He can put an offer of motherboard, CPU, power, case, memory, hard drive, etc. He make a portal folio offer contains 7 or more items. When he submit this portal folio offer, system regards the 7 sub-offers as a whole offer and will hold them till all of them are available on the market before putting the order into the waiting queue and return only 1 total price for the whole computer instead of 7 prices.

[0172] User may also want to buy a mouse and a mouse pad. But he wants to make sure to get a mouse first then the mouse pad. He can set the execute order of his bid offer, so the mouse pad offer will be hold until he got the mouse.

[0173] This is also true for the askers. He might only have one piece of item, but he can still managed to list it at different price to different buyer groups. And when any of those offers are matched, the rest is automatically voided at the same time.

Payment, Transaction and Execution Time

[0174] The system will consummate and track the sale on matched deals automatically. When a match is found, the system will make a contract of deal on the said merchandise between the selected asker, selected bidder and selected shipping carrier. Notification and tracking info will be sent to the bidder, asker and the carrier. Execution time will also be arranged and tracked by the server. Notice will also get documented in the trading system server for survey and rating.

[0175] When the bidder made his offer, he needs to fill out the method of payment. He can choose from standard methods such as Credit card, online wiring, e-check or other 3rd party payment service. The bidder need also agree to pay a certain percentage (0˜100%) as down payment to secure the deal, that amount will be deducted from bidder's said pre-set account immediately after the deal is reached. The rest of the payment will be clear later between the bidder, asker and cAsker (shipper).

[0176] Transaction is considered as done only when 1) payer has paid full payment to the payees (asker and carrier) and 2) buyer got the item from the seller/carrier. Otherwise, it will keep pending and sending notice to the payer, seller or carrier.

[0177] Generally, merchandise's price will drop in the long run. User can bid for some thing that needs to be delivered after a certain period of delay rather than right away. Usually he can get a better price. For example, they can bid a computer with chosen configuration but be delivered within 6 month at a much lower price. He can also get a new camera as Xmas gift long before the Xmas. There are always individual users who are good at finding good deals so they could get stuff at lower price and sell it later at a higher price to others. These users can also do the same trick by selling first and taking the risk to find the deals later.

[0178] The “falling trend” makes the merchandise market like a “bear stock market” where “PUT” options is profitable. Users could then do something like stock options trading on regular merchandise market through our platform. Experienced users can bid for a “right”, like a rain-check or coupon, to buy some merchandise in the future at a certain price at certain time from qualified “right issuers” (askers), who, usually the manufactures, could offer such a “right”. By selling the options, manufactures can plan their productions ahead of time and generate some cash flow well in advance. For the options like contract, some pre-located security payment, at a certain percentage of the full payment, from the option asker (right issuers) is mandatory as sort of bidder protections (in the concept of deposit from askers).

Post-Transaction

[0179] After each transaction, bidders and askers/cAskers will receive/give feedbacks ratings from/to their counter parties in the transaction. They will as well receive feedback from the trading system server (hosting website) about their trading behavior. The behavior includes the timeliness of payment and delivery and satisfaction of the merchandise. The feedbacks on users will in turn being encoded into users' UGIDs. Feedback request would be hold for the options like contact until the execution time. Bidders' feedback on merchandise will also be requested and later being reflected on the merchandise' MGIDs.

[0180] For each kind of merchandise on the market, historical transactions will be documented and statistically analyzed to provide information of price range, trading volume etc. The information could be revealed in the format of curve or tables, and provided to bidders and askers for their future purchasing reference. It could also be provided for market research of business purpose.

System Statistic: Merchandise Information and Rating of Users

[0181] Statistics information is essential for successful grouping. It not only provides Merchandise/User information about the trading but also evaluates the Users' trading behaviors.

[0182] More information about the merchandise/service, which is being traded, would be provided than it does in the traditional stock market. This is due to the fact that a MGID would carry more information than a stock ticker. It will not just be limited to the last trade, high-low and the gap. One asker may wonder what the 2nd high bid offer could be, if he change/lower the price, will he make more deals thus yields a larger profits from a larger volume? By providing something show the number of potential matches as a function of asking price, this asker will be given a answer of these sort of questions which are important for the asker to make decision. A demo of how price would effect users' decision is shown a chart is in FIG. 11. User can understand the market better by statistic data we provided.

[0183] Feedback rating is another main source for UGID (User's Group ID) and MGID. Overall ratings on involved Users should be done. Different rating result will categorize the user and merchandise into different groups thus affect the their GIDs. Rating should not only base on the number of users transactions, like what eBay does, but also by total order value of their transactions. As listed in FIG. 3 and FIG. 4. The reason is obvious, people trade $1000 computers should be more trustable than people trade $5 keyboards even they all have the same 95% positive feedback on number of transactions. The computer guy will beat the other in the ranking of statistics on total value of sales. Just as Google uses the “double ranking” technology in their search engine to sort search results, similar algorithm could be applied here too, which means the rating is effected by the importance and reputation of the rater. If a user always leave good feedbacks, the bad feedback from him will be more serious than that from users who are very pick- and leaving other bad feedback all the time. Feedbacks from a user has 3000 transactions would have more weigh than those users who just have 10 transaction. Our feedback and rating system will calculate and balance all information to give more objective statistics about rating. Another issue in the rating system is the follow-ups. Feedback need following up, not just after the transaction or received your merchandise. My DELL computer's keyboard failed after only 3 months of arrival but I have no way to reflect this complain to other users. Our new trading platform would provide user the option to leave “follow-up” comments again for the merchandise, and the sellers' warranty and responsiveness.

Back-End: Hardware and Software, Database and Application

[0184] The service solution could be developed in a multi-tiered way. For example the data tier (contains the database access components for the application), application tier (business rules and algorithm), and interface tier (dealing with user interface). The data tier and application tier would make the back-end while the interface tier is the front-end.

[0185] Backend of the system would consist of database server, database, database application and central application server. It will also contain an interface server and all related protocols as well as firewalls, it is illustrated in FIG. 1A02. The platform server's back-end is independent of its front-end, and it would exchange data with front-end through the interface server. Interface server also serves to communicate the trading platform server with users and partners companies through a variety of client interface.

[0186] The computing power of the entire platform can be run in a more distributed or integrated manner. The whole platform can be run on computers running any type of OS, such as Windows, Unix, Linux. etc. The whole server system can be run on a single computer. Or, on the other hand, each part of it can be run on different computer(s). In the future, as the market grows larger and larger, offer queue of each PID (product) can be processing by a designated individual server. Offers are, according to the product' PID, dispatched to sub-level peripheral server(s) from the central server. The sub-level peripheral server(s) can process the offers and generate orders/contracts for that specific product. Offers then be managed by the sublevel server or the central server. Each of the sub-level servers can also be an independent service that might be run by different partner companies.

[0187] The following description of server back-end will be based solely on illustration in FIG. 1A01 to keep the text simple.

[0188] Database: Where the information are stored and indexed. Information would be about merchandise, users (as bidder, asker or a shipping carrier), packages to be shipped, deal contracts, offers, orders and transactions. Offers from users include the original list and the final candidate list, which is generated by pre-filtering (FIG. 15) or an introducer routine. An illustration of database tables and the relationship is show in FIG. 1B.

[0189] Database application: procedures, functions and subroutines. Application handles and manipulates data in database. For example, the auto_upgrader, encoder, the deal_matcher, Shiping_package_selector, decoder and fee_calculator, etc.

[0190] Database server: coordinate database application and database

[0191] Interface server: coordinate communication between the backend and front-end interface. Such as web server, API server (to partner companies), ftp server, email server, call center, Web Service, etc. It will interpret among different interface terminals and exchange data between these components.

[0192] Central application server: the mainframe computer(s) of service system's backbone. Will handle overall applications, protocols and database; It will also do the all APIs such as payment, package tracking, rating and feedback, statistics, etc.

[0193] Protocols: rules and regulation for data storing, manipulating and exchange with internal and external interfaces. Protocols also include applications such as some API functions to communicate with internal or external human or application interface.

Front-End: Media and Interface

[0194] We are creating pages that are cross-device compatible rather than simply cross-browser and platform compatible. This trading platform can be utilized on any interactive media or telecommunication network. These media could be internet (computer network), TV cables, satellite, telephones (wire/wireless), network for wireless/mobile devices, and etc.

[0195] User can interact with the platform through any kind of media interfaces. It could be on a computer screen, TV, cell phone, PDA, game-box, telephone, or through a human or virtual User Representatives at call center or local branch offices. These interfaces will take users' input and give output back to them. Through interface server mentioned above, the front-end and backend can communicate and exchange data. Database of the back-end is independent of the front-end media, so user can communicate across different media network through the central server.

[0196] For example, an interface on computer screen would be something like the stock trading system, but much complex. In this case, the interface server would be a www server that provides both dynamic server pages (such as asp, jsp, cgi, etc) and html pages according to data obtained from its backend. A web browser application will display the last trading price, volume, historical data and etc. Other information such as number of bidder/asker, current bid/ask and gap can be shown. All prices (bid, ask, last trade, historical data, etc.) on this page are the real final prices which include all S/H fees and other commission fees. URLs lead to information related to the merchandise would also be there for the user to review. FIG. 12 show a demo interface of what a bidder would likely to see before a computer. When buttons on the page is clicked, the bidder will be directed to another page similar to corresponding section in FIG. 13, where user can modify the Acceptance Mask and the Keys. Notice that the user can't change the statistics and rating (left side of box 1305 in FIG. 13) which is provided by the trading system. He only have right to modify limited sections (right side) of his BGID Key. This bidder can also use FIG. 12 to change his order type (such as using market order, limit order or stop order, etc.), offer price, offer lifespan (restrictions such as whether his order is good till cancel or he only want put his offer for 36 hrs) and whether he use the all-or-none options (1207).

[0197] Interface displayed on a computer for an asker (seller) is different from that to the bidder (buyer), but the method to generate it is the same. Interface displayed before a shipping service carrier would be different too. It will contain features defining the shipping service provided, such as packing method, package size, weight, stuffing, service type, delivery time required, from and to address of the shipment and total number of packages and the price. The current market price for the shipping service could be shown as the difference between bidder's priceBid and the asker's priceAsk.

[0198] User interfaces on other networked media would provide similar information in a format that is supported by the corresponding terminals (hardware and protocols). For example it would use voice on a telephone call center interface. There is no limitation of what kind of terminal is and of where the interface locates. It could be both input device and output or it can be only part of input or output. It could be even on the merchandise itself. Any merchandise who has a display can display it value on the market by communication with our server via its own network. So don't be surprised when your little mp3 player/coffee maker will tell you its value on market that day when you turn it on. And you don't even have to log on our server in order to sell it. You can register the mp3's owner as yourself at our server when you purchased it. Then one day later when you see the bid and ask price of the mp3, you can enter your offered price with the mp3 buttons and submit it with mp3. The mp3 will transfer this offer together with its SN through its own network (maybe some wireless music exchanging network) into our server. According to the SN of this unit, server will find out the registered ownership information. Your UID and AGID will be used to put that mp3 player into the listing queue on the market. If a matched deal is reached, an email will send to you including all shipping information of the bidder on a paid printable pack slip with tracking number on it. And at the same time, the mp3 could also get a notice and then flashes “I am no longer yours tomorrow!” All you need to do is wrapping the mp3, printout the packing slip, and drop it at a carrier's drop-box. When the carrier pick-up the item and scan it, a notice (email) will be send to both you and the bidder automatically.

[0199] Isolated by an interface server and the related protocols, front end and backend are separated and independent. Change/modification occurred at either back-end or front-end will not affect another.

Communication With Other Third Party Web Services

[0200] Our platform will interact and communicate with other web services out there. Those web services may include user authentication (affiliating referring), shipping carriers' rates, credit card authorization and payment, shipping tracking, review and feedback, etc. All the resource out there on the net can be integrated under our universal trading framework.

Operation: How does the System Work

[0201] User registration: To trade through the system of this invention, users need to register themselves by choosing a userID and a password. They need to fill out some general information page and save the data into a database table (tbl_user). After that they need to assign themselves, at least one role, as an asker (merchandise seller), a bidder (buyer) or a carrier (shipping service provider). This assignment happens automatically when the user first make an offer of ask/bid/cAsk. One user can have more than one role. For each role he wants to linked to his userID, he need to provide essential information for that role. He needs to fill out corresponding property pages where key features of that role are listed. A groupID (UGID) is provided associated with that role. Each user will also fill out another property page, as the acceptance definition, to select his acceptable counterparties. For example, to register as a bidder, one needs to fill out a bidder property page to encode a BGID as key (BGID_key). He also needs to define from which asker he would like to buy product. He needs to generate an AGID as acceptance mask (AGID_bidder_AM). He will further define what kind of shipping he required by define a CGID acceptance mask (CGID_bidder_AM). Information from user and from our system are encoded in to GIDs (key and Acceptance Masks) and then saved in tbl_bidders. Key and acceptance masks would be used by introducer routine to pick out desired counterparties. Information of all askers, bidders and cAskers are saved into corresponding database tables (tbl_askers, tbl_bidders or tbl_cAskers). Fields of database table and of those property pages refers to FIG. 1B.

[0202] Result of property page of user info is encoded into UGID (User groupID) by an encoder routine. User ID, UGID and related information are saved in user database. More user roles may be added in the future's more advanced trading system such as broker, tax collector, etc.

[0203] Merchandise registration: Before merchandise could be traded, it has to be on the market. Merchandise need to be registered on our trading system by a registered user (either asker or bidder). An asker (seller) can register an item he wants to sell, and a bidder (buyer) can register an item he is looking for. A cAsker (shipping carrier) can register all service types, which are defined by packingMethod (dimension, weight, stuffing, etc.), zip codes of pickup/delivery and delivery time, it can provide. The user needs to fill out information about the item or service by filling out the property page of the merchandise or service, respectively. Merchandise information such as a bar code, digital image, description of status needs to be included. If the identical merchandise/service is already in our database, the user (asker/cAsker) can save his time by retrieving the saved information in our system. The result of the property page is then encoded into MGID by encoder routine. All information is then saved to merchandise database. Carriers' registration for their shipping service would generate a full permutation of all kinds of packages with different specification and various locations. Fields of database table and of those property pages refers to FIG. 1B.

[0204] Offering: Registered asker can put an ask offer on a registered merchandise. Bidder can put a bid offer too even without any asker selling that item. When there is a potential deal (asker and bidder are speaking about the same item), all registered cAskers are involved by asking their fees (cAsk) to deliver the merchandise from the askers to the bidders. Offers from asker and bidder would include their UID, MID (the instance, in some case, and for tracking), MGID (the group), price and volume of offer. Offers from cAsker would include the cAsker's UID, the service type (shippingMethod) for the merchandise involved, and the shipping fee between locations of the involved asker and bidder.

[0205] Grouping and matching: Merchandise/Service are inserted into the database as an individual instance. After that they are grouped, matched and traded by their GIDs as a member from one certain group. For each PID (product) on the market, an introducer (prescreen) routine will be used to match all offers, from the asker/bidder/cAsker with the same PID, and list all subset combination of these potential offers. It is done by comparing the keys and acceptance masks between the involved parties. For each PID, those subset of offers that passed the prescreening are then feed to a deal_matcher routine which return all matched deal (where gap is less than or equal to zero). The demo source code of the deal_matcher in Matlab (‘gap_matcher_demo.m’) and VB (‘offerMatcher.aspx.vb’) are attached on a CD.

[0206] Gap and Margin: Gap is defined as priceAsk+priceCAsk−priceBid. If the gap of price was less than zero, there would be a gap margin that can be shared at a certain ratio by all participated users or even by the trading system. For example, the asker asks for $10, the bidder bids for $16, the carrier want $3 for shipping service. The gap margin is 10+3−16=−$3. If the distribution ratio is 1:1:1, the three dollars can then be divided evenly to all 3 users. So the asker get 10+ 3/3=$11, the bidder pay 16−3/3=$15, and the carrier get 3+ 3/3=$4. The trading system can also share this margin as profit. For example, it can keep all of the $3 margin in which case the buyer, seller and carrier just pay/get what they have offered. The system can adjust the ratio between the involved parties to regulate and leverage the transaction.

[0207] Transaction and Post-transaction: After matched deals are found, system will consummate a transaction by binding the involved offers from the asker, bidder and cAsker into an order. System will then generate an order contract and follow up that contract. It will coordinate all involved parties with payment, shipping tracking and feedback rating. The rating and statistic will be done automatically and the result of feedback ranking will then modify the GID of the involved user and merchandise. Extensive and extended statistics may also be committed for other purposes.

Key Routines

[0208] Auto-upgrade: upgrade an Acceptance Mask by select options better than those the receiver required. It could be a based on a general look-up table or sub-routine for each property group. For example, when a bidder is looking for an asker with rating 3/5 starts as input, the routine will also return the entry of 5/5 and 4/5 because they are better than 3/5. Refer to FIG. 6.

[0209] Shipping_package_selector: Used by the askers/cAskers to decide what kind of package is need to deliver the merchandise identified by its MGID. It could be based on a general look-up table contains dimension and weight of the merchandise, or through some specific API routines at each shipping service provider (cAsker). For example, for shipping a notebook computer, the package would be a box with proper foaming stuff. While for a book, an envelope will do the job. If more than one merchandise will be shipped (MIN(volumeAsk, volumeBid)>1), the shippingMethod must fits the requirement of both the dimension and weight. Given the askID and bidID, the program can return shippingMethodID for the merchandise. shippingMethodID and zip codes of the transportation is then provided to carriers to get the cAsk offers. Refer to Shipping Service database in FIG. 1B.

[0210] GID Encoder/Decoder: convert lists of selected options into a GID code. The encoder can use at least two algorithm of encoding for either single-choice selection or multiple-choice selections. Refer to FIGS. 2, 3, 4 and 5B.

[0211] Introducer (preScreener): using Bitwise-AND operation for each section. Then check the Product of all sections. If the product in non-zero (which means Bitwise-And results are non-zero for all sections), it would be considered a match. Introducer routine select out those matched (compatible) GID Keys and Acceptance Masks. Refer to FIG. 7 and FIG. 9

[0212] Fee_calculator: Together with the Shiping_package_selector routine, it will calculate all applicable fees such as SH fee, commission, tax, etc. It may return the resulting final fee according to database or based on lookup table or flat rates. Refer to FIG. 8A and FIG. 8B. It may also take into consideration of all applicable discount fees, such as store credit, discounted rate or valid coupons, etc.

[0213] Deal Matcher: Sort offers by gap and other criteria, match sorted offers by price and volume and then it will return matched offers and generate order. See attached source code shown in gap_matcher_demo.m, deal_matcher.m and deal_matcher_abc.m on the attached application CD.

Demo Web Application of Trading Server

[0214] Included in this application CD, we also developed a demo web application that demonstrated some key features offered by our invention. You need to setup a MS-SQL server and WWW server to run this web application. The demo solution is developed with ASP.NET and VB.

[0215] We tried to follow the three-tiered application model. According to this model, this application should be divided into the following tiers:

[0216] Presentation Tier: Contains the user interface (web pages) for the application

[0217] Business Tier: Contains the business rules (logic) for the application

[0218] Data Tier: Contains the data access components for the application

[0219] But in order to keep it simple and because of its demo purpose, we skip the three-tiered model at some places.

SQL Server and WWW Server Setup

[0220] Restore a SQL database named PPA as instructed in AspDemo.readme.txt in the folder ASP\ on the attached CD. Make sure the user ASPNET or IIS_WPG are its users with full write permission.

[0221] After setting up your WWW server, add a virtual path directed to the location of ASP\PPA_WEB\, and then set Default.aspx as its default page. After compiling, you can then access the web site by visiting http://IP_address/virtual_path-name/where you will need to login the service. After authentication, you can follow a navigation bar at the top of the web pages.

[0222] There are different types of user accounts. Such as Admins, Moderators, Users, Guest, Greeners, etc. For detail, refer to table tbl_user_roles in the database. Guest and Greeners (name for new registered user) can browse the web but can't put any offers. Admin can access a secret page called admin.aspx where some administrate functions are presented. To test the full function of the web site, you can use one of the built-in admin with user name ‘xq’ with password as ‘1’. Other built-in users are from u5 to u8, with their passwords from 5 to 8, respectively.

[0223] A live demo can also be accessed at http:/www.profpro.com/PPA_WEB.

SMTP Mail Server Setup

[0224] You need setup a SMTP mail server to use the email referral and notification functions

Key SQL Database Functions and ASP Demo Pages Screenshots

[0225] Defaultaspx: where all the offers made by the currently logged in user are listed. FIG. 16

[0226] Asks.aspx: Where you can put an ask offer and all ask offers are listed. FIG. 17

[0227] Bids.aspx: Where you can put a bid offer and all bid offers are listed. FIG. 18

[0228] CAsks.aspx: Where you can put a cAsk(shipping) offer and all cAsk offers are listed. FIG. 19

[0229] Product.aspx: Where you can browse and search for a product. FIG. 20

[0230] Add_new_product.aspx: Where you can add a new product FIG. 21

[0231] GID_Encoder.aspx: Where you encode the GID Keys/AMs for M/A/B/C. FIG. 22. The information is defined by tables tbl_grp_pages, tbl_grp_blocks and tbl_grp_items in the database.

[0232] OfferMatcher.aspx: Where an admin user can see all matched offers, and close the deals. In this demo site, you will have to press a command button to do the task, but in real service, the matching subroutine will be done on real time automatically. FIG. 23. This is a hidden page that you can access through the admin.aspx.

[0233] admin.aspx. The page can only be accessed by administrators. FIG. 24. Be default, it will list all the database component such as tables, views, SP and Functions.

[0234] PackingMethodSelector.aspx: Where a logged in user can select shipping method from what he is selling. It will also list his previous history of shipping method for the same item. FIG. 25

[0235] dbo.ismatched(Key, AM): the SQL database function used to find positions of all 1s in the Key and check for the same location in AM. Return true if it is also 1 in AM. Which means the Key and AM are matched pairs.

[0236] Shipping carrier may keep doing their business in the old passive and non-competitive way or compete in the package shipping market on our new platform. When they choose the old way, they don't need to put any cAsk offer. Instead, they can list their services and fees in a lookup table on their web site and leave the rest to our trading server's backend routines. In this case, our system can automatically generate some cAsk offer based on the lookup table for that carrier. As illustrated in FIG. 14.

[0237] Since in someway, shipping service can be considered as merchandise itself. One may only looks for a shipping service without purchasing any other merchandise. In this case, a deal may go only between the bidder and the carrier without any asker or any merchandise involved. For example, FedEx and UPS can register all their service packages, such as envelopes and boxes of different dimensions and weight and between different locations. And a consumer may want to mail 15 pages of A4 paper and one floppy disk from Boston to New York City. The carriers can compete on providing this service. The winner will ship the package for the bidder. This can itself be an independent server platform without involving any traditional merchandise and traditional sellers.

[0238] Advertisement industry and network media. Advertisement can also be traded on our server or on a stand-alone trading platform server. Each advertisement can be defined by some properties such as which media (website, TV or newspaper) it will be published, what level of the pages it locates, its word count and picture size, its color, and its start time and end time on the media, its format, etc. By this way, the advertisement media and position can be traded and people can bid for that position. The winner will be given an permit to upload his advertisement to the media and media will put the uploaded advertisement on according to the schedule and format in the agreement.

[0239] Other participant may be interested to join a more competitive game. For example, someone may act as brokers and charge broker fee (some format of handle/commission). They can help other customers to buy or sell items on line so to save those peoples time and money. Government policy maker can also adjust their state tax for all sales or on certain items, so to promote business of their state. They can do this by creating another bid/ask/tax offers. Current system server can handle all such requirements: minor customization at the introducer routine and fee_calculation routine will accommodate such needs.

[0240] Wholesale/retail/brokers. Wholesaler or retailer can use their BGID to get bulk volume rate and bulk volume shipping rate from manufacture. They can distribute by selling them to individual end users who can even use local pick up to get the product. Since all payment already done online, the user will only need to bring their pickup order confirmation and grab the stuff they ordered. Some local store can even setup a Pickup Only Casher Lane to help fastening the check out.

[0241] If the offer queue is very big on certain product, some pre-filtering can be used to reduce the subset size of candidate offers before take the cAsk in. The pseudo SQL code is shown in FIG. 15.

[0242] User interface can be either web-based (only need browser, with/without plugins/scripts) or application-based (need download/install client software).

[0243] Other stand-alone sites/servers that can trade services: From ordering TV program or find travel packages or even make a home doctor visit appointment, user can always use our website. You can also find a service that helps you to print out some digital pictures at the cheapest price at some near by local stores.

[0244] Technique/Intellectual property/Research result/Commercial information/creative ideas can all be trade here. In fact, we can trade anything that has value and categorizable. Coupon/order collectors/brokers who collect coupon/orders can sell their collection of coupons/orders here at our site.

[0245] Other unique stuff like telephone number, IP address, domain Names, etc can also be trade here.

[0246] Accordingly, the reader will see that:

• [0247] 1) This invention developed a method of categorizing merchandise or parties in a commercial transaction (namely but not limited to seller, buyer, shipping carrier) by first grouping the merchandise or parties and then identifying each group of merchandise or party with an encoded unique group ID (GID). These GIDs can be used to describe the properties that the group can provide (the GID Key) or the properties that the group can accept (the GID Acceptance Mask, or GID AM).
  • [0248] a) The criteria for grouping merchandise will include not only what the merchandise is (such as using a UPC bar code), but also full description of the status of the merchandise (such as new or used, the warty it carries), as well as user feedbacks on that merchandise (such as reviews rating from the users of the merchandise)
  • [0249] b) The criteria for grouping parties of a transaction (seller/buyer/carrier) will include not only the membership info (time of registration, level) but also the payment method, feedback rating and previous transaction history. The feedback is from both the server (such as number of transaction, average time of response, total value and average value of transaction) and the other parties. For an asker or carrier, the store warranty policy can also be used for the categorization.
  • [0250] c) Instances with same properties will be combined into a group and identified with the same Group ID (GID).
  • [0251] d) The method of encoding the properties of merchandise and parties: First list all non-overlapping properties as a option list, then mark the applicable options with one token (such as 1) while the other inapplicable with a different token (such as 0)
  • [0252] e) Asker (seller) of a transaction will provide AGID_Key to identify himself, MGID_key to identify the merchandise he is selling, a BGID_asker_AM to describe the bidders he (the asker) would deal with, and a CGID_asker_AM to describe the shipping service he (the asker) required.
  • [0253] f) Bidder (buyer) of a transaction will provide BGID_Key to identify himself, MGID_bidder_AM to identify the merchandise he wants to buy, a AGID_bidder_AM to describe the asker he (the bidder) would deal with, and a CGID_bidder_AM to describe the shipping service he (the bidder) required.
  • [0254] g) Carrier (shipper) of a transaction will provide CGID_Key to identify the shipping service he can provide, MGID_carrier_AM to describe the merchandise he can ship, a BGID_carrier_AM to describe the bidders he (the carrier) would deal with, and a AGID_carrier_AM to describe the askers he (the carrier) would deal with.
• [0255] 2) This invention developed a method of choosing candidates of possible transaction by matching the grouped merchandise and parties of transactions by comparing the providers' GID Keys against the counter parity's (receivers') Acceptance Masks (AM).
  • [0256] a) The Keys and AM could be obtained by method mentioned above in method Id
  • [0257] b) The match is between the Keys and AMs of all involved parties and merchandise. In a three parties (asker, bidder and carrier) transaction, there would be four sections in total: MGID, AGDI, BGID and CGID. They represent the groups of merchandise, asker, bidder and carrier, respectively.
  • [0258] c) For each GID Key and AM section, the matching routine is performed for each item from the property list which is represented by the GID. When Key and AM are obtained from Method Id, this matching could be done with the BIT AND operation. A non-zero result indicates that the corresponding section is matched. Only when every single GID section of a transaction is matched, the involved parties and the merchandise could be considered the candidates of a possible transaction.
• [0259] 3) This invention developed a method of trading grouped merchandise or service by their GIDs, like trading stocks, among categorized user groups. It integrates the seller, buyer and also the shipping carriers into a real time universal dynamic trading platform.
  • [0260] a) Merchandise or services are grouped and identified by unique MGID using method 1. Users (asker,bidder,cAsker) are also grouped and identified by unique UGIDs (AGDI,BGID,CGID) using the method mentioned above in Method 1.
  • [0261] b) Candidates (merchandise and involved parties) of a possible transaction are selected out with method mentioned above in Method 2
  • [0262] c) Within each merchandise/service group (MGID), the final total gap prices for the permutation of each possible transactions is calculated according to the formula below:
    gap=priceAsk+shippingFee+otherFee−priceBid
  • [0263] d) A Negative final total gap price would indicate that the certain combination of parties, which is associated with that gap price, for that specific merchandise group (MGID) can reach a deal and thus conduct a transaction. Larger absolute values of the gap price would give higher priority in the execution order of the transaction queue. Priority of queue can be effected by other less important factors (such as time of the offer) when the gap prices are same.
  • [0264] e) Feedback rating and previous behavior of user are encoded into the grouping information of that user, thus reflected on the GID of the user group. This would help to make reasonable expectation thus generate the satisfaction of the involved parties
  • [0265] f) The users' payment method is encoded into the grouping information. This would help to reduce payment fault of online business transactions.
  • [0266] g) By grouping users and merchandise/services, the trading system will provide more advanced and versatile tools for its user to trade common commodity and services. It allows user to make market order, limit order, make portfolio orders or even choose execution time of the orders. It also helps to relieve the load of server and network. The invention also enables other advanced features mentioned in the text of the application.

[0267] As used herein, it is understood that “program code” means any expression, in any language, code or notation, of a set of instructions that cause a computing device having an information processing capability to perform a particular function either directly or after any combination of the following: (a) conversion to another language, code or notation; (b) reproduction in a different material form; and/or (c) decompression. To this extent, program code can be embodied as some or all of one or more types of computer programs, such as an application/software program, component software/a library of functions, an operating system, a basic I/O system/driver for a particular computing, storage and/or I/O device, and the like.

[0268] The foregoing description of various aspects of the invention has been presented for purposes of illustration and description. It is not intended to be exhaustive or to limit the invention to the precise form disclosed, and obviously, many modifications and variations are possible. Such modifications and variations that may be apparent to an individual in the art are included within the scope of the invention as defined by the accompanying claims.

[0269] Although the description above contains many specificities, these should not be construed as limiting the scope of the invention but as merely providing illustrations of some of the presently preferred embodiments of this invention. Thus the scope of the invention should be determined by the appended claims and their legal equivalents, rather than by the examples given.

[0270] For the purposes of the claims, the term “merchandise”, “grouped merchandise”, “merchandise item” or other variations is intended to also mean “service”, “grouped service”, “service item” or other variations.

[0271] Not applicable.