WO2001088821A1

WO2001088821A1 - Apparatus, system and method for managing transaction profiles representing different levels of market party commitment

Info

Publication number: WO2001088821A1
Application number: PCT/US2001/016166
Authority: WO
Inventors: Zvi M. Schrieber; Amit Gal
Original assignee: Vert Tech Llc
Priority date: 2000-05-18
Filing date: 2001-05-18
Publication date: 2001-11-22
Also published as: AU2001264684A1

Abstract

A transaction server (112) receives a plurality of transaction profiles (200) from a plurality of market parties (102). The transaction profiles include limitations defining a suggested transaction and indicating the level of intended commitment by the submitting market party (102). The transaction server (112) identifies transaction profiles (200) having overlapping limitations. In an exemplary embodiment, market parties (102) having different levels of intended commitment are identified and the market parties (102) are notified of other transaction profiles (200) having similar interests allowing market parties (102) with different levels of commitment to observe the electronic market and allowing a smooth transition from a search through to commitment. The transaction requests may include transaction value ranges corresponding to a transaction term, where the transaction value ranges define a range of values acceptable to the market party submitting the request.

Description

APPARATUS, SYSTEM AND METHOD FOR MANAGING TRANSACTION PROFILES REPRESENTING DIFFERENT LEVELS OF MARKET PARTY

COMMITMENT

BACKGROUND OF THE INVENTION

The invention relates in general to electronic markets and more specifically to managing transaction profiles submitted by market parties through a communication network.

Communication systems are increasingly being used to provide a medium for facilitating commercial transactions, advertising and the exchange of information. The popularity of the Internet has allowed vendors to provide information regarding their products and services, as well as advertise, to a large number of potential customers. Buyers can purchase products and bid electronically through the Internet network.

Conventional electronic transaction techniques, however, are limited in several ways. In general, most conventional systems are based on hard-coded mechanisms of matching and negotiation. For example, many conventional systems, particularly those that are auction based, perform one-to-many matching and not many-to-many matching. These conventional systems, therefore, allow a seller to pick between many buyers based on price but do not allow for the buyer to select between many sellers.

Another restriction of conventional auction and exchange systems is that buyers and sellers are compared and matched purely on the basis of price and quantity. In commercial transactions, however, other parameters such as credit terms, delivery dates, quality parameters play just as important a role in choosing a supplier or buyer as price and quantity.

Existing systems are limited to providing matching services between only two types of parties such as a buyer and seller. The best match, however, of buyer and seller will often depend crucially on the availability of third-party enablers such as logistics, insurance or finance.

If more than one market mechanism exists, conventional system do not provide services for trading between the mechanisms. For example, in a system which allows some sellers to make a spot offer while others to use an auction, no support is provided for buyer requests which can automatically clear against either a spot offer or an auction even though the buyer may be looking to the system to optimize their price regardless of the market mechanism in use.

Conventional systems are further limited in that a market party accessing the system can only be matched with other market parties having the same level of commitment to a transaction. Typical systems provide only one or two levels of commitment such as a search request or firm offer that are treated separately. The software required to process these separate transactions is cumbersome while the interactions are burdened since the parametric information must be structured differently for searching and for making an offer. Conventional systems are further limited in support for a realistic negotiation process in which both parties increase their level of commitment in stages.

Conventional systems are further limited in that only predetermined discrete terms may be presented to buyers and sellers prohibiting the submission of ranges of acceptable terms. Conventional auction systems do not provide any flexibility to the auctioner to allow modification to the specification of an article of commerce. For example, the auctioner can not submit an offer welcoming bids that allows for variations in delivery times, quantities, credit terms or specifications of a product. This is even more restricting in the case of reverse auctions since buyers may have flexibility in terms of product parameters. A buyer, for example, may consider acceptable equivalents. Similarly, exchange based systems such as the NASDAQ require that each traded commodity be totally discrete and identified by a ticker symbol whereas most business-to-business transactions involve multiple parameters to which the parties may have flexibility.

Finally, although more and more industries are creating standards within the XML framework for describing the goods and even the transactions (commercial contracts) using DTD and XML Schema - conventional systems are not able to match buyers and sellers directly based on their interests expressed in industry specific XML formats. Further, conventional use of XML only allows its use to describe well defined data such as an agreed contract between buyer and seller.

Therefore, there is need for an apparatus, system and method for managing transaction profiles submitted by market parties through a communication network where the market parties may submit transaction profiles representing different intended levels of commitment of the market parties. There is need for various market parties to view market trends, receive information about potential trading parties and enter into transaction agreements through the system.

SUMMARY OF THE INVENTION

In an exemplary embodiment of the invention, a transaction server is connected to several market parties through a communication network. Market parties submit transaction profiles to the transaction server where each transaction profile describes a suggested transaction corresponding to the market party submitting the profile. Each transaction profile includes at least one limitation to the value of at least one parameter such as a price, credit terms, quantity, delivery date, catalog number, quality, or size. The one or more parameters characteristically describe the suggested transaction using a character string, a discrete value or a value range for a transaction attribute. The transaction server identifies at least two transaction profiles having overlapping limitations (i.e. limitations which are not mutually exclusive). Each transaction profile indicates a level of commitment of the market party to the suggested transaction and can be categorized based on the level of commitment into several types of transaction profiles. Some examples of transaction profile types include searches for potential traders, expression of interest in entering into a suggested transaction to allow the identification of potential transaction participants having similar interests (soft match) and firm offers to enter into a transaction. A further example involves a level of commitment changing in time such as an auction modeled by a non-firm expression of interest in order to solicit bids that turns into a firm expression of interest at the auction's end when clearing takes place. In response to the transaction profile, the transaction server provides transaction information to the appropriate market parties.

The transaction information may contain a variety of information and is dependent on the type of transaction profile submitted by the particular party. In the exemplary embodiment, the transaction information includes a resulting transaction profile that contains a description of the overlapping limitations on values of characteristic parameters of the proposed transactions and, therefore, provides a description of which commercial transactions will fulfill the needs of both parties. Transaction information may include search results, transaction terms, information describing transaction profiles submitted by other market parties or any other data, information or statistic. The transaction server may provide a soft match in which information on the match is provided to the parties without any clearing taking place, allowing the parties to close the transaction by subsequent actions, or may commit the market parties to a transaction (i.e. clear the transaction) if the transaction profiles represented firm offers to enter into a transaction by all the market parties. Therefore, transaction profiles indicating different levels of commitment are examined to identify transaction profiles having overlapping limitations. Matching transaction profiles include overlapping limitations and describes at least the common set of transaction characteristics acceptable to both parties. Transaction information is sent to each market party submitting a transaction profile identified as meeting the limitations of another transaction profile.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram of a transaction management system in accordance with an exemplary embodiment of the invention. FIG. 2 is a block diagram of an exemplary transaction profile template. FIG. 3 is a block diagram of the transaction server interfacing to a graphic user interface (GUI) at the local processor in accordance with the exemplary embodiment.

FIG. 4 is a block diagram of an exemplary transaction scenario of the transaction management system. FIG. 5 is a pictorial representation of a buyer transaction profile form as presented by a Web browser to the buyer in accordance with the exemplary transaction scenario and the exemplary embodiment of the invention.

FIG. 6 is a pictorial representation of a seller transaction profile form as presented by a Web browser to the seller in accordance with the exemplary transaction scenario and the exemplary embodiment of the invention.

FIG. 7 is a pictorial representation of a carrier transaction profile form as presented by a Web browser to the carrier in accordance with the exemplary transaction scenario and the exemplary embodiment of the invention.

FIG. 8 is a block diagram of a storage architecture in accordance with the exemplary embodiment for buyer, seller, and transaction enabler trading scenario.

FIG. 9 is a pictorial representation of transaction information as presented by a Web browser to the market party in accordance with the exemplary transaction scenario and the exemplary embodiment of the invention.

FIG. 10 is a flow chart of a method of managing transactions in accordance with the exemplary embodiment of the invention.

FIG. 11 is an illustration of a example of the use of indexing in accordance with the exemplary embodiment of the invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS As described above, conventional electronic market techniques are severely limited by rigid and restrictive rules for representing a transaction request including the need to specify definitive values for all parameters of the transaction. Further, conventional tecliniques provide only limited information to the market parties regarding the capabilities or desires of other market parties or provide such information effectively only in one direction typically only to the sellers. In addition, conventional systems only allow two parties to form a transaction preventing the optimal matching and formation of multiparty transactions. Further, conventional systems have hard coded logic for market mechanisms making it difficult to add new mechanisms and preventing a single buy offer, for example, from competing against multiple types of sell offers. The present invention overcomes these limitations and others by providing an efficient and flexible apparatus, system and method for managing electronic markets and transactions. FIG. 1 is block diagram of a transaction management system 100 in accordance with an exemplary embodiment of the invention. In the exemplary embodiment, market parties 102, which may be individuals or electronic trading systems, submit transaction profiles through local processors 104 (user terminals) connected to a communication network 106. A transaction server 112 identifies related transaction profiles, provides information to appropriate market parties 102, commits market parties 102 to transactions and provides other services based on the content of the transaction profiles received. The transaction profiles include limitations to a suggested transaction acceptable to the market party 102 submitting the transaction profile. Since the limitations may allow for more than one value or transaction term, the transaction profile may describe more than one suggested transaction acceptable to the market party 102. The limitations may be values, character strings, or other symbols that limit or define transaction attributes such as transaction terms, market party names, locations, times, dates, product specifications, model numbers, catalog numbers, sizes, quantities or any other information that may be used to describe a transaction.

