WO2002023451A1

WO2002023451A1 - Apparatus, system and method for forming resulting transaction profiles

Info

Publication number: WO2002023451A1
Application number: PCT/US2001/029023
Authority: WO
Inventors: M. Zvi Schreiber; Amit Gal
Original assignee: Vert Tech LLC
Current assignee: Vert Tech LLC
Priority date: 2000-09-18
Filing date: 2001-09-18
Publication date: 2002-03-21
Anticipated expiration: 2003-03-18
Also published as: AU2001291035A1

Abstract

A transaction server (112) receives a plurality of transaction profiles (802, 804) from a plurality of market parties (102) through a communiction network (106), where each of the transaction profiles can include any number of limitations (518) to a suggested transaction or transactions acceptable to the market party submitting the transaction profile. The tansaction server calculates at least one resultant limitation by applying a combination rule to a set of associated limitations pertaining to a particular transaction attribute or attributes (212, 214). One or more resultant transaction profiles (1206) are formed that includes at least one resulting transaction limitation calculated for a set of associated limitations. The transaction server (112), therefore can receive any number of transaction profiles that represent one or more transactions acceptable to the market parties represented by the particular resulting transaction profile.

Description

APPARATUS, SYSTEM AND METHOD FOR FORMING RESULTING TRANSACTION PROFILES

RELATED PATENT APPLICATIONS

This is a continuation-in-part of Application Number 09/643,361 entitled "Apparatus, System And Method For Managing Transactions Between Market Parties From Multiple Market Party Classes" filed on August 22, 2000 which is a continuation-in-part of Application Number 09/573,711, entitled "Apparatus, System and Method for Managing Transaction Profiles Representing Different Levels of Market Party Commitment", filed on May 18, 2000, which is a continuation-in-part of Application Number 09/564,164, entitled "Apparatus, System And Method For Managing Transaction Profiles Representing Different Levels Of Market Party Commitment", filed on May 03, 2000. This application is related to Application Number 09/628,539 entitled

"System, Apparatus And Method For Providing A Transaction Management Markup Language" filed on July 31, 2000 which is incorporated by reference herein and is a continuation-in-part of Application Number 09/573,711 , entitled "Apparatus, System and Method for Managing Transaction Profiles Representing Different Levels of Market Party Commitment", filed on May 18, 2000, which is a continuation-in-part of Application Number 09/564,164, entitled "Apparatus, System And Method For Managing Transaction Profiles Representing Different Levels Of Market Party Commitment", filed on May 03, 2000.

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, and 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 systems 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 cannot 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 a 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 is configured to receive a plurality of transaction profiles where each transaction profile can include any number of limitations and can represent either a single or several suggested transactions acceptable to the market party submitting the particular transaction profile. By applying a combination rule to a set of limitations associated with a transaction attribute, the transaction server calculates a resulting limitation associated with the transaction attribute. The transaction server forms any number of resultant transaction profiles that include the resulting limitations. A resultant transaction profile at least partially defines any number of resultant transactions that meet the limitations of the transaction profiles represented by the limitations combined to form the resulting limitations of the resultant transaction profile.

Therefore, the transaction server can receive transaction profiles having any number of limitations to one or more suggested transactions as defined by the submitting market party submitting the particular transaction profile. One or more combination rules are applied to the limitations to form transaction profiles having resulting limitations and at least partially defining one or more suggested transactions.

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.

FIG. 12 is a flow chart of a method of identifying groups of transaction profiles submitted from a plurality of market parties belonging to three or more market party classes in accordance with the exemplary embodiment of the invention.

FIG. 13 is a flow chart of an exemplary optimization method.

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 techniques 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.

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 a 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 defined by 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. Further, a limitation may be a market party characteristic of a potential trading market party (102). Examples of market party characteristics that may be used as limitations to transactions include credit ratings, geographical locations, company size, number of offices, and amount of annual revenue. Other market party characteristics will readily occur to those skilled in the art.

A limitation can designate a single value or may be a multiple value limitation representing more than one value, symbol or string. One type of multiple value limitation is a range of values or numbers. Examples of other multiple value limitations include wild-cards and partial wild-cards. A partial wild-card multiple value limitation may represent an infinite set of values where one or more values are excluded. A wild-card multiple value limitation can express that any value, string or symbol is acceptable. In other words, a wild-card multiple value limitation does not limit the transactions in the traditional sense and limits a transaction by conveying that any value is acceptable to the submitting market party. The transaction server is configured to receive a plurality of transaction profiles that can include any number of limitations to a suggested transaction as defined by the submitting market party. After receiving the transaction profiles, the transaction controller 108 identifies at least two transaction profiles that have limitations meeting the other identified transaction profiles. Limitations corresponding to a particular transaction attribute are referred to as associated limitations where a set of associated limitations relate to a particular transaction attribute. Each limitation of a set of associated limitations is submitted within a separate transaction profile. Since a resulting transaction profile may be based on several transaction profiles, a set of associated limitations may include any number of limitations, each from a different transaction profile. Any one limitation may belong to one or more sets of associated limitations. For example, a limitation related to a shipping cost offer by' a carrier may belong to a set of associated limitations pertaining to the transaction attribute of a shipping cost where a buyer is specifically defining an acceptable shipping cost. The shipping cost limitation defined by the carrier can also belong to a set of associated limitations related to a total buyer cost where the set includes seller price, total buyer cost and shipping charges in a multiparty transaction. This example also demonstrates that each of the transaction profiles may be submitted by a market party belonging to a different market party class (also referred to as a market party classification).

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. In the exemplary embodiment, 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 transaction profiles having a wide variety of formats. The transaction profiles may describe search requests, expressions of interest to participate in a suggested transaction or a group of transactions (soft match), or may be firm offers to enter into a transaction if the limitations are met.