After receiving the transaction profiles, the transaction controller 108 identifies at least two transaction profiles that have limitations meeting the other identified transaction profiles. A limitation of a transaction profile meets another limitation of another transaction profile if the limitations of each transaction profile are not inconsistent with the other. Therefore, in context of a value limitation, one limitation meets another limitation if the two limitations are the same or if at least one value defined by one of the limitations is included in the description of the other and no specified values are inconsistent with the other transaction profile description. Several groups of transaction profiles may be identified where each group includes at least two transaction profiles having overlapping transaction limitations. A single system can accept transaction profiles from a variety of industries and relating to a variety of subject matter and can identify the appropriate transaction profiles that match within a group. As discussed below in further detail, the transaction controller 108 accepts and processes transactions profiles having a wide variety of formats. The transaction profiles may describe search requests, expressions of interest to participate in a suggested transaction or group, of transactions (soft match), or may be firm offers to enter into a transaction if the limitations are met. In the exemplary embodiment, the communication network 106 is a packet switched network, such at the Internet, that supports Transmission. Control Protocol/Internet Protocol (TCP/IP), Hypertext Transmission Protocol (HTTP), and Hypertext Markup Language (HTML). Although the transaction management system 100 utilizes the Internet and associated technologies, those skilled in the art will recognize the other types of communication techniques that may be used to facilitate the transaction management based on the teachings discussed below. For example, the communication network 106 may be an Ethernet network. Further, the communication network 106 may be any network or combination of networks suitable for performing the functions described herein. Examples of other suitable data formats include extensible Markup Language (XML), Standard Generalized Markup Language (SGML), serialized Java objects, and custom vector formats. The communication network 106 may include wireline Internet networks as well as wireless communication systems capable of transmitting the information and messages between the local processors 104 and the transaction server 112. The transaction server 112 includes a transaction controller 108, a network interface 110 and a database 114. As described below in further detail, the network interface 110 facilitates the transmission and reception of data and other messages through the communication network 106. The database 114 provides a medium for storing information pertaining to the transaction profiles in addition to, as part of, or as an alternative to, RAM (Random Access Memory) storage and can be accessed by the transaction controller 108. The transaction controller 108 is connected to the communication network 106 through the network interface 110 and performs the transaction management functions. In the exemplary embodiment, the transaction server 112 is a computer such as a PC having dual Pentium III processors operating at a speed of at least 500 MHz and running a Windows NT® based operating system with 500 MB of RAM. Higher volume systems may require a transaction controller 108 utilizing a multiple CPU SUN Solaris box with several gigabytes of RAM. The transaction server 112, however, may be any type of computer processor, processor arrangement or processor combination suitable for implementing the functionality discussed herein. The network interface 110 and the database 114 are shown as boxes with broken lines to illustrate that these functions may be implemented on other computers or processors connected to the transaction controller 108.

The transaction controller 108 is a computer program implemented in Pure Java on a computer running a Java Virtual Machine in the exemplary embodiment. The software used to facilitate the transaction controller 108 allows for parallel processing to run simultaneoμsly on multiple processors or computers. Data synchronization is coordinated through the database 114. Transaction profiles are received through the network interface 110, cached in Random Access Memory (RAM) (not shown), and compared to other transaction profiles stored in the database 114. Those skilled in the art will recognize the various other methods and arrangements for establishing a process or apparatus for performing the operations and calculations for the transaction management system 100. For example, the transaction controller 108 may be implemented in accordance with the Enterprise Java Bean (EJB) technology to allow management by a Web application server. The network interface 110 facilitates communication between the transaction controller 108 and the communication network 106 and is implemented using a Web servlet in addition to conventional Web server hardware and processes. Web servlets may run on Web servers available from Apache, Sun Netscape and J-BM. No persistent data is stored in the Web servlet in the exemplary embodiment. As is known, Java servlets are software running on a Web server that process HTTP messages sent form the browser to the Web server (HTTP POSTs) and can be analogized to a Java applet running on Web browser. As discussed above, the box representing the network interface 110 is illustrated using dotted lines to indicate that the network interface 110 may be implemented as part of a transaction server 112 or as a separate apparatus. The functions of the network interface 110 may be implemented using other interface techniques such as those, for example, utilizing a Common Gateway Interface (CGI), Microsoft Active Server Pages and Java Server Pages for browser based trading and direct TCP/IP communications or methods such as Java RMI and CORBA for system-to-system trading.

The database 114 maintains a persistent copy of all the transaction profiles submitted by the market parties 102 and of a corresponding storage structure. Any one of several types of object or relational databases may be used in the exemplary embodiment. Examples of suitable databases include object databases provided by Versant and relational databases provided by Microsoft and Oracle. Other types of database and storage techniques may be used to maintain the appropriate information and to provide access to the information by the transaction controller 108 including a naming or directory service. Access to an object database may be through the Object Database Management Group (ODMG) Application Program Interface or vendor specific interfaces and access to relational databases may be through JDBC, ODBC and other commercial and proprietary drivers. Multiple computers and storage mechanisms can be used to maintain the database 114 allowing the information to be distributed across several machines. Redundant synchronized copies of the database may be maintained to provide reliability.

The local processors 104 facilitate communication between the market parties 102 and the transaction controller 108 through the network interface 110 and the communication network 106. The local processors 104 may be any type of processor, microprocessor, computer, personal computer (PC), laptop computer, personal digital assistant (PDA) or processor arrangement or processor combination capable of performing the functions described below. In the exemplary embodiment, the local processor 104 is a PC running a Windows 2000® based operating system. The local processor 104 includes, or may be connected to, a communication interface such as a modem for communicating through the communication network 106. Those skilled in the art will recognize the various transmission media and techniques for liriking the local processor 104 to the communication system. Some examples of these techniques and devices include cable modems, analog modems, Digital Subscriber Line (DSL) modems, Tl lines, Ethernet connections, and any other digital or analog communication interface suitable for exchanging information between the local processor 1034 and the communication system. In the exemplary embodiment, Web browser software running on the local processor 104 facilitates a graphic user interface (GUI) which allows the market party 102 to obtain information from, and submit information to, the communication network 106. Examples of suitable Web browser software include Netscape Navigator and Microsoft Explorer. The local processor 104 includes at least one type of output device such as video monitor or display capable of presenting visual information of the GUI and may contain other output devices such as an audio speaker or printer. At least one input device allows the market party 102 to communicate information to the transaction controller 108. In the exemplary embodiment, the market party 102 enters information through a keyboard and computer mouse into a transaction profile form presented as a Web page, including an html <form> element, by the Web browser. Any suitable technique for entering information, however, may be used. Examples of other input techniques include using touch screens and entering information through a microphone and speech-to-text software as well as automated trading by a computer program. Alternatively, if the market party has automated procurement or sales s ch as ERP software the communication with 102 may be software based (e.g. using data formats such as XML and technology such as RPC or messaging) and not involve a display.

In the exemplary embodiment, a transaction profile template in an XML format is accessible by the network interface 110 and the transaction controller 108. The network interface 110 transmits a Web page associated with a template to the local processor 104 ir response to a request by the market party 102. The Web page has a Hypertext Markup Language (HTML) format and includes a form with various fields that correspond to fields in the template. The market party 102 enters information into designated fields within the Web page GUI to create a transaction profile. The transaction profile is transmitted to the transaction server 112 through the communication network 106 using a HTTP POST command and Transfer Control Protocol/Internet Protocol (TCP/LP) techniques. After receiving the transaction profiles, the network interface 110 creates an XML message that includes the limitations described in the transaction profile.

The transaction controller 108 parses the XML message and determines if any other transaction profiles meet the limitations of the transaction profile by comparing the limitations to the limitations of the other transaction profiles received from other market parties 102. If at least one other transaction profile meets the limitations of the received transaction profile (the limitations overlap), the transaction controller 108 determines that a match exists between the transaction profiles. Depending on the type of transaction profile, the transaction controller 108 transmits a notification or other transaction information to selected market parties 102. In the exemplary embodiment, a market party 102 submitting a transaction profile indicates the type of transaction profile that is submitted. The market party 102 may request a search, submit an interest expression that requests the identification for potential transaction participants that may be used to create a soft match, provide a firm offer to enter into a transaction or submit other types of transaction profiles. The data included in the transaction information transmitted to a market party 102 is dependent on the type of transaction profile, the types of transaction profiles that have overlapping limitations and other factors. The transaction information may be transmitted to the market party 102 using HTTP techniques or may be forwarded using other communication techniques such as electronic mail. Electronic mail is convenient for use when a match has been found to a transaction profile submitted at a time significantly earlier than the finding of the match since the party 102 submitting the earlier transaction profile may no longer have access to a Web browser at the time the match is identified. Each of the market parties 102 obtains a transaction profile form from the transaction controller 108 through the communication network 106. In the exemplary embodiment, the market party 102 submits a request for a transaction profile form by designating the appropriate Universal Resource Locator (URL) using the Web browser running on the local processor 104. Each type of transaction profile form is uniquely associated with an URL and the market party 102 may obtain the desired transaction profile form by identifying the appropriate URL: A message formatted in accordance with TCP/IP is transmitted to the network interface 110.

In response to the request for the transaction profile form, the network interface 110 transmits a Web page in accordance with Hypertext Markup Language (HTML). Those skilled in the art will recognize that other types of markup languages or template languages, such as Cold Fusion, and communication techniques may be used to provide a Web page to the market party 102. Although not yet widely accepted, XML methods are suitable for providing the required transfer of information. The Web page provides a transaction profile form to the market party 102 as a Graphic User Interface (GUI) displayed on the monitor or other visual display of the local processor 104.

Therefore, a plurality of transaction profiles are received from a plurality of market parties 102 at a transaction controller 108 through a commumcation network 106. The transaction controller 108 identifies at least two transaction profiles that meet each other's limitations. The matched transaction profiles may indicate different levels of market party 102 commitment. Transaction information describing the identified transaction profiles is transmitted to the market parties 102 corresponding to the identified transaction profiles. Depending on the types of transaction profiles, the market parties 102 may receive information such as the identity of the other market parties 102 having overlapping interests, statistical information, information regarding the other transaction profile limitations. If the identified transaction profiles are firm offers, the parties are committed to a transaction. Otherwise, the market parties 102 may use the transaction information to continue pursuing an agreement with the parties to enter into a transaction. Combinations and adaptations of the above methods provide a sophisticated transaction management system 100 allowing a wide variety of transactions, reports and analysis. FIG. 2 is a block diagram of an exemplary transaction profile template 200. The transaction profile template 200 is a data structure implemented using XML and includes fields for receiving the information entered by the market party 102 in the transaction profile form. As explained above, the market party 102 enters information into a Web page displaying the transaction profile form when submitting the transaction profile. The completed transaction profile form is transmitted through the communication network 106 and received by the network interface 110. The network interface 110 converts the HTML completed transaction profile form to an XML transaction profile by extracting the appropriate information from the HTML transaction profile and placing it within the transaction profile template 200. Although various methods and techniques may be used to represent the transaction profile template 200, a language allowing the representations of sets of XML documents is used in the exemplary embodiment and is referred to as the Extensible Profile Language (XPL). The XPL language may have any one of various structures and rules and the characteristics of the language relevant to the present invention are highlighted below. Those skilled in the art will recognize the various alteration, modifications and permutations that can be applied to the language discussed herein. In the exemplary embodiment, the transaction profile template 200 includes a transaction profile classification 202 and a transaction profile description 204. The transaction profile classification 202 provides technical aspects of the transaction profile and includes a profile type indicator 206, an expiration date 208, and a market party designator 210.

The profile type indicator 206 describes the type of profile that is being submitted by the market party 102 where each type is associated with a particular level commitment. The transaction profile may be a search request, a request to identify potential market participants (soft match request), an offer, an auction submission or other transaction profile. The various transaction profiles are discussed in further detail below.

The expiration date 208 limits the life of the transaction profile by indicating the time the transaction profile lapses. Although the expiration date 208 may not be critical for transaction profiles such as search requests, a market party 102 may desire that other types of transaction profiles have only a limited duration. For example, a market party 102 submitting an offer may only want the offer to stay open for a short time because of market volatility. The market party 102 submitting a reasonable offer at the time of submission may be seriously disadvantaged if the market changes substantially allowing an accepting market party 102 to unfairly reap rewards of an outstanding offer that has not lapsed. By limiting the duration of the transaction profiles, a market party 102 can reduce the risk of undesirable consequences due to market fluctuations. In addition, the expiration date 208 may be useful for other types of transaction profiles. A search will be stored until its expiration date 208 allowing the searching market party to receive notice of matching transaction profiles until the expiration date 208.

The market party designator 210 provides a classification of the market party 102 submitting the transaction request. Examples of market party designators 210 include designators indicating that the market party 102 submitting the transaction profile is a buyer, seller, carrier, financier, or insurer. Depending on the particular market, the market party designator 210 may have additional or fewer potential designations to those mentioned. As described below, the transaction profile classification 202 may include other fields for describing the type of transaction profile, or other parameters related to the transaction profile other than a transaction term. Those skilled in the art will recognize that categorization of transaction profile classification 202 indicators and transaction terms may be achieved in other ways. For example, the expiration date 208 may be considered to be a transaction term (in that it describes the ranges of allowed values for the time of. the transaction) rather than a transaction profile classification 202.

The transaction profile description 204 includes at least one field (212-220) for a transaction term. In the exemplary transaction profile template 200, the transaction profile description 204 includes fields for transaction terms corresponding to price 212, quantity 214, a quality grade minimum 216, a quality grade maximum 218 and a catalog number 220. Other transaction terms that may be included in a transaction profile template 200 include parameters that relate to a product or service. For example, fields may be provided for a size, style and color. The number and types of fields of a particular profile template 200 will depend on the types of goods or services, traditions in the market, and other factors that will readily occur to those skilled in the art.

Each transaction term may be represented by a single value, a wild card, or a range of values. The quality grade minimum 216 and quality grade maximum 218 provide an example of a transaction term having a range of values corresponding to a specification transaction term. For this exemplary transaction term, the value contained in quality grade minimum 216 field and the value in the quality grade maximum 218 field define a range of values corresponding to the quality grade. Since quality grades are typically represented by a discrete value, the fransaction term range defines a finite set of possible values between the maximum and the minimum value. For other types of transaction terms, however, the defined range may represent an infinite number of values. A catalog number field 220 provides a location for specifying a particular catalog number 220 that describes the item by a specific identifier.

A single value transaction term such as the price 212 term, catalog number 220 or the quantity 214 term may be defined with a wild card symbol indicating that any value is acceptable to the market party 102 submitting the transaction profile. Other types of specifications for a parameter include enumeration of acceptable values, key words or expressions which must appear in a matching text parameter. Further, some indication of preference between stored values may be provided.

The data represented in a transaction profile may have a hierarchical structure using XML. This allows groups of related parameters to be grouped both for clarity and to allow them to be wild carded in a single operation. An exemplary hierarchical structure of a fransaction profile is shown in Appendix I. The transaction profile relates to a market party 102 wishing to sell a black BMW having two airbags and antilock brakes where the safety features have been grouped.

Appendix II illustrates an exemplary hierarchical structure of a transaction profile relating to a buyer looking for a black or blue BMW but unconcerned with safety features. If both transaction profiles described in Appendices I and II were submitted, a successful match would occur. As shown in Appendix π, safety features have been grouped as children elements of <safety-features> and are thus wild-carded with a single <xpl:any- element-list>. In the exemplary embodiment, the transaction management system 100 accepts and processes several different types of transaction profiles. Each transaction profile indicates a level of intended commitment to a suggested transaction by a transaction profile type indicator 206. As discussed above, the profile type indicator 206 provides a description of the type of fransaction profile that is intended by the market party 102 submitting the transaction profile. For example, a transaction profile having a transaction profile type indicator 206 designating the transaction profile as a search request indicates that the market party 102 commitment of the market party 102 submitting the transaction profile is limited to only receiving information relating to the suggested fransaction described in the transaction profile. A search allows a market party 102 to identify market parties 102 having particular interests as indicated by the transaction terms of the search request. In the exemplary embodiment, search requests are submitted anonymously and matched to other transaction profiles. Search results are only reported to the market party 102 submitting the search request and are not provided to market parties 102 submitting other matching transaction profiles to the search request.

The transaction controller 108 identifies these market parties 102 by the transaction profiles they submit. Accordingly, a search request may result in several identified market parties 102 that have submitted different types of transaction profiles. As explained above, transaction terms may be described as ranges or may include wild cards corresponding to any value or partial flexibility such as a range or enumeration of acceptable values allowing the market party 102 submitting a search request to limit the breadth of the search. Accordingly, a search may result in the identification of several market parties 102 submitting different types of transaction profiles with different transaction terms.

An expression of interest (soft match request) allows market parties 102 to identify potential trading partners by advertising their interest in entering into a particular category of transactions without firm commitment. The results of a soft match provide the market parties 102 with identities of the market parties 102 meeting the request criteria (fransaction profile), at least some details of the other identified fransaction profiles, explore alternate fransaction terms and progress efficiently to a next level of negotiation with the market party 102 having the most attractive transaction terms. Negotiations may take the form of traditional techniques such as telephone or email or may continue with subsequent transaction profiles. Market parties 102 may observe the market by tracking the changes in matching transaction profiles and noting trends in the number of matching transaction profiles and the transaction terms included in matching fransaction profiles. A firm offer describes a transaction to which the submitting market party 102 is willing to be legally bound. The submitting market party 102 expects to be bound to a transaction if the firm offer of another market party 102 matches the transaction profile. The transaction controller 108 clears the transaction after offers are matched without any additional input or instruction from the submitting market parties 102.

Combinations and modifications to the core transaction profiles discussed above allow a wide variety of market negotiations and exchange of information. Examples of other transaction profiles include Auctions, Dutch auctions, reverse auctions, reverse Dutch auctions, and Request For Quotations (RFQs). English Auctions are launched by a seller and allow interested buyers to propose ascending prices until the highest bidder (or combination of highest bidders when bids are allowed on partial quantities) is .awarded the goods in a predetermined time. As an example of how the different levels of commitment can be applied to modeling complex market mechanisms, the English Auction may be implemented as an expression of interest which is periodically replaced with an expression of interest with higher minimum price and which at the end of the auction is replaced with a firm offer which then clears immediately with the highest bids (bids being represented by firm offers which are controlled to clear with the auction only by an auction number parameter which is introduced into all transaction profiles associated with the auction.) Reverse auctions are launched by the buyer and.allow interested sellers to take turns to propose descending price until the lowest bidder (or combination of bidders when bids are allowed on partial quantities) is awarded a supply contract in a predetermined time.

In Dutch Auctions, which are launched by the seller 404, the market maker periodically calls descending prices until a buyer 402 (or a number of buyers when bids are allowed on partial quantities) agrees to purchase the goods offered at the price called. As a further example of how the different levels of commitment can be applied to modeling complex market mechanisms, the Dutch Auction may be implemented as a firm offer which is periodically replaced with a firm offer with descending prices. A market party 102, such as a seller 404, inherently submits a request-for-quotation (RFQ) when transmitting an expression of interest (soft match) transaction profile. Other market parties 102 may learn of the expression of interest through a search request or through automatic notification upon overlap with their own stored search or soft match request and submit the quotation in the form of a firm offer limited to the particular market party 102 submitting the soft match transaction profile.