Several types of combination rules may be applied to the limitations to identify matching transaction profiles. One example of a suitable combination rule involves logically intersecting the sets of transactions defined by the limitations and the transaction profiles. Since any received transaction profile can represent one or more suggested transactions, each transaction profile defines a set of transaction profiles where the set can include a single transaction, a limited number of transactions or an infinite set of transactions. As explained below in further detail, a transaction profile may represent multiple transactions where a limitation includes a range of values, a partial wild-card or a wild-card. When the sets of transactions represented by the transaction profiles are intersected, a resulting transaction set is formed that may include any number of resulting transactions having resulting limitations. The resulting limitations meet each of the limitations of the transaction profiles included in the match. Each transaction profile, therefore, defines a set of attributes related to one or more suggested transactions defined by the submitting market party. Accordingly, a resulting transaction profile may have resulting limitations directed to any number of transaction attributes and may represent any number of resulting suggested transactions. Further each resulting limitation directed to a specific attribute may define any number of values, strings or symbols associated with the specific attribute.

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 wire-line 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 simultaneously 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 IBM. 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 from the browser to the Web server (HTTP POSTs) and can be analogized to a Java applet running on a 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 114 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 (114) may be through the Object Database Management Group (ODMG) Application Program Interface or vendor specific interfaces and access to relational databases (114) 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 114 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 linking 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, T1 lines, Ethernet connections, and any other digital or analog communication interface suitable for exchanging information between the local processor 104 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 a 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 102 has automated procurement or sales such as ERP software the communication with market party 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 in 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 an HTTP POST command and Transfer Control Protocol/Internet Protocol (TCP/IP) 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 market 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.

The transaction profile form includes at least two attribute fields where each attribute field corresponds to a unique market party class. Examples of market party classes include buyers, sellers, carriers (shippers), insurers, underwriters, financiers, and packagers. As those skilled in the art will recognize, the various market parties 102 can be defined in an almost unlimited way and the number and types of market party classes will depend on the particular industry, anticipated transactions and transaction management system 100. Therefore, a plurality of transaction profiles are received from a plurality of market parties 102 belonging to a plurality of market party classes at a transaction controller 108 through a communication network 106. The transaction controller 108 identifies at least three 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; and/or information regarding the other transaction profile limitations. If the identified transaction profiles are firm offers, the market parties 102 are committed to a transaction. Otherwise, the market parties 102 may use the transaction information to continue pursuing an agreement with the market parties 102 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 of 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 102 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. Each market party designator 210 is uniquely associated with a market party class. Therefore, examples of market party designators 210 include a buyer, seller,- carrier, financier, insurer, underwriter and packager designators. Depending on the particular market, the market party designator 210 may have different, 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 2 6, 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.

A transaction term may be directed to a single market party class or multiple market party classes. For example, a quantity 214 transaction term submitted by a submitting market party 102 may affect the requirements of more than one market party 102 of the transaction where the affected market parties 102 belong to different market party classes. If the submitting market party 102 is seller (404) offering a product at a particular quantity and the transaction involves a carrier (406) and a buyer (402), the quantity term pertains to each of the market parties' 102 requirements. The buyer (402) must be willing to buy the product in the particular quantity and the carrier (406) must be willing to ship the particular quantity that the seller (404) will sell and the buyer (402) will buy. Any transaction term may correspond to any number of market party classes. If an insurer (406) is involved in the transaction, for example, the quantity term will likely affect the requirement of the insurer (406). The willingness of the insurer (406) to enter into an agreement for a particular fee will depend on the potential for loss, the value of the total product shipped and therefore, the quantity.

A transaction term may be directed to single market party class. For example, a quality term may be relevant to a buyer (402) and seller (404) and will not change the requirements of a carrier (406). 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 transaction 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.

In the exemplary embodiment, a unique transaction profile form associated with a market party class. Accordingly, a buyer transaction profile template 200 is used to create a buyer transaction form which is submitted only to market parties 102 belonging to the buyer class. Sellers, carriers and other receive transaction profiles forms associated with their market party class. 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 transaction 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 II, 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 transaction 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 transaction 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 (transaction profile), at least some details of the other identified transaction profiles, explore alternate transaction 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 transaction 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 transaction 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 transaction 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 III, the buyer transaction profile specified by a fictitious company, "Electronics Procurement Inc.," indicates the resistors required, the identity of the buyer 402 and specifies the seller 404 as a wild-card indicating that the buyer 402 will work with any seller 404. 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 402 in California.

By including details of buyer 402 and seller 404 as parameters of the transaction, the same wild-cards which are used to match product parameters may be used by buyers 402 and sellers 404 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 resulting limitations which are specific values for quantity 214, buyer 402 and seller 404 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 306, 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 306 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 200 and provides the market party 102 with a vehicle for providing the transaction profile since the completed transaction 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 arrangements will be readily apparent to those skilled in the art.

The market party 102 enters the appropriate information to express the suggested transaction to form a completed transaction profile form 310. The completed transaction profile form 310 is information to be included in the transaction profile in an HTTP POST format that is transmitted 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 transaction 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 transaction 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 transaction 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 transaction.

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 have flexibility in some parameter, the intersection may still be flexible. For example, if the seller 404 offered delivery dates between the 12^th and 15^th and the buyer 402 specified a delivery date between the 10^th and 14^th then any date between the 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 transaction 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 transaction 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 that contains resulting limitations based on all transaction profiles of the 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 02 that have submitted matching transaction profiles and the transaction attributes from the transaction profiles including transaction terms such as price 212, quantity 214, catalog numbers 220, 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 an XSLT 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 1 10 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 transaction 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 transaction management 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 market parties 102 which pay-fixed and receive-fixed. In the exemplary embodiment, the transaction controller 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 transaction 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 212, quantity 214 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 transaction form by accessing the URL of the form through the home Web page of the transaction management service provider. The network interface 1 10 provides a transaction profile form 500 as an HTML Web page using HTTP techniques. In the exemplary trading scenario, a separate transaction form is provided to the buyer 402, seller 404 and the carrier (transaction enabler) 406 where each form utilizes a different transaction profile template 200. FIG. 5 is a pictorial representation of a buyer transaction profile form (buyer form) 500 in accordance with the exemplary embodiment of the invention. The buyer form 500 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 5,10 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 pulldown 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 transaction server 1 12. The buyer 402 will receive updates reporting any new matching transaction profiles submitted during the pending period of the transaction 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 buyer transaction profile form 500 to the network interface 110 when the buyer transaction profile form 500 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 transaction that the seller 404 intends to submit. In the exemplary embodiment, the seller 404 may choose 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 transaction 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 seller transaction profile form 600 to the network interface 110 when the seller transaction profile form 600 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-salβ xmlns :xpl="http: //www. tradeum.com" xmlns: pt="http: //www. tradeum. co " >

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.

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

<partiβs>

<buyβr>

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 controller such as the network controller's IP address, a local handle for the user or a random request ID.

</tpt : originator>

The following line marks the level of commitment which the market party 102 is expressing to the transaction profile. The command tpt:inserttext is a template command which represents a value to be filled in by the submitting market party 102 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.

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

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> <source>

<tpt:inserttext field=^π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 tptiinsertext. 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>"/>

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

<tpt: inserttext field="zip">

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

</tpt : inserttext> </zip>

</destination> <delivery>

The "xpl : daterange" 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 minimum 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 transaction information. A submit button 728 allows the carrier (406) to submit the carrier transaction profile form 700 to the network interface 110 when the carrier transaction profile form 700 has been completed.

The network interface 110 extracts the appropriate information form each field in each transaction profile (500, 600, 700) received and enters the information into a transaction template corresponding to the type of transaction 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 transaction 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 802. Information contained within the HTML seller form 600 is placed within an XML template to create an XML seller transaction profile 804. A carrier XML transaction profile 808 is formed using the HTML carrier form 700. The XML transaction forms are received at the transaction 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 non-empty intersections. The transaction controller 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 transaction 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 trading scenario. In the exemplary scenario of a three way match, the transaction controller 108 preferably stores not only submitted transaction profiles but also two-way matches already 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 transaction profiles 810. Carrier transaction profiles 808 are matched with seller transaction profiles 804 and stored as seller-carrier combination transaction 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 transaction 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 transaction profile representing its intersection with a compatible transaction 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 transaction 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 transaction 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 transaction information 918 corresponding to the transaction profiles submitted by three market parties 102; a buyer 402, a seller 404, and a carrier (406). The type of transaction 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 1 12 receives a request for a transaction profile form 306. The network interface 110 receives a request for a transaction profile form 306. As described above, the market party 102 submits a request for the transaction profile form 306 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 1 10 transmits a Web page to the local processor 104. The Web page is a transaction profile form 306 having at least one transaction that the market party 102 can modify or use to describe a transaction term or other parameter.

The transaction server 1 12 receives the transaction profile at step 1006. The network interface 1 10 receives the completed transaction profile form 306 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 instantiating a transaction profile template 200. The values and wildcards 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 transaction controller 108. The XML template containing the extracted information is received by the transaction controller 108 from the network interface 1 10.

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 transaction controller 108 analyzes the limitations as described by 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 transaction 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 transaction profile or details therefrom. In the exemplary embodiment, the transaction profile result vector lists all non-empty intersections. Provided that details of the submitting market parties 102 are included within the transaction profile (e.g. buyer 402 specified himself as buyer 402 and wildcards seller and seller 404 specified himself as seller 404 and wild-cards buyer) after intersection details of both market parties 102 appear in the intersection result.

At step 1018, the transaction profile result vector is converted into an HTML formatted transaction information Web page 600.