If the transaction profile is a search request, the transaction controller 108 forwards fransaction information related to market parties 102 submitting transaction profiles having overlapping limitations to the searcher. The transaction information includes the identity of market parties 102 submitting requests for soft matches and market parties 102 providing firm offers. The reporting logic will however not report the existence of one search to another overlapping search.

In the exemplary embodiment, anonymity is controlled at the market level by the inclusion or exclusion of the market party 102 from the results page. The inclusion of party information in the transaction profile also depends on whether the identity of the market party 102 is one of the parameters which is a transaction term and examined to determine if a match exists. The inclusion of the parties' identity in the transaction profile may be desirable, for example, where the market party 102 submitting a transaction profile indicates that only selected market parties 102 are acceptable for entering into a fransaction by specifying the names, geographical location, credit rating, or other criteria of the preferred market party 102 for a transaction. Other suitable methods for controlling anonymity include submitting a transaction profile that indicates whether the identity of the submitter can be revealed to other market parties 102 or by including only a pseudorandom handle representing the user. The identity of the submitter may be omitted for other reasons, however.

Appendices III and IV illustrate exemplary buyer and seller transaction profiles useful for discussing a matching criteria based on the detailed characteristics of the market parties 102. As shown in Appendix HI, the buyer transaction profile specified by a fictitious company, "Electronics Procurement Inc.," indicates the resistors required, the identity of the buyer and specifies the seller as a wild card indicating that the buyer will work with any seller. Appendix IV provides an exemplary transaction profile submitted by a seller wishing to sell lots of 1000 and 10,000 and that is only willing to enter into a transaction with a buyer in California.

By including details of buyer 402 and seller 404 as parameters of the fransaction, the same wild cards which are used to match product parameters may be used by buyers and sellers to select the specific partners they will work with by name, or the type of trading partner they will accept based on, for example, geography or credit rating. Appendix V illustrates an exemplary resulting transaction profile of a match between the buyer and seller transaction profiles. The intersection specifies a specific value for quantity, buyer and seller and can be used as record of a resulting contract between the two market parties 102. Another example includes further parameters describing the product and transaction terms.

FIG. 3 is a block diagram of the transaction server 112 interfacing to a graphic user interface (GUI) 302 at the local processor 104 in accordance with the exemplary embodiment. In response to a request for a transaction profile form, the web server within the network interface 110 retrieves a transaction profile form 306 stored in HTML format either on the network interface 110 or in storage accessible to the network interface 110. The Web server transmits the transaction profile form to the local processor 104 where it is displayed to the market party 102 through a GUI 302. The transaction profile form 306 includes fields that correspond to the associated transaction profile template 200.

Accordingly, the transaction profile form 306 solicits information corresponding to the fields within the transaction profile template and provides the market party 102 with a vehicle for providing the transaction profile since the completed fransaction form 310 includes the information of the transaction profile. The GUI 302 may be any type of suitable user interface for receiving and entering information. In the exemplary embodiment, the GUI 302 includes the Web browser and an electronic mail (e-mail) interface. Other GUI 302 arrangement will be readily apparent to those skilled in the art.

The market party 102 enters the appropriate information to express the suggested fransaction to form a completed transaction profile form 310 . The completed transaction profile form 310 is information to be included in the transaction profile in a HTTP POST format that is fransmitted to the network interface 110 through the communication network 106. The web servlet 304 parses the transaction profile (completed transaction profile form 310), extracts the appropriate information from the completed transaction profile form 310, and inserts the information into an XML template 312 to form an XML formatted transaction profile which in the exemplary embodiment may include XPL wild cards. The XML formatted transaction profile is transmitted to the fransaction controller 108.

A matching engine 314 in the transaction controller 108 retrieves other transaction profiles stored in the database 114 in order to compare the various fransaction profiles and to identify at least one other transaction profile having limitations that meet the incoming transaction profile. The transaction profiles are indexed in memory to allow efficient elimination of many of the transaction profiles that will not match the incoming transaction profile. As described below in further detail, the matching engine 314 uses indexes to narrow the set potential matching transactions to a smaller subset of potential matching fransaction profiles to promote efficient matching techniques. Various methods, however, may be used to match the transaction profiles.

In the exemplary embodiment, the matching engine 314 invokes a reporting engine 316 and a clearing engine 318 based on the results of any identified matches. If the matching engine 314 determines that two or more firm offers have matching transaction criteria (overlapping limitations), the matching engine 314 forwards the appropriate information to the clearing engine 318. The clearing engine 318 is responsible for removing sets of matching firm offers from the market and passing on a record of the consummated transaction to a fulfillment engine 320. The fulfillment engine 320 is a marketplace system which tracks the execution of a contract when market parties 102 have agreed on an acceptable fransaction.

In the exemplary embodiment, the clearing engine 318 performs resolution of overlaps, prioritization and clearing. An agreed transaction must have a specific value for every parameter. If both market parties 102 had flexibility in some parameter, the intersection may still be flexible. For example, if the seller offered delivery dates between 12^th and 15^th and the buyer specified a delivery date between 10^th and 14^th then any date between 12^th and 14^th would be acceptable to both market parties 102 and this range will be specified in the resultant transaction profile. The clearing engine 318 will replace any such range with a specific value. Typically, the market provider will specify (e.g. using an attribute in the XML template) whether flexibility in a given parameter should be rounded up or down.

Matching is prompted by a newly submitted transaction profile and the new fransaction profile may match with more than one pending transaction profile. The clearing engine 318 organizes all the possible matches in order of priority for clearing. In the exemplary embodiment, the market provider (or an individual user via a fransaction profile) can specify a parameter or more than one parameter in order of precedence (e.g. price or submission date) according to which potential matches are prioritized for matching.

The clearing engine 318 clears transactions in accordance with the matching transaction profiles. Pairs of requests are either removed or their quantity available is mutually reduced according to the prioritization until the new request leading to the match is totally cleared or there is nothing left with which to clear.

The reporting engine 316 produces a resulting transaction profile based on all fransaction profiles of group identified as having overlapping limitations. In the exemplary embodiment, the resulting transaction profile is formatted in accordance with XML and contains information including the identity of the market parties 102 that have submitted matching transaction profiles and the transaction attributes from the transaction profiles including fransaction terms such as price, quantity, catalog numbers, locations, and colors.

The resulting transaction profile is transmitted in an XML format to the network interface 110. In the exemplary embodiment, the Web servlet 304 uses anXSLT script 308 to render XML into an HTML page and provides a visual display of the results by showing the results, for example, in tabular form. As is known, XSLT (extensible style sheet language transformations) is a language that provides a flexible process for the transformations of XML documents to HTML and other languages or types of XML documents. The network interface 110 notifies the market parties 102 in a way appropriate to the choices of the market provider and of the specific market party 102 to be notified. In the exemplary embodiment, the market party 102 that submitted the last transaction profile that resulted in a fransaction match is notified using an html results screen in a results page 322. An HTML web page 322 is appropriate since this last entering market party 102 is on line and has an open browser. Other matching market parties 102 are notified by a results e-mail 324. The resulting transaction profile (322) formatted in accordance with HTML is transmitted through the Internet to the local processor 104. The GUI 302 on the web browser displays the resulting transaction profile as the results page 322 to the market party 102. Other forms of notification include messaging to a backend system or integration with, for example, Wireless Access Protocol (WAP) applications. An enterprise system 326 provides backend procurement and sales services for the transaction management system 100. The enterprise system 326 is an Enterprise Resource

Planning (ERP) system that can integrate to the system 100. Examples of suitable ERP systems include systems available from SAP, Peoplesoft, Oracle, Baan and J.D. Edwards.

FIG. 4 is a block diagram illustrating a transaction scenario in accordance with the exemplary embodiment of the invention where the market parties 102 include buyers 402, sellers 404, and transaction enablers 406. As discussed above, the market parties 102 may be any type of potential participants in a transaction. Although for illustrative purposes, FIG. 4 relates to an example of a commercial transaction that includes at least one buyer 402 and one seller 404, other types of transactions and trading scenarios can be managed by the transaction management system 100. For example, a reinsurance transaction may include market parties 102 categorized as assume and cede and an interest rate swaps transaction may involve parties which pay-fixed and receive-fixed. In the exemplary embodiment, the transaction confroller 108 can process and evaluate transaction profiles related to several types, of transactions, industries, products and services. For purposes of the example discussed with reference to FIG. 4, however, the buyers 402, sellers 404 and transaction enablers 406 are potential participants in a commercial market of gasoline.

During setup and customization procedures, the transaction profile template 200 for each type of market party 102 within each market is created in accordance with the particular market. Each fransaction profile template 200 will have a general form of the transaction profile corresponding to the type of market party 102 submitting the transaction profile. The transaction profile template 200 has "holes" for transaction attribute values such as price, quantity and quality which vary from profile to profile. The market party 102 submitting the transaction profile provides information to complete the form to create the transaction profile. Preferably, the transaction profile template 200 follows any formal XML Data Type Document (DTD) or Schema accepted by the particular market.

A buyer 402 accesses the transaction management system 100, by requesting a buyer transaction profile form through the local processor 104 and the communication network 106. In the exemplary embodiment, the buyer 402 requests the appropriate fransaction form by accessing the URL of the form through the home Web page of the transaction management service provider. The network interface 110 provides a transaction profile form as an HTML Web page using HTTP techniques. In the exemplary frading scenario, a separate transaction form is provided to the buyer 402, seller 404 and the carrier (fransaction enabler) 406 where each form utilizes a different transaction profile template 200.

FIG. 5 is a pictorial representation of a buyer fransaction profile form (buyer form) 500 in accordance with the exemplary embodiment of the invention. The buyer form includes instruction text 502 including information potentially helpful to the buyer 402 when completing the buyer form 500. A profile type field 504 includes a space for entering the type of transaction that the buyer 402 intends to submit. In the exemplary embodiment, the buyer 402 may chose between two status options that are accessible through a pull-down menu including a search (browse) or soft match (expression of interest). A maximum price field 506 allows the buyer 402 to enter a maximum price the buyer 402 is willing to pay per barrel of gasoline. In the present example, the buyer transaction profile form 500 is hard valued to zero as the minimum price. The buyer 402 enters the appropriate minimum and maximum values for a quantity range 508. A minimum quantity field 510 allows the buyer 402 to enter any integer denoting the minimum number of barrels the buyer 402 is willing to buy. The maximum quantity field 512 provides an entry location for the maximum number of barrels the buyer 402 wishes to obtain. The delivery date field 514 includes two fields for defining a range of dates that the buyer 402 would consider for delivery of the gasoline. A grade field 516 allows the buyer 402 to enter the preferred grade of oil to be purchased. In the exemplary embodiment, the buyer 402 may choose the grades by choosing the appropriate option in a pull-down menu. The pull-down menu provides a wild card option by allowing the buyer 402 to choose all grades of oil. In the exemplary scenario, the buyer 402 may enter tolerance values for defining the gasoline. For example, an RVP field 518 allows the buyer 402 to specify a range for the Residual Vapor Pressure (RVP) of the gasoline. An oxygenates section 520 allows the buyer 402 to enter the desired tolerance values for MTBE and ethanol as a percentage of volume of the gasoline. A shipment location field 522 allows a buyer 402 to enter the location to which the oil should be delivered. In the exemplary embodiment, a state may be designated using a pull-down menu and a zip code can be entered manually by the buyer 402. A transaction information request field 524 allows the buyer 402 to request the number of days for which the transaction profile will be stored in the fransaction server 112. The buyer 402 will receive updates reporting any new matching fransaction profiles submitted during the pending period of the fransaction profile. In addition, an e-mail address field 526 allows the buyer 402 to designate an e-mail address that will receive the transaction information. A submit button 528 allows the buyer 402 to submit the fransaction profile form to the network interface 110 when the transaction profile form has been completed. The submit button 528 is implemented in accordance with known internet techniques.

FIG. 6 is a pictorial representation of a seller transaction profile form (seller form) 600 implemented as a Web page. The seller form 600 includes instruction text 602 including information potentially helpful to the seller 404 when completing the seller form 600. A profile type field 604 includes a space for entering the type of fransaction that the seller 404 intends to submit. In the exemplary embodiment, the seller 404 may chose between two status options that are accessible through a pull-down menu including a search request and a soft match (expression of interest). A minimum price field 606 allows the seller 404 to enter a minimum price the seller 404 is willing to receive per barrel of gasoline. The seller 404 enters the appropriate minimum and maximum values for a quantity range 608. A minimum quantity field 610 allows the seller 404 to enter any integer denoting the minimum number of barrels the seller 404 is willing to sell in a transaction. The maximum quantity field 612 provides an entry location for the maximum number of barrels the seller 404 wishes to obtain. The delivery date field 614 includes two fields for defining a range of dates that the seller 404 is presenting for delivery of the gasoline. A grade field 616 allows the seller 404 to enter the preferred grade of oil to be purchased. In the exemplary embodiment, the seller 404 may choose the grades by choosing the appropriate option in a pull-down menu. The pull-down menu provides a wild card option by allowing the seller 404 to choose all grades of oil. In the exemplary scenario, the seller 404 may enter tolerance values for defining the gasoline. For example, an RVP field 618 allows the seller 404 to specify a range for the Residual Vapor Pressure (RVP) of the gasoline. An oxygenates section 620 allows the seller 404 to enter the desired tolerance values for MTBE and ethanol as a percentage of volume of the gasoline. A shipment location field 622 allows a buyer 402 to enter the location to which the oil should be delivered. In the exemplary embodiment, a state may be designated using a pull-down menu and a zip code can be entered manually by the buyer 402. A fransaction information request field 624 allows the seller 404 to request the number of days for which updates will be received. In addition, an e-mail address field 626 allows the seller 404 to designate an e-mail address that will receive the transaction information. A submit button 628 allows the seller 404 to submit the transaction profile form to the network interface 110 when the transaction profile form has been completed. The submit button 628 is implemented in accordance with known internet techniques.

Appendix VI includes an exemplary XML document suitable for implementing a transaction profile template (tpt) 200 consistent with the seller transaction profile form 600. Selections from the appendix are reproduced below and integrated with the following discussion.

The following element is the root element for the XML document to be instantiated by the template. It includes a definition of the xpl and tpt namespaces as required by the XML Namespace standard. <gaz-sale xmlns:xpl=^,,http://www.tradeum.com" xmlns:tpt="http://www.tradeum.com">

The following demonstrates a template command generating a "valid-till" time for the transaction profile with a standard format (e.g. with children for year, month, day, hour, minute and second) and is based on the current time and offsets provided by the http submit. For example, the transaction information request field 624 may be given a reserved html name telling the tpt processor that the value provided is an offset to be used to calculate the correct expiry date.

<tpt:validtill/>

The following XML element groups the details of the parties including the buyer 402 and seller 404 of the transaction.

<buyer>

The following template command will generate details of the submitter (in this case acting as buyer 402). In the exemplary embodiment, the details are retrieved from the database 114 based on the logon name as well as information generated by the network confroller such as the network controller's IP address, a local handle for the user or a random request ID.

<tpt:originator>

</tpt:originator>

The following line marks the level of commitment which the market party 102 is expressing to the transaction profile. The command tp inserttext is a template command which represents a value to be filled in by the submitting party in the form in this case in field 604 which is assumed to have been given html field name "status".

Given that this transaction profile template 200 is for buyers 402, details of the sellers 404 are hard coded to be a wild card. In other words the buyer 402 will work with any seller 404 that matches the other requirements.

<xpl: any_element/> </parties>

The quantity is expressed as an XPL range element where the mimmum and maximum are filled in by the tpt: in-attribute template command from the fields 610 and 612.

<xpl:range min="tpt:minquantity" max="tpt:maxquantity" prefer="up'7>

</quantity>

Continuing with the exemplary template and form, the price element is a range which the buyer 402 has a hard-coded minimum of "0" in the template and a maximum to be filled in from field 606. A preferred attribute is used to indicate the direction in which any price range should be resolved upon clearing.

<price>

<xpl:range min="0" max="tpt:price" prefer- ¹ down" /> </price> <source>

<tpt:inserttext fϊeld="state">

An error message can be generated using the template convention below. This template convention allows an error message to be specified as a child of tp insertext. If no value is entered for the relevant field, the template will not be instantiated and the error will be returned to the user.

<tpt:error text=^"<h2>Please specify your state. Press the Back button to continue.</h2>'7> </tpt:inserttext>

</state> <zip>

<tpt:inserttext field="zip">

<tpt:error text="<h2>Please specify your zip code. Press the Back button to continue.</h2>'7>

</tpt:inserttext> </zip> </destination> <delivery>

The "xplrdaterange" command represents a range of times between the first and second <date> children as illustrated in Appendix VI. Other exemplary ranges are shown in Appendix VI.

FIG. 7 is a pictorial representation of the carrier transaction profile form (carrier form) 700. The carrier form 700 includes instruction text 702 including information potentially helpful to the carrier (406) when completing the carrier form 700. A profile type field 704 includes a space for entering the type of transaction that the carrier (406) intends to submit. In the exemplary embodiment, the carrier (406) may chose between two status options that are accessible through a pull-down menu including a search and an expression of interest. A shipping cost field 706 allows the seller 404 to enter a mimmum price the carrier (406) is willing to receive for shipping each barrel of gasoline. The carrier (406) enters the appropriate minimum and maximum values for a quantity range 708. A minimum quantity field 710 allows the carrier (406) to enter any integer denoting the minimum number of barrels the carrier (406) is willing to ship in a single transaction. The maximum quantity field 712 provides an entry location for the maximum number of barrels the carrier (406) wishes to ship in a transaction. The delivery date field 714 includes two fields for defining a range of dates that the carrier (406) is presenting for shipment of the gasoline. A grade field 716 allows the carrier (406) to enter the preferred grade of oil to be shipped. In the exemplary embodiment, the carrier (406) may choose the grades by choosing the appropriate option in a pull-down menu. The pull-down menu provides a wild card option by allowing the carrier (406) to choose all grades of oil. A shipping duration field 718 allows the carrier (406) to enter shipping duration range in days. The seller 404 enters one or more locations that the carrier (406) is willing to acquire the oil by choosing one or more options from a pull down menu in the pickup location field 720. The delivery location is indicated in the delivery location field 722. A transaction information request field 724 allows the carrier (406) to request the number of days for which updates will be received. The e-mail address field 726 allows the seller 404 to designate an e-mail address that will receive the fransaction information. A submit button 728 allows the carrier (406) to submit the transaction profile form to the network interface 110 when the transaction profile form 200 has been completed.

The network interface 110 extracts the appropriate information form each field in each fransaction profile (500, .600, 700) received and enters the information into a fransaction template corresponding to the type of fransaction profile. As discussed above, transaction profile templates 200 are created in accordance with XML techniques during the initialization procedure used to create XML transaction profiles. Each transaction profile is received in an HTTP POST format and converted into an XML format by inserting information extracted from the HTML fransaction profile into an appropriate XML template. Therefore, information received in the fields of the buyer form 500 are inserted into the appropriate fields of a buyer template to form a buyer transaction profile. Information contained within the HTML seller form 600 is placed within an XML template to create an XML seller transaction profile. A carrier XML transaction profile is formed using the HTML carrier form 700.