At step 1020, the transaction information Web page 600 is transmitted 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 transaction but 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_e!ement/> 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 profiles expressed in XPL that have overlapping limitations (intersect). The result of the match is a new resulting transaction profile, which represents the intersection of the original transaction 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 (transaction 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 transaction 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 314, network interface 110 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 transaction 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 transaction profiles meet the transaction criteria described in the newly submitted transaction profile. The matching engine 314 could intersect each incoming transaction 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 transaction 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 314 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 transaction 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 transaction profile from this small collection is intersected with the incoming profile. If the intersection is non-empty, this transaction profile is added to the list of potential match reports to be passed to the reporting engine 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 tree index based on the value of a specific parameter. The resistance of a resistor is selected from the transaction 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 transaction profiles.

This type of index is not useful in the case where many of the stored transaction 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 transaction profile p to transaction 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 transaction 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 transaction 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 descendent of p.

In order for this search structure to be effective it may be necessary to create nodes with broad transaction profiles which effectively group together certain classes of transaction profiles (e.g. it may be that no buyer 402 or seller 404 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 controller 108, coupled within a transaction management system 100 through a network interface 1 10, receives a plurality of transaction 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 transaction profile and may indicate a level of intended commitment by the market party 102. The transaction controller 108, using the matching engine 314, matches transaction profiles by identifying transaction profiles with overlapping limitations. Each of the transaction profiles may correspond to a different market party class. Accordingly, a potential transaction can be formulated based on the transaction profiles submitted by market parties 102 from more than two market party classes. 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.

FIG. 12 is a flow chart of a method of identifying groups of transaction profiles submitted from a plurality of market parties (102) belonging to three or more market party classes. At step 1202, the transaction controller 108 receives a plurality of transaction profiles submitted by market parties (102) belonging to at least three different market party classes. Several market parties (102) from each market party class may submit transaction profiles which are processed as described above and stored in the database 114. At step 1204, the transaction controller 108 identifies a group of transaction profiles where each transaction profile of the group meets the limitations of each of the other transaction profiles of the group. Any number of methods can be used to provide the transaction controller with the transaction profile information. For example, if a transaction requires three market parties 102 and a match is found with two of the parties, the two party match can be retrieved from the database 114 and compared to a recently submitted transaction profile from the third market party class.

Each transaction profile can have any number of limitations defining one or more potential (suggested) transactions. The limitations may be transaction attributes such as price 212, quantity 214, delivery date, identity of party, characteristic of party or any other transaction attribute as described above. If the transaction profile includes one or more limitations that define a range, wild-card or other plurality of values, the transaction profile describes more than one potential transaction. Each transaction profile of the group meets all the limitations of each of the other transaction profiles if none of the limitations are inconsistent with the corresponding limitations in the other transaction profiles. If a particular limitation of a transaction profile provides an acceptable range to a particular transaction attribute, the corresponding limitation in each of the other transaction profiles must have at least one value in common with the limitation. In other words, each limitation must overlap with every other associated limitation of the transaction profiles of the group.

At step 1206, a resulting transaction profile 900 is formed for each group of transaction profiles. Each resulting transaction profile 900 may have any number of limitations where each limitation may define a single value, a range of values, or an infinite number of values using a range, wild-card or partial wild-card. In the exemplary embodiment, a resulting transaction profile 900 includes an aggregate limitation when limitations of two or more market parties 102 are combined to meet the limitation of another market party 102. Since each of the limitations is dependent on the other associated limitations, each limitation is a combination of the other limitations. For example, the maximum purchase price specified by a buyer 402 must be greater than the sum of the selling price of the seller 404 plus the carrier fee for shipping the product. The aggregate limitation in this case could be defined as the sum of the carrier and seller limitation, if defining the transaction from the point of view of the buyer 402. The aggregate limitation could also be the difference between the buyer's maximum purchase price and the carrier fee if looking at the transaction from the seller's 404 point of view. Accordingly, an aggregate limitation is defined as the combination of limitations of transaction profiles submitted by market parties 102 other than the submitting party, where the submitting party is the party intended to receive information regarding the resulting transaction profiles. An aggregate limitation is, therefore, observed from the view point of the submitting market party 102.

The aggregate limitation meets the associated limitation of the submitting party. Continuing with the example provided immediately above, if the buyer 402 is the submitting market party 102, the maximum purchase price is the limitation associated with the aggregate limitation and the aggregate limitation is the sum of the seller's 404 minimum price and the carrier's minimum price. If all three market parties 102 are included in a resulting transaction profile 900, the buyer's 402 maximum purchase price is greater than the aggregate limitation.

At step 1208, the resulting transaction profiles 900 are prioritized using an optimization function. An exemplary method of performing the optimization procedure is discussed below in reference to FIG 13.

At step 1210, transaction information is presented to the market parties 102 by transmitting and displaying at least an indication that matching transaction profiles have been identified. In the exemplary embodiment, optimization information is displayed to the market party 102 in accordance with market party class of the particular market party 102 receiving the optimization information. The transaction information can be displayed any number of ways and may omit or include various information depending on the particular market party 102 receiving the information, the market, the type of transaction or any other appropriate factor. The optimization information may include a prioritized list of resulting transaction profiles 900 ranked in accordance with the optimization function, a single resulting transaction profile 900 determined to be the best combination for the particular market party 102 or a prioritization of individual resulting transactions which may be defined by any number of resulting transaction profiles 900. The examples immediately below illustrate some of these scenarios.

For the following examples, three market parties 102 are required for a particular transaction including a buyer 402, a seller 404 and a transaction enabler 406. In the interest of simplicity, the following scenarios focus on the transactions from the perspective of the buyer 402. The buyer 402 submits a transaction profile including several limitations that define several acceptable values allowing the transaction profile to describe several acceptable (suggested) transactions. Several sellers 404 and several transaction enablers 406 each submit a transaction profile defining more than one suggested transaction. The transaction controller 108 identifies several resulting transaction profiles 900 where each resulting transaction profile 900 involves a different pair of sellers 404 and transaction enablers 406. In one scenario, a prioritization list of resulting transaction profiles 900 is formed based on the optimization function which is defined to minimize the total purchase price to the buyer 402. The resulting transaction profiles 900 are ranked based on the most attractive potential transaction defined by the resulting transaction profile 900. For example, a resulting transaction profile 900 may include a limitation defining a range of total costs to the buyer 402 to enter into a transaction based on a selling price and a delivery cost associated with a single seller 404 and single transaction enabler 406. Another resulting transaction profile 900 may have a similar limitation defining a different range of total costs associated with the buyer 402 for a different seller 404 and transaction enabler 406 combination. The resulting transaction profiles 900 are ranked based on the lowest possible associated cost to the buyer 402. The prioritization list is displayed to the buyer 402 without indicating the particular transaction defined by each resulting transaction profiles 900 that resulted in the particular ranking order.

In a second scenario, the individual transactions defined by each of the resulting transaction profiles 900 is used to form a prioritization list of potential transactions which is displayed to the buyer 402. In this scenario, the buyer 402 does not receive a list of the resulting transaction profiles 900 but receives a list of the optimum transactions offered by all of the resulting transaction profiles 900.

In another scenario, a single transaction offering the most attractive terms is displayed to the buyer 402. Various other scenarios can be addressed and different information and combinations of information can be displayed to each of the market parties (102).

In the exemplary embodiment, the system 100 performs an optimization procedure that calculates an optimum transaction scenario for a particular market party 102. The optimum transaction for a market party 102 may not necessarily be the combination of the transaction profiles providing the best set of transaction terms as observed on an individual transaction profile basis. For example, if a buyer 402 is willing to purchase 100 units at a price of 3 dollars per unit including shipping cost for a delivery schedule of three days to Los Angeles, the optimum transaction may not be the combination of the carrier 406 offering the lowest cost and shortest delivery schedule coupled with the seller 404 providing the product at the lowest cost. For this example, Company X in Chicago offers to sell 100 units for $1.90/unit and Company Y in New York offers to sell the units for $1.50 per unit. Further, Company X will guarantee that the units will be ready for shipping within 2 days and Company Y will guarantee that the products will be ready for shipping within one day. Carrier A will provide shipping from anywhere in the U.S. to Los Angeles for $1.50/unit and will guarantee delivery within 2 days. Carrier B also will providing shipping from anywhere in the US to Los Angeles for 1.50 with a guaranteed delivery of 2 days. Carrier B, however, has a distribution hub in Chicago and will provide shipping from Chicago to Los Angeles for $1.00 and will guarantee delivery within 1 day from the time a shipment is picked up in Chicago. Therefore, in this case the buyer 402 could obtain the best overall deal by purchasing the products from Company X even though the selling price per unit is more than the selling price of Company Y. If the units are purchased from company Y, the units can be delivered by either Carrier A or Carrier B within three days since the Company Y will provide units for shipping within 1 day and both carriers can deliver the units within two days resulting in a total cost per unit of $3.00. If the units are purchased at the higher price from Company X in Chicago, however, the total cost per unit including the Carrier B shipping charge is only $2.90. The optimization procedure is based on an optimization function that may include one or more parameters such as transaction terms or transaction attributes. The optimization function may be an industry standard optimization function accepted by the particular market or may be a function specified by the market party 102 (submitting market party) that will receive the prioritization list of the transaction profiles. For example, the buyer 402 may provide an optimization function specifying that the total cost of the transaction be minimized. Also an industry standard optimization function may provide that the total cost to a buyer 402 be minimized to provide a prioritized list of transaction profiles to a buyer 402. The potential optimization functions are almost limitless and other examples include ranking the potential transactions based on delivery date, minimum quantity that can be sold and delivered or a total cost to a buyer 402 based on insurance, carrier charges, and financing costs. A group of transaction profiles may be ranked differently based on the market party 102 that will receive the results. Accordingly, the same combinations of matching transaction profiles may be prioritized differently for each market party 102 of the potential transactions. .

FIG. 13 is a flow chart of an exemplary optimization method for performing step 1206 of FIG 12. The method is performed at the transaction server 112 in the exemplary embodiment. At step 1302, the transaction server 112 obtains a set of resulting transaction profiles 900 corresponding to a submitting market party transaction profile. The procedure for obtaining the resulting transaction profiles 900 is performed in accordance with the techniques discussed above. At step 1304, the calculates the resulting values for each of the transaction terms for each of the resulting transaction profiles (900). Each combination of transaction terms associated with a potential transaction is applied to an algorithm designed to evaluate the combination of terms and produce a value indicating a transaction term value or a desirability of entering into a transaction. Various methods and optimization functions can be used to determine a particular resulting transaction value or indicator. The appropriate method will depend on the particular industry, transaction value and system 100 and will readily occur to those skilled in the art. For example, if the transaction value that is to be optimized for the buyer 402 is price 212, the various cost values for the seller 404 and transaction enablers 406 are added to produce a total cost to the buyer 402.

Although various methods can be used to facilitate the submission of transaction profiles that result in the optimization of resulting transaction profiles 900, an exemplary technique allows the aggregation of limitations submitted using XPL elements. The following example includes a transaction involving a buyer 402, seller 404 and a carrier 406. The seller 404 indicates a minimum of the seller's 404 price and wild-cards (i.e. allows any value) for the transport price. The carrier 406 specifies a wild-card for the seller's 404 price and indicates a minimum on the transport price. The buyer 402 specifies a maximum on the sum of the buyer's 402 price plus the seller's 404 price. An XPL element, <sum max="nnn7>, included in the transaction profile matches any element whose grandchildren are numbers adding up to less than nnn. The seller 404 submits a transaction profile including the following.

<price>

<seller-price> <range min="mmm"/> </seller-price> <transport-price> <xpl:any-element/> </transport-price>

</price>

The seller 404 submits a transaction profile including the following. <price>

<seller-price> <xpl:any-element/> </seller-price> <transport-price> <range min="mmm"/> </transport-price>

</price>

The buyer 402 submits a transaction profile including the following.

<pπce>

<buyer-price> <sum max="nnn"/> </buyer-price> </price>

The resulting transaction profiles 900 involving the buyer 402 will include all combinations of seller 404 and carrier transaction profiles 808 resulting in a total buyer price less than nnn. Other examples include similar specifications for shipping date, transit time and delivery date. Another example arises when the buyer 402 and seller 404 are using different currencies and transaction enabler 406 provides a currency conversion service.

The results to the buyer 402 can be presented by combining the two prices to show only a total cost to the buyer 402. The carrier 406 can be presented with a price equal to the difference between the buyer sum maximum and the seller's 404 price to indicate the spread available to cover the transportation.

At step 1306, the resulting transactions are prioritized based on one or more transaction terms. The transaction terms may be predetermined terms as appropriate for the particular industry or may be terms identified by the submitting market party 102. For example, the transaction server 112 may prioritize the resulting transaction profiles 900 related to a buyer's 402 transaction profile submission based on a total price per unit and on delivery date. The resulting transaction profiles 900 describing an overall lowest price will be identified as having highest priority. The buyer 402 may also provide optimization term corresponding to a transaction term that should be minimized or maximized to obtain the highest priority (optimum) transaction profile. The buyer 402, for example may wish to have the resulting transaction profile 900 prioritized in order of earliest delivery date. Further, any combination of market party optimization terms and predetermined optimization terms may be used to form a prioritized list of resulting transaction profiles 900.

At step 1308, the optimum resulting transaction profile 900 is sent to the market party 102. In the exemplary embodiment, a prioritized list of resulting transaction profiles 900 is sent allowing the market party 102 to view the entire list. A single optimum resulting transaction profile 900 can be transmitted to the market party 102 in place of a list. The resulting information is transmitted as discussed above and the appropriate mechanism for transmission will depend on the market party 102 and the time the transaction profile was submitted. Therefore, transaction profiles are received from a plurality of market parties

102 belonging to at least three different market party classes at the transaction controller 108. Resulting transaction profiles 900 are formed by matching the transaction profiles submitted from each class. A resulting transaction profile includes an aggregate limitation when transaction profiles submitted by two or more market parties 102 belonging to different market party classes are combined to form the aggregate limitation associated with a limitation included in a transaction profile of a submitting market party 102. The aggregate limitation meets the limitation of the submitting market party 102. An optimization function is performed by applying an algorithm to the potential suggestions defined by the resulting transaction profiles 900. A prioritization list is transmitted and displayed to the submitting market party 102.

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 the 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 </color> <safety-features>

<air-bags>

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

</car>

Appendix II

BMW </make> <color>

<xpl: choice valuel="Black" value2="Blue"/> </color>

<safety-features>

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

Appendix III

<resistor-sale> <ohms>

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

1.10 </price>

<transaction-parties> <buyer>

<name>

Electronics Procurement Inc </name> <state> CA </state> </buyer> <seller>

Appendix IV

<rβsis or-sale> <ohms> <xpl: range min="100" max="10000"/>

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

1.10 </price> <transaction-parties>

<buyer>

<name>

<xpl:any-element/> </name> <state>

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

Resistors Inc. </name> <state> CA </state>

</seller> </transaction-parties> </resistor-sale>

Appendix V <resistor-sale> <ohms>

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

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 :xpl="http: //www. tradeum. com" xmlns: tpt="http: //www. radeum. com" >

<buyer>

</tpt : originator>

<price>

<xpl: range min="0" max=" tpt: price" prefers "down" />

</price> <source> <xpl:anyelementlist/>

</source> <destination> <state>

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

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

<tpt: inserttext field="zip">

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

<year>

</year> <month>

</month> <day>

</day> </date> <date>

<year>

</year> <month>

</month> <day>

<tpt: inserttext fields" lastday"/>

</day> </date> </xpl:daterange>

</delivery> <grade>

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

<xpl: range min="tpt :minrvp" maχs"tpt :maxrvp" prefers "u "/>

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

</MTBE> <Ethanol>

<xpl: range mins"tpt :minethynol" max="tpt :maxethynol" prefer="up"/> </Ethanol> </gaz-sale>

Claims

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 any number of limitations to a suggested transaction acceptable to a submitting market party of the plurality of market parties; calculating at least one resultant limitation by applying a combination rule to a set of associated limitations of the plurality of transaction profiles, wherein the set of associated limitations is associated with a transaction attribute, the at least one resultant limitation at least partially defining a suggested resulting transaction; and forming any number of resultant transaction profiles, wherein each resultant transaction profiles comprises any number of the at least one resultant limitations and wherein each of the resultant transaction profiles represents at least one suggested resulting transaction.

2. A method in accordance with claim 1 , wherein the combination rule comprises: logically intersecting sets of transactions defined by the set of the associated limitations to form the resultant limitation.

3. A method in accordance with claim 1 , wherein each of the plurality of transaction profiles at least partially defines a set of commercial transactions acceptable to a submitting market party of the plurality of market parties.

4. A method in accordance with claim 1 , wherein a first transaction profile of the plurality of transaction profiles at least partially defines a different set of transaction attributes than a second transaction profile of the plurality of transaction profiles.

5. A method in accordance with claim 1 , wherein the resultant transaction profile represents a plurality of suggested resultant transactions.

6. A method in accordance with claim 1 , wherein the any number of limitations to a suggested transaction includes any number of multiple value limitations to an attribute of the suggested transaction, wherein each of the multiple value limitations represents more than one value of the attribute acceptable to a submitting party.

7. A method in accordance with claim 6, wherein the multiple value limitation is a range limitation representing a plurality of values between a minimum value and a maximum value.

8. A method in accordance with claim 6, wherein the multiple value limitation is a wild-card limitation representing an infinite number of values.

9. A method in accordance with claim 6, wherein the multiple value limitation is a partial wild-card representing an infinite number of values other than at least one omitted value.

10. A method in accordance with claim 9, wherein the multiple value limitation defines an infinite number of values greater than a minimum value.

11. A method in accordance with claim 9, wherein the multiple value limitation defines an infinite number of values less than a maximum value.

12. A method in accordance with claim 9, wherein the multiple value limitations defines a set of strings matching a regular expression.

13. A method in accordance with claim 6, wherein the calculating comprises calculating a plurality of resulting limitations by applying an associated combination rule to each set of associated limitations of a plurality of sets of limitations, wherein each set is associated with a corresponding transaction attribute.

14. A method in accordance with claim 1 , wherein the any number of limitations to a suggested transaction includes any number of market party limitations, each market party limitation associated with a market party characteristic.

15. A method in accordance with claim 14, wherein the any number of limitations to a suggested transaction includes any number of product limitations, each product limitation associated with a product characteristic.

16. A method in accordance with claim 14, wherein the any number of limitations to a suggested transaction includes any number of commercial limitations, each commercial limitation associated with a commercial term.

17. A method in accordance with claim 14 wherein the any number of limitations to a suggested transaction comprises: any number of market party limitations, each market party limitation associated with a market party characteristic; any number of product limitations, each product limitation associated with a product characteristic; and any number of commercial limitations, each commercial limitation associated with a commercial term, wherein the calculating at least one resultant limitation comprises: applying the combination rule to a set of associated market party limitations of the plurality of transaction profiles, a set of associated product limitations, and a set of associated commercial limitations to form a resultant market party limitation, a resultant product limitation and a resultant commercial limitation.

18. A method in accordance with claim 14, wherein the market party characteristic is a market party identifier.

19. A method in accordance with claim 18, wherein the market party identifier identifies a submitting market party submitting the transaction profile including the market party identifier.

20. A method in accordance with claim 19, wherein the transaction attribute is a name of the submitting market party.

21. A method in accordance with claim 18, wherein the market party identifier identifies a market party other than a submitting market party submitting the transaction profile including the market party identifier.

22. A method in accordance with claim 14, wherein the market party characteristic is credit rating.

23. A method in accordance with claim 14, wherein the market party characteristic is geographical location.

24. A method in accordance with claim 14, wherein the any number of market party limitations comprises any number of multiple value limitations representing at least two market parties acceptable to the submitting market party.

25. A method in accordance with claim 24, wherein the multiple value limitation is wild-card limitation representing an infinite number of acceptable market parties to the submitting market party.

26. A method in accordance with claim 24, wherein the multiple value limitation is partial wild-card limitation representing an infinite number of acceptable market parties to the submitting market party except for at least one omitted market party.

27. A method in accordance with claim 1 , wherein the receiving comprises: receiving a plurality of transaction profiles from market parties of at least three market party classes, each transaction profile comprising any number of limitations to a suggested transaction acceptable to a corresponding submitting market party of one of the at least three market party classes, wherein each resulting transaction profile of the plurality of resulting transaction profiles involves the market parties from the at least three market party classes.

28. A method in accordance with claim 1 , wherein forming further comprises: forming a resulting transaction profile representing a plurality of resulting potential transactions.

29. A method in accordance with claim 28, wherein the prioritizing produces an optimum resulting transaction, the method further comprising displaying the optimum resulting transaction to a market party submitting one of the transaction profiles of the group.

30. A method in accordance with claim 28, wherein the prioritizing produces a list of resulting potential transactions, the method further comprising displaying the list to a market party submitting one of the transaction profiles.

31. A method in accordance with claim 28, further comprising: prioritizing the plurality of resulting potential transactions based on an optimization function.

32. A method in accordance with claim 31 , wherein the optimization function is defined by a provider to a market exchange.

33. A method in accordance with claim 31 , wherein the optimization function is defined by a market party.

34. A method in accordance with claim 28, wherein the any number of transaction profiles comprises a plurality of resulting transaction profiles, each of the plurality of resulting transaction profiles defining at least one resulting potential transaction to create a plurality of resulting potential transactions, the method further comprising: prioritizing the plurality of resulting potential transactions to produce a transaction prioritization.

35. A method in accordance with claim 34, further comprising: prioritizing the plurality of transaction profiles based on the transaction prioritization.

36. A method in accordance with claim 28, wherein the any number of resulting transaction profile comprises a plurality of resulting transaction profiles, the method further comprising: prioritizing the plurality of resulting transaction profiles based on an optimization function.

37. A method in accordance with claim 36, wherein the optimization function is defined by a provider of a market exchange.

38. A method in accordance with claim 36, wherein the optimization function is defined by a market party.

39. A method in accordance with claim 36, wherein the prioritizing produces a prioritization list of resulting transaction profiles, the method further comprising: displaying the prioritization list to the submitting party.

40. A method in accordance with claim 36, wherein the prioritizing produces an optimum resulting transaction, the method further comprising: displaying the optimum resulting transaction to the submitting party.

41. A method in accordance with claim 36, further comprising: receiving an optimization function from a submitting market party, the optimization function indicating a procedure for prioritizing the plurality of resulting transaction profiles.

42. A method in accordance with claim 1 , wherein at least one transaction profile of the plurality of transaction profiles indicates a different market party commitment level than another transaction profile of the group.

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

44. A method in accordance with claim 43, wherein the transaction profile type comprises a secret search request requesting a search for other transaction profiles meeting the limitation of the transaction profile, the transaction profile type indicating the submitting party is submitting the secret search request and does not intend to be legally bound by any transaction and does not intend to provide information related to the secret search provided to any other market party.

45. A method in accordance with claim 43, wherein the transaction profile type comprises posting requesting a search for other transaction profiles meeting the limitation of the transaction profile, the transaction profile type indicating: the submitting party is submitting a posting and is not providing an offer that can be accepted by any other party; and the submitting party is expressing an interest in transactions defined by the transaction profile.

46. A method in accordance with claim 45, further comprising displaying the transaction profile submitted by the submitting party to at least one other market party.

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

48. A method in accordance with claim 47, wherein each of the plurality of transaction profiles represents a plurality of transactions acceptable to a submitting market party, the transaction profile type indicating a market party commitment of the submitting market party to be legally bound to any one transaction represented by- the transaction profile submitted by the submitting party.

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

50. A method in accordance with claim 1 , wherein each of the plurality of transaction profiles is a wild-card data record structured in accordance with a data language, the wild-card data record comprising: at least one wild-card data element representing a plurality of data elements, the wild-card data record configured to form a data record conforming to a schema when the at least one wild-card data element is replaced with any one of the plurality of data elements.

51. A method in accordance with claim 50, wherein the at least one wildcard data element comprises a plurality of wild-card data elements, each of the plurality of wild-card data elements representing a corresponding plurality of data elements and wherein the wild-card data record is configured to form the data record conforming to the schema when each of the plurality of wild-card data elements is replaced by any of the corresponding plurality of data elements.

52. A method in accordance with claim 50, wherein the wild-card data record is used to represent the set of data records which may be obtained from any combination of replacing the at least one wild-card data record with one of the data elements represented by the at least one wild-card data record.

53. A method in accordance with claim 50, wherein the data language allows a tree structure, the at least one wild-card data element representing the set of all sub-trees allowed by the data language.

54. A method in accordance with claim 50, wherein the data language allows a tree structure, the at least one wild-card data element replacing an entire sub-tree specified in the schema and representing some subset of the sub-trees allowed by the schema.

55. A method in accordance with claim 50, wherein the at least one wild-card data element represents a range of numbers.

56. A method in accordance with claim 50, wherein the at least one wild-card data element represents a range of dates.

57. A method in accordance with claim 50, wherein the at least one wild-card data element represents a set of strings.

58. A method in accordance with claim 53, wherein the wild-card data element is the root of the wild-card data record and the wild-card data record represents all data records allowed by the data language.

59. A method in accordance with claim 50, wherein the data language is Extensible Markup Language (XML).

60. A method in accordance with claim 50, wherein the schema is in accordance with a Data Type Document (DTD) formalism.

61. A method in accordance with claim 50, wherein the schema is in accordance with a XML Schema formalism.

62. A method in accordance with claim 50, wherein the at least one wild-card element is an XML element.

63. A method in accordance with claim 62, wherein the at least one wild-card element belongs to an XML namespace associated with a set of all possible wildcard elements

64. A method in accordance with claim 52, wherein the wild-card data record is configured to return a resultant wild-card record when an intersection function is applied to the wild-card record and a second wild-card record, the third wild-card data record representing a resultant set of data records equal to a set-theoretic intersection of the set of data record and a second set of data records represented by the second wild-card data record.

65. A method in accordance with claim 64, wherein: the wild-card data record represents a set of all commercial transactions meeting constraints of a potential market party to a commercial transaction; the second wild-card data record represents a set of all commercial transactions meeting constraints of a second potential market party to a commercial transaction; and the third wild-card data record represents the set of all commercial transactions meeting the constraints associated with the commercial transactions of the first and the second potential market parties.

66. A transaction server comprising: network interface configured to receive 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 any number of limitations to a suggested transaction acceptable to a submitting market party of the plurality of market parties; a transaction controller configured to calculate at least one resultant limitation by applying a combination rule to a set of associated limitations of the plurality of transaction profiles, wherein the set of associated limitafions is associated with a transaction attribute, the at least one resultant limitation at least partially defining a suggested resulting transaction; and the transaction controller further configured to form any number of resultant transaction profiles, wherein each resultant transaction profiles comprises any number of the at least one resultant limitations and wherein each of the resultant transaction profiles represents at least one suggested resulting transaction.

67. A transaction server in accordance with claim 66, wherein the combination rule comprises: logically intersecting the associated limitations of a set of associated limitations to form the resultant limitation.

68. A transaction server in accordance with claim 66, wherein each of the plurality of transaction profiles at least partially defines a set of commercial transactions acceptable to a submitting market party of the plurality of market parties.