The XML transaction forms are received at the fransaction controller 108. The transaction controller 108 identifies combinations of buyers 402, seller 404 and carrier profiles with non-empty three way intersection. In the exemplary embodiment, each incoming transaction profile is compared to all stored transaction profiles to identify nonempty intersections. The transaction confroller 108 preferably indexes the stored transaction profiles to allow for efficient and rapid elimination of non-matching transaction profiles and individual comparison of potential matching transaction profiles to identify the transaction profiles having limitations meeting the limitations of the incoming fransaction profile.

FIG. 8 is a block diagram of a storage architecture in accordance with the exemplary embodiment for a buyer 402, seller 404, and transaction enabler frading scenario. In the exemplary scenario of a three way match, the fransaction controller 108 preferably stores not only submitted fransaction profiles but also two-way matches akeady calculated so that the three way match may be computed immediately when the third party enters. Buyer transaction profiles 802 are matched with seller transaction profiles 804 and stored as buyer-seller combination transaction profiles 806. Buyer transaction profiles 802 are matched with carrier transaction profiles 808 and stored as buyer-carrier combination fransaction profiles 810. Carrier fransaction profiles 808 are matched with seller transaction profiles 804 and stored as seller-carrier combination fransaction profiles 812. The matched combinations of all three parties are stored as buyer-seller-carrier combination transaction profiles 814. Preferably, the system stores the single profiles and two and three way matches in a directed acyclic graph representing the semi-lattice (in algebraic terms) of the fransaction profiles and their intersections with the partial order relation of set inclusion.

The arrows in FIG. 8 point from a transaction profile to a subset of that fransaction profile representing its intersection with a compatible fransaction profile from a different party. The buyer-seller-carrier combination transaction profiles 814 (three way intersection or, more generally, an intersection between all relevant party roles) need not be stored and can be directly reported to the appropriate market parties 102.

For each computed intersection the transaction controller 108 will call reporting logic which will decide which market parties 102 to notify. In the exemplary embodiment, an intersection between a search and a soft match will be notified to the soft match only. The intersections will be reported in XML and still containing special wild card elements if the overlap still has flexibility remaining. The matches are converted into an appropriate format such as an HTML table, for example, using the extensible Styling Language Transformation (XSLT). FIG. 9 is a pictorial representation of a resulting fransaction profile 900

(transaction information) as presented by a Web browser to the market party 102 in accordance with the exemplary transaction scenario and the exemplary embodiment of the invention. A transaction attribute may be described in the resulting fransaction profile 900 as a single value or a plurality of values. For example, a resulting transaction profile 900 resulting from the intersection of two or more expressions of interest (soft match) may include one or more transaction attributes represented by ranges, wild cards or partial wild cards.

The exemplary resulting transaction profile represented as 900 in FIG. 9 corresponds to a soft match scenario. The resulting transaction profile includes fransaction information 918 corresponding to the fransaction profiles submitted by three market parties 102; a buyer 402, a seller 404, and a carrier (406). The type of fransaction profile submitted by each market party 102 is displayed in a status field 902 - 906. The text string "proposal" in the column indicates that each transaction profile was an expression of interest to enter into a suggested transaction. The quantity field 908 provides a description of the overlapping range of quantity values submitted by the market parties 102. In the example, 1000 to 10000 gallons is included within all the specified acceptable ranges within the transaction profiles submitted by all of the market parties 102 within the identified group. The price field 910 indicates the acceptable values of prices that the seller 404, and buyer 402 are willing to entertain. In the example, the buyer 402 and seller 404 must continue to another of level of negotiations before either party is committed to a price or quantity. The market parties 102 may continue to use the transaction management system 100 to agree on a value by submitting subsequent transaction profiles which may be firm offers of more restrictive expression of interest. The market parties 102 may continue to negotiate using other methods such as email, facsimile, or conversation. The origin location is displayed in the origin field 912 and the destination of the delivery of the gasoline is shown in the destination field 914. The delivery date 916 indicates a range of acceptable delivery dates. The market parties 102 may continue to negotiate to more narrowly define the delivery dates or agree that the delivery date within the range specified is acceptable in a cleared transaction. FIG. 10 is a flow chart of a method of managing transactions in accordance with the exemplary embodiment of the invention. At step 1002, the transaction server 112 receives a request for a transaction profile form. The network interface 110 receives a request for a transaction profile form. As described above, the market party 102 submits a request for the fransaction profile form by indicating the appropriate URL through a Web browser. The URL uniquely indicates to the network interface 110 the type of transaction profile the market party 102 requires.

At step 1004, the network interface 110 transmits a Web page to the local processor 104. The Web page is a transaction profile form having at least one fransaction that the market party 102 can modify or use to describe a transaction term or other parameter.

The transaction server 112 receives the transaction profile at step 1006. The network interface 110 receives the completed transaction profile form 300 from the market party 102 through the communication network 106 in an HTML format.

The network interface 110 converts the transaction profile into an XML format at step 1008 by mstantiating a transaction profile template 200. The values and wild cards in the transaction profile originate in some combination of the values submitted in the form and values hard-coded in the transaction profile template 200.

At step 1010, the transaction profile is received at the fransaction controller 108. The XML template containing the extracted information is received by the fransaction confroller 108 from the network interface 110.

At step 1012, the transaction controller 108 identifies at least two transaction profiles meeting the limitations of each of the other of the at least two transaction profiles. The fransaction controller 108 analyzes the limitations as described by the each transaction profile to determine overlapping transaction criteria. The matching process is described in further detail below in reference to FIG. 11.

At step 1014, the received transaction profile is stored within the database 114. In the exemplary embodiment, the transaction profiles are stored in a hierarchical data structure in order to facilitate the matching process by rapidly eliminating broad classes of non-matching profiles from the matching. At step 1016, the transaction controller 108 creates a fransaction profile result vector corresponding to the matches found for the transaction profile. The transaction information included in the transaction profile result vector may include the identity of the market parties 102 submitting transaction profiles having overlapping limitations, and the actual fransaction profile or details therefrom. In the exemplary embodiment, the transaction profile result vector lists all non-empty intersections. Provided that details of the submitting parties are included within the transaction profile (e.g. buyer 402 specified himself as buyer 402 and wild cards seller and seller 404 specified himself as seller and wildcards buyer) after intersection details of both parties appear in the intersection result. At step 1018, the fransaction profile result vector is converted into an HTML formatted transaction information Web page 600.

At step 1020, the transaction information Web page 600 is fransmitted to the appropriate market party 102. The information is presented to the market party 102 through the Web browser using known techniques.

As discussed above, XPL is a language of special XML elements which can be inserted within an XML document to represent flexibility in the value of a particular parameter. A given industry may have a DTD or XML Schema for XML Documents describing the contracts (i.e. commercial transactions) in that industry. During negotiations, a market party may want to describe not only a specific contract or fransaction bur rather may wish to describe the transactions that interest them. These desired transactions may include some flexibility of the transaction terms such as delivery dates, the identity of the counter part, quantities and other terms which will occur readily to those skilled in the art.

The use of XPL documents allows this flexibility to be captured in a natural way which respects the structure of the XML document. Each XPL element represents a set of XML elements and the XPL element may be inserted in a given place in the document to describe which XML elements would be acceptable at that place in the document.

Although the XPL can have a variety of semantics, a convenient example allows each XPL element to represent a set of XML elements which it matches. Each XPL document (i.e. XML document containing XPL elements) can be given a semantics by stating that each XPL document matches a given XML document if their root elements match.

Table 1

XPL element Simple XML elements which match

Ordinary XML element Matches any other XML element provided their tags are the same and that they have the same number of children which match pair-wise (recursively)

Ordinary XML text Matches identical text only.

<xpl:none/> None

<xpl: any__element/> Any single XML element <xpl:range min="5" max- '10"/> Any textual XML element containing a well formatted number in the range 5 to 10.

Those skilled in the art will recognize that the XPL language can be extended to provide a variety of convenient attributes. For example, the XPL language may be extended to deal with lists of XML elements such as <xpl:any_element_list/> which matches any list of XML elements.

Table 2 below provides an exemplary algorithm utilized by the method of identifying transaction profiles having overlapping limitations in accordance with the exemplary embodiment of the invention. For illustrative purposes, the method discussed in reference to Table 2 provides an exemplary matching technique for identifying two transaction profile expressed in XPL that have overlapping limitations (intersect). The result of the match is a new resulting fransaction profile, which represents the intersection of the original fransaction profiles submitted by the two market parties 102. If no match is found, the intersection is an empty set that can be expressed, for example, as an XPL element, "<xpl:none/>" which does not match any XML documents.

If the two XPL documents (fransaction profiles) to be compared are referred to as P and Q and the XPL document resulting from the intersecting of P and Q (transaction profile) is labeled as R, then this intersection R is defined by saying that it matches a given XML document if and only if both P and Q match that XML document. Since each XPL document may represent multiple XML documents, P, Q, and R may match more than one XML document. Those skilled in basic mathematical techniques will readily be able to use the semantics above in Table 1 to verify that the intersection results given in Table 2 (below) are indeed intersections by this definition.

In the exemplary embodiment, all corresponding elements in matching fransaction profiles must match (be the same). Otherwise, the transaction profiles are not considered to match. This rule applies recursively to all child elements of all the elements in the profiles except where an <xpl:any_element> wild card in one makes the children of the corresponding element irrelevant. Even if only one pair of corresponding elements does not match, the result is an empty intersection.

As discussed above, the code running on a computer or processor can be used to implement the functions of the matching engine, network interface and server functions. Those skilled in the art will readily apply the teachings and techniques discussed in Table 2 to create computer code in any appropriate computer language for implementing the functionality of the matching process utilized by the transaction system 100.

Table 2

The matching procedure, therefore, determines whether a newly submitted fransaction profile is compared to stored transaction profiles to determine if any of the stored transaction profiles have overlapping limitations using the algorithm above. In other words, the matching engine 314 determines if the stored fransaction profiles meet the fransaction criteria described in the newly submitted fransaction profile. The matching engine could intersect each incoming fransaction profile with all stored profiles and pass all non-empty intersections to the reporting 316 and/or clearing engines 318. Time and resource efficiency, however, may be gained by using indexing techniques to narrow the set of potential matching fransaction profiles. Large categories of irrelevant profiles (i.e. profiles which certainly cannot match) can be eliminated by indexing as described immediately below.

In the exemplary embodiment, the matching engine performs an indexing procedure to efficiently match transaction profiles as follows. One or more indexes allow the group of potential matches to be reduced from the entire collection of stored fransaction profiles to a smaller subset which is a superset of all matches with the particular transaction profile that is under examination. If more than two indexes are used, a small collection is provided either by merging the collections provided by the various indexes (i.e. finding their intersection) or by selecting the smallest collection returned.

Each fransaction profile from this small collection is intersected with the incoming profile. If the intersection is non-empty, this fransaction profile is added to the list of potential match reports to be passed to the reporting 316 and/or clearing engines 318.

The following discussion provides an example relating to the matching of transaction profiles describing resistor transactions. Those skilled in the art will recognize the various extensions and modification to the described process and examples. In the example, the transaction profiles are indexed using a standard free index based on the value of a specific parameter. The. resistance of a resistor is selected from the fransaction profile expressed in XPL using the XML path resistor-sale/ohms. A standard search tree is established that includes branches based on ranges of values of resistor-sale/ohms and lists, within its leaves, all stored transaction profiles with a given value of resistance.

Given an incoming transaction profile with a well defined resistance (i.e. not a wild card), the index can be used to find all the stored transaction profiles with equal resistance. The transaction profiles that have other resistance values are, therefore, eliminated from the group of potential matching transaction profiles where the elimination occurs in a time duration logarithmically related to the number of such non-matching fransaction profiles. This type of index is not useful in the case where many of the stored fransaction profiles (and also the incoming transaction profile) do not have well defined values for resistance but rather have wild cards, ranges or inter-dependence between the resistance and another parameter such as price. The exemplary embodiment has an indexing scheme referred to herein as the semi-lattice scheme. This scheme uses the fact that each transaction profile is, semantically, a set of transactions (i.e. its constraints define the set of transactions which meet those constraints).

For example, the XPL language may have semantics, as discussed above, in which each XML document containing XPL elements either matches or does not match any given XML document without XPL elements ("simple XML") so that each XML document with XPL represents a set of simple XML documents. The exemplary set of semantics discussed above allows concepts from mathematical set-theory to apply. In particular, transaction profiles may be stored at the nodes of a directed acyclic graph (DAG) with the following properties.

Existence of root - there is a single root element which is the transaction profile which represents the set of all transactions (or of all transactions matching the schema of the marketplace)

Ordering - if there is an edge from fransaction profile p to fransaction profile q then p is a superset of q. Uniqueness — no two nodes have the same transaction profile.

Transitive reduction - if a transaction profile p has edges to both q and r then q is not a subset of r.

Completeness - if node p is a superset of node q then there is a path from p to q. Closure - if there are nodes p and q then there is a node with the intersection of p and q.

FIG. 11 is an illustration of an example of the use of indexing. The fransaction profile 1100 describes Smith offering to sell his Blue Ford. All Cars 1102 is the root. The ordering is clearly preserved since every Blue Ford 1104 is a Ford 1106. The nodes are clearly unique. Transitive reduction can be tested. Transitive reduction would be broken if, for example, an edge was added directly from All Cars 1102 to Blue Fords 1104. Completeness may also be checked. Closure is also satisfied since the intersection of Blue Cars 1108 with Fords 1106 (the only pair in which one does not contain the other) is Blue Fords 1104. This structure is suitable for containing fransaction profiles with wild cards which semantically are sets, whereas many traditional indexes such as those found in SQL databases assume that discrete values are being stored.

In order to search for matches with an incoming profile p the following procedure may be followed. First, all children of the root are checked to see if any of them contain p. If so, the children of that element are recursively searched to see if any of them contain p. This is repeated until a node is found which contains p but which has no children which contain p. This is the unique smallest node containing p. The search for matches with p may be limited to the descendents of p since it follows from the axioms that for every node q such that p and q have non-empty intersections, the intersection of p and q exists as a node and is a descendeht of p. In order for this search structure to be effective it may be necessary to create nodes with broad fransaction profiles which effectively group together certain classes of fransaction profiles (e.g. it may be that no buyer 402 or seller is offering all Blue Cars 1208 but such a transaction profile has been added in order to create a DAG structure with bounded branching). Therefore, the transaction confroller 108, coupled within a fransaction management system 100 through a network interface 110, receives a plurality of fransaction profiles submitted by a plurality of market parties 102 through the communication network. 106. Each of the transaction profiles describes one or more acceptable transactions to the market party 102 submitting the fransaction profile and may indicate a level of intended commitment by the market party 102. The transaction confroller 108, using the matching engine 314, matches fransaction profiles by identifying transaction profiles with overlapping limitations. The results of the matches are conveyed to the market parties 102 through a Web browser or email. Transaction profiles describing different levels of commitment may be matched allowing a variety of transactions to be performed.

Clearly, other embodiments and modifications of this invention will occur readily to those of ordinary skill in the art in view of these teachings. Therefore, this invention is to be limited only by following claims, which include all such embodiments and modifications when viewed in conjunction with the above specification and accompanying drawings.

APPENDIX I

<car>

<make> BMW

</make> <color>

Black </co!or> <safety-features>

<air-bags>

2 </air-bags> <anti-lock brakes/> </safety-features>

</car>

Appendix II

BMW </make> <color>

<xpl:choice valuel="Black" value2="Blue'7> </co!or>

<safety-features>

<xpl: any-element-list/> </safety-features> </car>

Appendix III

<resistor-sale> <ohms>

1000 </ohms>

<transaction-parties> <buyer>

<name>

Electronics Procurement Inc </name>

<state>

CA </state> </buyer> <seller>

<xpl: any-element-list/> </se!ler> </transaction-parties> </resistor-sale>

Appendix IV

<resistor-sale> <ohms> <xpl:range min="100" max="10000'7>

</ohms> <price unit="cents">

1.10 </price> <transaction-parties>

<buyer>

<name>

CA </state> </buyer> <seller> <name>

Resistors Inc. </name> <state>

CA </state>

</selIer> </transaction-parties> </resistor-sale> Appendix V <resistor-sale> <ohms>

10000 </ohms>

1.10 </price>

<transaction-parties> <buyer>

<name>

Electronics Procurement Inc </name> <state> CA

</state> </buyer> <seller>

<name> Resistors Inc.

</name> <state>

CA </state> </seller>

</transaction-parties> </resistor-sale> Appendix VI

<gaz-sale xmlns:xpI="http.7/ ww.tradeum.com" xmlns :tpt=" http ://www.tradeum.com">

<tpt:validtill/>

<buyer>

<tpt:originator>

</tpt:originator>

<xpl: any_e!ement/> </parties>

</quantity>

</price>

<xpl: anyelement!ist >

</source> <destination> <state>

<tpt:inserttext field="state">

<tpt:error text="<h2>Please specify your state. Press the Back button to continue.</h2>'7>

</tpt:inserttext> </state> <zip>

<tpt:inserttext field="zip"> <tpt:error text="<h2>Please specify your zip code. Press the Back button to continue.</h2>'7>

</tpt:inserttext> </zip> </destination> <delivery>

<xpl:daterange prefer="down"> <date>

</year> <month>

<tpt:inserttext field="fϊrstmonth'7> </month> <day>

<tpt:inserttext field="firstday'7> </day> </date> <date> <year> <tpt:inserttext field=" lastyear "/> </year> <month>

<tpt:inserttext field=" lastmonth "/> </month>

<day>

<tpt:inserttext field="lastday'7> </day> </date> </xpl:daterange>

</deIivery> <grade>

<tpt:inserttext field="grade'7> </grade> <RVP>

<xpl:range min="tpt:minrvp" max="tpt:maxrvp" prefer="up'7>

</RVP> <MTBE> <xpl:range min="tpt:minmtbe" max="tpt:maxmtbe" prefer="up'7>

</MTBE> <Ethanol>

<xpl:range min="tpt:minethynol" max="tpt:maxethynoI" prefer="up'7>

</Ethanol> </gaz-saϊe>

Claims

What is claimed is:

1. A method comprising: receiving a plurality of transaction profiles from a plurality of market parties through a communication network, each transaction profile of the plurality of transaction profiles comprising one or more limitations to a suggested fransaction, wherein the limitation comprises at least a date or a credit rating as a fransaction attribute of the suggested fransaction; and identifying a group of fransaction profiles, each fransaction profile of the group meeting the limitation of each other transaction profile of the group, wherein at least one transaction profile of the group indicates a different market party commitment level than another fransaction profile of the group.

2. A method in accordance with claim 1, wherein the at least one limitation of a first transaction profile of the group of transaction profiles comprises a plurality of limitations.

3. A method in accordance with claim 2, wherein the first limitation of the first transaction profile of the group of fransaction profiles comprises a first transaction attribute range including at least two values of a transaction attribute, each of the limitations of the other fransaction profiles of the group comprising at least one value of the first transaction attribute range.

4. A method in accordance with claim 3, wherein a second limitation of a second fransaction profile of the group of fransaction profiles comprises a second fransaction attribute range including at least two values of the transaction attribute, wherein the second fransaction attribute range includes at least one value within the first fransaction attribute range.

5. A method in accordance with claim 3, wherein the first limitation is a wild card defining an infinite range of values for the fransaction attribute.

6. A method in accordance with claim 5, wherein the first limitation is a partial wild card defining an infinite range of values excluding at least one value.

7. A method in accordance with claim 4, wherein each transaction profile of the group of transaction profiles comprises a plurality of limitations to the suggested transaction, each limitation of the plurality of limitations of a transaction profile associated with a corresponding limitation of each of the other fransaction profiles of the group and comprising at least one value within the corresponding limitation in each of the other fransaction profiles.

8. A method in accordance with claim 1, wherein the limitation includes the additional fransaction attribute of a price.

9. A method in accordance with claim 1, wherein the limitation includes the additional transaction attribute of quantity.

10. A method in accordance with claim 1, wherein the limitation includes the additional fransaction attribute of a quality indicator.

11. A method in accordance with claim 1, wherein at least one of the transaction attributes is a date.

12. A method in accordance with claim 1, wherein at least one of the transaction attributes is a credit rating.

13. A method in accordance with claim 1, wherein the limitation includes a market party identifier.

14. A method in accordance with claim 13, wherein the market party identifier identifies a submitting market party.

15. A method in accordance with claim 14, wherein the market party identifier is a name of the market party submitting the transaction profile.

16. A method in accordance with claim 13, wherein the market party identifier identifies a market party other than a market party submitting the fransaction profile.

17. A method in accordance with claim 1, further comprising: determining a resulting transaction profile having a limitation defined by the limitations of each of the transaction profiles of the group.

18. A method in accordance with claim 17, wherein the resulting fransaction profile comprises a plurality of limitations, each of the plurality of limitations defined within the limitations of each of the fransaction profiles of the group.

19. A method in accordance with claim 17, further comprising transmitting the resulting fransaction profile to at least one of the market parties of the group.

20. A method in accordance with claim 19, further comprising displaying the resulting transaction profile.

21. A method in accordance with claim 17, wherein each of the plurality of transaction profiles comprises a transaction profile type indicating the level of market party commitment.

22. A method in accordance with claim 21, wherein the fransaction profile type comprises an anonymous search request requesting a search for other fransaction profiles meeting the limitation of the fransaction profile, the fransaction profile type indicating a market party commitment limited to anonymously providing information related to the transaction profile.

23. A method in accordance with claim 21, wherein the transaction profile type comprises a non-anonymous search request requesting a search for other transaction profiles meeting the limitation of the transaction profile, the fransaction profile type indicating a market party commitment limited to providing an identify of the market party submitting the non-anonymous search request and information related to the fransaction profile.

24. A method in accordance with claim 21, wherein the fransaction profile type comprises an offer to enter into a fransaction with another market party submitting another fransaction profile meeting the limitation of the fransaction profile, the transaction profile type indicating a market party commitment to be legally bound to the fransaction.

25. A method in accordance with claim 21, wherein the fransaction profile type comprises an expression of interest to enter into a transaction with another market party submitting another fransaction profile meeting the limitation of the fransaction profile, the transaction profile type indicating a market party commitment to continue to a next level of negotiation with the another market party.

26. A method comprising: receiving a plurality of fransaction profiles from a plurality of market parties through a communication network, each fransaction profile of the plurality of transaction profiles comprising a limitation to a suggested fransaction, wherein the limitation comprises at least a date or a credit rating as a fransaction attribute of the suggested fransaction; and identifying a group of fransaction profiles comprising: a first transaction profile indicating a first level of commitment of a first market party submitting the first transaction profile; and second fransaction profile indicating a second level of commitment of a second market party submitting the second fransaction profile, the first transaction profile having a first limitation meeting a second limitation of the second fransaction profile.

27. A transaction server comprising: a network interface adapted to receive a plurality of transaction profiles through a communication network from a plurality of market parties, each fransaction profile of the plurality of fransaction profiles comprising a limitation to a suggested fransaction, wherein the limitation comprises at least a date or a credit rating as a transaction attribute of the suggested fransaction; and a fransaction confroller coupled to the network interface, the fransaction confroller adapted to identify a group of fransaction profiles, each transaction profile of the group meeting the limitation of each other transaction profile of the group, wherein at least one fransaction profile of the group indicates a different market party commitment level than another fransaction profile of the group.

28. A transaction server in accordance with claim 27, wherein a limitation of a first transaction profile of the group of fransaction profiles comprises a plurality of limitations.

29. A transaction server in accordance with claim 28, wherein the first limitation of the first transaction profile of the group of transaction profiles comprises a first transaction attribute range including at least two values of a fransaction attribute, each of the limitations of the other fransaction profiles of the group comprising at least one value of the first fransaction attribute range.

30. A fransaction server in accordance with claim 29, wherein a second limitation of a second fransaction profile of the group of fransaction profiles comprises a second transaction attribute range including at least two values of the fransaction attribute, wherein the second transaction attribute range includes at least one value within the first i fransaction attribute range.

31. A fransaction server in accordance with claim 29, wherein the first limitation is a wild card defining an infinite range of values for the transaction attribute.

32. A fransaction server in accordance with claim 29, wherein the first limitation is a partial wild card defining an infinite range of values excluding at least one value.

33. A transaction server in accordance with claim 31, wherein each fransaction profile of the group of fransaction profiles comprises a plurality of limitations to the suggested transaction, each limitation of the plurality of limitations of a fransaction profile associated with a corresponding limitation of each of the other fransaction profiles of the i group and comprising at least one value within the corresponding limitation in each of the other fransaction profiles.

34. A transaction server in accordance with claim 33, wherein the limitation includes the additional transaction attribute of a price.

35. A fransaction server in accordance with claim 33 wherein the limitation includes the additional fransaction attribute of quantity.

36. A transaction server in accordance with claim 33, wherein the limitation includes the additional fransaction attribute of a quality indicator.

37. A method in accordance with claim 33, wherein at least one of the transaction attributes is a date.

38. A method in accordance with claim 33, wherein at least one of the fransaction attributes is a credit rating.

39. A transaction server in accordance with claim 33, wherein the limitation includes a market party identifier.

40. A fransaction server in accordance with claim 39, wherein the market party identifier identifies a submitting market party.

41. A fransaction server in accordance with claim 40, wherein the market party identifier is a name of the market party submitting the fransaction profile.

42. A fransaction server in accordance with claim 39, wherein the market party identifier identifies a market party other than a market party submitting the fransaction profile.

43. A transaction server in accordance with claim 27, further comprising: determining a resulting fransaction profile having a limitation defined by the limitations of each of the transaction profiles of the group.

44. A transaction server in accordance with claim 43, wherein the resulting fransaction profile comprises a plurality of limitations, each of the plurality of limitations defined within the limitations of each of the fransaction profiles of the group.

45. A fransaction server in accordance with claim 43, further comprising transmitting the resulting fransaction profile to at least one of the market parties of the group.

46. A transaction server in accordance with claim 44, further comprising displaying the resulting transaction profile.

47. A fransaction server in accordance with claim 44, wherein each of the plurality of fransaction profiles comprises a transaction profile type indicating the level of market party commitment.

48. A fransaction server in accordance with claim 46, wherein the fransaction profile type comprises an anonymous search request requesting a search for other transaction profiles meeting the limitation of the fransaction profile, the fransaction profile type indicating a market party commitment limited to anonymously providing information

> related to the transaction profile.

49. A transaction server in accordance with claim 46, wherein the fransaction profile type comprises a non-anonymous search request requesting a search for other fransaction profiles meeting the limitation of the fransaction profile, the fransaction profile type indicating a market party commitment limited to providing an identity of the market

5 party submitting the non-anonymous search request and information related to the fransaction profile.

50. A transaction server in accordance with claim 46, wherein the transaction profile type comprises an offer to enter into a fransaction another market party submitting another fransaction profile meeting the limitation of the fransaction profile, the fransaction profile type indicating a market party commitment to be legally bound to the fransaction.

51. A transaction server in accordance with claim 46, wherein the transaction profile type comprises an expression of interest to enter into a transaction with another market party submitting another fransaction profile meeting the limitation of the fransaction profile, the fransaction profile type indicating a market party commitment to continue to a next level of negotiation with the another market party.

52. A graphical user interface providing a communication interface between a market party and a fransaction server, wherein the transaction server is adapted to receive a plurality of fransaction profiles, each fransaction profile comprising information submitted through the graphical user interface, the graphical user interface comprising: a fransaction attribute field adapted to accept a transaction attribute chosen by the market party, the fransaction attribute describing at least one limitation to a suggested fransaction, wherein the limitation comprises at least a date or a credit rating as a transaction attribute of the suggested fransaction; and a transaction profile type field adapted to accept a fransaction profile type indicating a level of commitment of the market party to the suggested fransaction.

53. A graphical user interface in accordance with claim 52, wherein the transaction profile type comprises an anonymous search request requesting a search for other fransaction profiles meeting the limitation of the fransaction profile, the fransaction profile type indicating a market party commitment limited to anonymously providing information related to the transaction profile.

54. A graphical user interface in accordance with claim 52, wherein the transaction profile type comprises a non-anonymous search request requesting a search for other transaction profiles meeting the limitation of the transaction profile, the transaction profile type indicating a market party commitment limited to providing an identity of the market party submitting the non-anonymous search request and information related to the transaction profile.

55. A graphical user interface in accordance with claim 52, wherein the fransaction profile type comprises an offer to enter into a fransaction another market party submitting another transaction profile meeting the limitation of the fransaction profile, the fransaction profile type indicating a market party commitment to be legally bound to the fransaction.

56. A graphical user interface in accordance with claim 52, wherein the fransaction profile type comprises an expression of interest to enter into a fransaction with another market party submitting another transaction profile meeting the limitation of the fransaction profile, the fransaction profile type indicating a market party commitment to continue to a next level of negotiation with the another market party.