WO2002010882A2

WO2002010882A2 - Apparatus, system and method for providing a transaction management markup language

Info

Publication number: WO2002010882A2
Application number: PCT/US2001/023873
Authority: WO
Inventors: Zvi M. Schrieber; Amit Gal
Original assignee: Vert Tech Llc
Priority date: 2000-07-31
Filing date: 2001-07-31
Publication date: 2002-02-07
Also published as: WO2002010882A3; AU2001284678A1

Abstract

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

Description

APPARATUS, SYSTEM AND METHOD FOR PROVIDING A TRANSACTION MANAGEMENT MARKUP LANGUAGE

RELATED PATENT APPLICATIONS

This 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 thrqugh a communication network.

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

Conventional electronic transaction techniques, however, are limited in several ways. In general,_, most conventional systems are based on hard-coded mechanisms of matching and negotiation.

For example, many conventional systems, particularly those that are auction based, perform one-to-many matching and not many-to-many matching. These conventional systems, therefore, allow a seller to pick between many buyers based on price but do not allow for the buyer to select between many sellers.

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

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

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

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

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

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

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

SUMMARY OF THE INVENTION

In an exemplary embodiment of the invention, a wild-card data record conforming to a data language includes at least one wild card data element that can represent more than one data element. The wild card element may represent several discrete values, a range, or any other infinite of finite arrangement or set of values or strings. Although the wild card is a single data record, it represents more than one document conforming to a schema or DTD of the data language. If any of values or strings represented by the wild card data element is replaced with one of the data elements it represents, the resulting data record conforms to the DTD or schema. Accordingly, a wild-card data record may represent any number of data records conforming to the schema, although the wild card data record may or may not conform to the schema of the data language.

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

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

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram of a transaction management system in accordance with an exemplary embodiment of the invention.

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

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

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

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

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

FIG. 10 is a flow chart of a method of managing transactions in accordance with the exemplary embodiment of the invention. FIG. 11 is an illustration of a example of the use of indexing in accordance with the exemplary embodiment of the invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS As described above, conventional electronic market techniques are severely limited by rigid and restrictive rules for representing a transaction request including the need to specify definitive values for all parameters of the transaction. Further, conventional 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. Further, conventional systems have hard coded logic for market mechanisms making it difficult to add new mechanisms and preventing a single buy offer, for example, from competing against multiple types of sell offers.

The present invention overcomes these limitations and others by providing an efficient and flexible apparatus, system and method for managing electronic markets and transactions. FIG. 1 is block diagram of a transaction management system 100 in accordance with an exemplary embodiment of the invention. In the exemplary embodiment, market parties 102, which may be individuals or electronic trading systems, submit transaction profiles through local processors 104 (user terminals) connected to a communication network 106. A transaction server 112 identifies related transaction profiles, provides information to appropriate market parties 102, commits market parties 102 to transactions and provides other services based on the content of the transaction profiles received.

As described below in further detail, a wild card data record (wild-card document) is created using a transaction profile template and information submitted by a market party. The wild card data record conforms to the XML Schema in the exemplary embodiment and is forwarded to a transaction controller 108. The wild card data record includes a wild card data element representing more than one data element (a range or set of transaction limitations). In the exemplary embodiment, each of the wild card data records is a transaction profile having at least one wild card element corresponding to two or more values or strings associated with a limitation to a proposed transaction. The transaction controller 108 applies set-theory techniques to identify wild card data records having overlapping limitations. Each of the wild card data records represents one or more data records conforming to the XML schema or DTD of the particular data language associated with the industry of the market parties. Accordingly, each of the potential transactions represented by the data records resulting from replacing the wildcard element with each of the data record elements it represents is considered when identifying matching transaction. The transaction profiles include limitations to a suggested transaction acceptable to the market party 102 submitting the transaction profile. Since the limitations may allow for more than one value or transaction term, the transaction profile may describe more than one suggested transaction acceptable to the market party 102. The limitations may be values, character strings, or other symbols that limit or define transaction attributes such as transaction terms, market party names, locations, times, dates, product specifications, model numbers, catalog numbers, sizes, quantities or any other information that may be used to describe a transaction.

After receiving the transaction profiles, the transaction controller 108 identifies at least two transaction profiles that have limitations meeting the other identified transaction profiles. A limitation of a transaction profile meets another limitation of another transaction profile if the limitations of each transaction profile are not inconsistent with the other. Therefore, in context of a value limitation, one limitation meets another limitation if the two limitations are the same or if at least one value defined by one of the limitations is included in the description of the other and no specified values are inconsistent with the other transaction profile description. Several groups of transaction profiles may be identified where each group includes at least two transaction profiles having overlapping transaction limitations. A single system can accept transaction profiles from a variety of industries and relating to a variety of subject matter and can identify the appropriate transaction profiles that match within a group. As discussed below in further detail, the transaction controller 108 accepts and processes transactions profiles having a wide variety of formats. The transaction profiles may describe search requests, expressions of interest to participate in a suggested transaction or group of transactions (soft match), or may be firm offers to enter into a transaction if the limitations are met.

In the exemplary embodiment, the communication network 106 is a packet switched network, such at the Internet, that supports Transmission Control Protocol/Internet Protocol (TCP/IP), Hypertext Transmission Protocol (HTTP), and Hypertext Markup Language (HTML). Although the transaction management system 100 utilizes the Internet and associated technologies, those skilled in the art will recognize the other types of communication techniques that may be used to facilitate the transaction management based on the teachings discussed below. For example, the communication network 106 may be an Ethernet network. Further, the communication network 106 may be any network or combination of networks suitable for performing the functions described herein. Examples of other suitable data formats include Extensible Markup Language (XML), Standard Generalized Markup Language (SGML), serialized Java objects, and custom vector formats. The communication network 106 may include 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 form the browser to the Web server (HTTP POSTs) and can be analogized to a Java applet running on Web browser. As discussed above, the box representing the network interface 110 is illustrated using dotted lines to indicate that the network interface 110 may be implemented as part of a transaction server 112 or as a separate apparatus. The functions of the network interface 110 may be implemented using other interface techniques such as those, for example, utilizing a Common Gateway Interface (CGI), Microsoft Active Server Pages and Java Server Pages for browser based trading and direct TCP/IP communications or methods such as Java RMI and CORBA for system-to-system trading. The database 114 maintains a persistent copy of all the transaction profiles submitted by the market parties 102 and of a corresponding storage structure. Any one of several types of object or relational databases may be used in the exemplary embodiment. Examples of suitable databases include object databases provided by Versant and relational databases provided by Microsoft and Oracle. Other types of database and storage techniques may be used to maintain the appropriate information and to provide access to the information by the transaction controller 108 including a naming or directory service. Access to an object database may be through the Object Database Management Group (ODMG) Application Program Interface or vendor specific interfaces and access to relational databases may be through JDBC, ODBC and other commercial and proprietary drivers. Multiple computers and storage mechanisms can be used to maintain the database 14 allowing the information to be distributed across several machines. Redundant synchronized copies of the database may be maintained to provide reliability. The local processors 104 facilitate communication between the market parties 102 and the transaction controller 108 through the network interface 110 and the communication network 106. The local processors 104 may be any type of processor, microprocessor, computer, personal computer (PC), laptop computer, personal digital assistant (PDA) or processor arrangement or processor combination capable of performing the functions described below. In the exemplary embodiment, the local processor 104 is a PC running a Windows 2000® based operating system. The local processor 104 includes, or may be connected to, a communication interface such as a modem for communicating through the communication network 106. Those skilled in the art will recognize the various transmission media and techniques for 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 1034 and the communication system. In the exemplary embodiment, Web browser software running on the local processor 104 facilitates a graphic user interface (GUI) which allows the market party 102 to obtain information from, and submit information to, the communication network 106. Examples of suitable Web browser software include Netscape Navigator and Microsoft Explorer.

The local processor 104 includes at least one type of output device such as video monitor or display capable of presenting visual information of the GUI and may contain other output devices such as an audio speaker or printer. At least one input device allows the market party 102 to communicate information to the transaction controller 108. In the exemplary embodiment, the market party 102 enters information through a keyboard and computer mouse into a transaction profile form presented as a Web page, including an html <form> element, by the Web browser. Any suitable technique for entering information, however, may be used. Examples of other input techniques include using touch screens and entering information through a microphone and speech-to-text software as well as automated trading by a computer program. Alternatively, if the market party has automated procurement or sales such as ERP software the communication with 102 may be software based (e.g. using data formats such as XML and technology such as RPC or messaging) and not involve a display.

In the exemplary embodiment, a transaction profile template in an XML format is accessible by the network interface 110 and the transaction controller 108. The network interface 110 transmits a Web page associated with a template to the local processor 104 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 a 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 party 102 submitting the earlier transaction profile may no longer have access to a Web browser at the time the match is identified.

Each of the market parties 102 obtains a transaction profile form from the transaction controller 108 through the communication network 106. In the exemplary embodiment, the market party 102 submits a request for a transaction profile form by designating the appropriate Universal Resource Locator (URL) using the Web browser running on the local processor 104. Each type of transaction profile form is uniquely associated with an URL and the market party 102 may obtain the desired transaction profile form by identifying the appropriate URL. A message formatted in accordance with TCP/IP is transmitted to the network interface 110.

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

Therefore, a plurality of transaction profiles are received from a plurality of market parties 102 at a transaction controller 108 through a communication network 106. The transaction controller 108 identifies at least two transaction profiles that meet each other's limitations. The matched transaction profiles may indicate different levels of market party 102 commitment. Transaction information describing the identified transaction profiles is transmitted to the market parties 102 corresponding to the identified transaction profiles. Depending on the types of transaction profiles, the market parties 102 may receive information such as the identity of the other market parties 102 having overlapping interests, statistical information, information regarding the other transaction profile limitations. If the identified transaction profiles are firm offers, the parties are committed to a transaction. Otherwise, the market parties 102 may use the transaction information to continue pursuing an agreement with the parties to enter into a transaction. Combinations and adaptations of the above methods provide a sophisticated transaction management system 100 allowing a wide variety of transactions, reports and analysis. FIG. 2a 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 alterations, modifications and permutations that can be applied to the language discussed herein.

FIG. 2b is block diagram of an exemplary wild-card data record (wild card data document) 222. The XPL document created from the HTML information and the transaction profile template is an example of a wild-card data record 222 if the document includes XPL tags 224 identifying ranges, sets or other arrangement of values or strings 226. Each XPL tag 224 in addition to the corresponding set, range or arrangement 226 is an example of a wild-card element 228. As will be apparent to those skilled in the art, the wild card element 228 may be formed using other techniques. For example, the wild card element 228 may be formed with other identification mechanisms alternatively to tags (224). Further wild-card data records 222 may be electronic documents, stored data records or transmitted messages and the wild-card elements 228 may be any type of entry or element that represents multiple data elements or entries in accordance with the techniques discussed herein. Accordingly, the various fields, information and tags discussed below may be associated with wild card elements. Another exemplary wild-card element is shown below in Table 1. In addition to the wild card elements 228, the wild-card data record may include other elements 234 that include tags 230 and information (transaction limitations) 232.

Those skilled in the art will recognize that the techniques described above can be used to modify any existing data record that conforms to a machine readable format into a data record that represents more than one data record where each of the data records it represents conforms to the machine readable format. A schema may include a set of acceptable language elements and a machine readable format. In the context of markup languages, a markup language schema or DTD typically has a format requirement as well as a acceptable set of language element designators (original tags) 230. The language element designators (original tags) 230 identify information within an element 234. In an XML document, the XML tag and associated information form an XML element that is formatted in accordance with the format required for the particular XML schema. Using a particular schema, a wild card tag (wild card element designator) 224 can be embedded with a document 222 allowing the document 222 to conform to the format of the schema. The wild card element designator 224, however, may or may not be an acceptable element designator (230) for the particular schema. The wild card element designator (wild card tag) 224 can be nested within an acceptable pair of element designators 230 forming a wild card element 228 within the document 222. The wild card document 222 formed with the wild card element 228 represents multiple documents where each of the documents conforms to the format as well as the other schema requirements. Since the wild card element 228 can be replaced with information corresponding to a single value or string having the acceptable language element designators of the schema, the wild card document 222 can be interpreted as several documents each conforming to ail the requirements of the schema.

Applying the above explanation to an example, if a schema for the resistor industry provides a format and an acceptable set of language designators (original tags) that includes a quantity designator allowing for a single resistor value, a document can be formed that conforms to the format of the schema but includes nested wild card language element designators (wild card tags) that allow the document to represent several proposed transactions, where each proposed transaction proposes a different resistor value. The tag, <ohms> is an acceptable designator as allowed by the resistor industry schema. The wild card element, <xpl:range min= "100" max="10000"> can be nested within the acceptable tag pair. The wild card document that is formed represents all transactions expressing a resistor value of 100 ohms to 10000 ohms. The wild card document can represent a finite number of transactions if the resistor values are determined to be discrete for an industry. Otherwise, the wild card document represents infinite number of transactions. If the wild card element is replaced with any of one of the values it represents, the wild card document conforms to all the requirements of the schema. Referring again to Fig 2a, the transaction profile template 200 includes a transaction profile classification 202 and a transaction profile description 204 in the exemplary embodiment. The transaction profile classification 202 provides technical aspects of the transaction profile and includes a profile type indicator 206, an expiration date 208, and a market party designator 210.

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

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

The market party designator 210 provides a classification of the market party 102 submitting the transaction request. Examples of market party designators 210 include designators indicating that the market party 102 submitting the transaction profile is a buyer, seller, carrier, financier, or insurer. Depending on the particular market, the market party designator 210 may have additional or fewer potential designations to those mentioned.

As described below, the transaction profile classification 202 may include other fields for describing the type of transaction profile, or other parameters related to the transaction profile other than a transaction term. Those skilled in the art will recognize that categorization of transaction profile classification 202 indicators and transaction terms may be achieved in other ways. For example, the expiration date 208 may be considered to be a transaction term (in that it describes the ranges of allowed values for the time of the transaction) rather than a transaction profile classification 202. The transaction profile description 204 includes at least one field (212-220) for a transaction term. In the exemplary transaction profile template 200, the transaction profile description 204 includes fields for transaction terms corresponding to price 212, quantity 214, a quality grade minimum 216, a quality grade maximum 218 and a catalog number 220. Other transaction terms that may be included in a transaction profile template 200 include parameters that relate to a product or service. For example, fields may be provided for a size, style and color. The number and types of fields of a particular profile template 200 will depend on the types of goods or services, traditions in the market, and other factors that will readily occur to those skilled in the art. Each transaction term may be represented by a single value, a wild card, or a range of values. The quality grade minimum 216 and quality grade maximum 218 provide an example of a transaction term having a range of values corresponding to a specification transaction term. For this exemplary transaction term, the value contained in quality grade minimum 216 field and the value in the quality grade maximum 218 field define a range of values corresponding to the quality grade. Since quality grades are typically represented by a discrete value, the 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.

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 ail 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 and specifies the seller as a wild card indicating that the buyer will work with any seller. Appendix IV provides an exemplary transaction profile submitted by a seller wishing to sell lots of 1000 and 10,000 and that is only willing to enter into a transaction with a buyer in California. By including details of buyer 402 and seller 404 as parameters of the transaction, the same wild cards which are used to match product parameters may be used by buyers and sellers to select the specific partners they will work with by name, or the type of trading partner they will accept based on, for example, geography or credit rating. Appendix V illustrates an exemplary resulting transaction profile of a match between the buyer and seller transaction profiles. The intersection specifies a specific value for quantity, buyer and seller and can be used as record of a resulting contract between the two market parties 102. Another example includes further parameters describing the product and transaction terms.

FIG. 3 is a block diagram of the transaction server 112 interfacing to a graphic user- interface (GUI) 302 at the local processor 104 in accordance with the exemplary embodiment. In response to a request for a transaction profile form, the web server within the network interface 110 retrieves a transaction profile form 306 stored in HTML format either on the network interface 110 or in storage accessible to the network interface 110. The Web server transmits the transaction profile form to the local processor 104 where it is displayed to the market party 102 through a GUI 302. The transaction profile form 306 includes fields that correspond to the associated transaction profile template 200. Accordingly, the transaction profile form 306 solicits information corresponding to the fields within the transaction profile template and provides the market party 102 with a vehicle for providing the transaction profile since the completed 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 arrangement 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 a 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 had flexibility in some parameter, the intersection may still be flexible. For example, if the seller offered delivery dates between 12^th and 15^th and the buyer specified a delivery date between 10^th and 14^th then any date between 12^th and 14^th would be acceptable to both market parties 102 and this range will be specified in the resultant transaction profile. The clearing engine 318 will replace any such range with a specific value. Typically, the market provider will specify (e.g. using an attribute in the XML template) whether flexibility in a given parameter should be rounded up or down.

Matching is prompted by a newly submitted transaction profile and the new 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 based on all transaction profiles of group identified as having overlapping limitations. In the exemplary embodiment, the resulting transaction profile is formatted in accordance with XML and contains information including the identity of the market parties 102 that have submitted matching transaction profiles and the transaction attributes from the transaction profiles including transaction terms such as price, quantity, catalog numbers, location^'s, 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 110 notifies the market parties 102 in a way appropriate to the choices of the market provider and of the specific market party 102 to be notified. In the. exemplary embodiment, the market party 102 that submitted the last transaction profile that resulted in a 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 system 100. Examples of suitable ERP systems include systems available from SAP, Peoplesoft, Oracle, Baan and J.D. Edwards.

FIG. 4 is a block diagram illustrating a transaction scenario in accordance with the exemplary embodiment of the invention where the market parties 102 include buyers 402, sellers 404, and transaction enablers 406. As discussed above, the market parties 102 may be any type of potential participants in a transaction. Although for illustrative purposes, FIG. 4 relates to an example of a commercial transaction that includes at least one buyer 402 and one seller 404, other types of transactions and trading scenarios can be managed by the transaction management system 100. For example, a reinsurance transaction may include market parties 102 categorized as assume and cede and an interest rate swaps transaction may involve parties which pay-fixed and receive-fixed. In the exemplary embodiment, the transaction 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, quantity and quality which vary from profile to profile. The market party 102 submitting the transaction profile provides information to complete the form to create the transaction profile. Preferably, the transaction profile template 200 follows any formal XML Data Type Document (DTD) or Schema accepted by the particular market.

A buyer 402 accesses the transaction management system 100, by requesting a buyer transaction profile form through the local processor 104 and the communication network 106. In the exemplary embodiment, the buyer 402 requests the appropriate transaction form by accessing the URL of the form through the home .Web page of the transaction management service provider. The network interface 10 provides a transaction profile form 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 includes instruction text 502 including information potentially helpful to the buyer 402 when completing the buyer form 500. A profile type field 504 includes a space for entering the type of transaction that the buyer 402 intends to submit. In the exemplary embodiment, the buyer 402 may chose between two status options that are accessible through a pull-down menu including a search (browse) or soft match (expression of interest). A maximum price field 506 allows the buyer 402 to enter a maximum price the buyer 402 is willing to pay per barrel of gasoline. In the present example, the buyer transaction profile form 500 is hard valued to zero as the minimum price. The buyer 402 enters the appropriate minimum and maximum values for a quantity range 508. A minimum quantity field 510 allows the buyer 402 to enter any integer denoting the minimum number of barrels the buyer 402 is willing to buy. The maximum quantity field 512 provides an entry location for the maximum number of barrels the buyer 402 wishes to obtain. The delivery date field 514 includes two fields for defining a range of dates that the buyer 402 would consider for delivery of the gasoline. A grade field 516 allows the buyer 402 to enter the preferred grade of oil to be purchased. In the exemplary embodiment, the buyer 402 may choose the grades by choosing the appropriate option in a pull-down menu. The pull-down menu provides a wild card option by allowing the buyer 402 to choose all grades of oil. In the exemplary scenario, the buyer 402 may enter tolerance values for defining the gasoline. For example, an RVP field 518 allows the buyer 402 to specify a range for the Residual Vapor Pressure (RVP) of the gasoline. An oxygenates section 520 allows the buyer 402 to enter the desired tolerance values for MTBE and ethanol as a percentage of volume of the gasoline. A shipment location field 522 allows a buyer 402 to enter the location to which the oil should be delivered. In the exemplary embodiment, a state may be designated using a 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 112. 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 transaction profile form to the network interface 110 when the transaction profile form has been completed. The submit button 528 is implemented in accordance with known internet techniques.

FIG. 6 is a pictorial representation of a seller transaction profile form (seller form) 600 implemented as a Web page. The seller form 600 includes instruction text 602 including information potentially helpful to the seller 404 when completing the seller form 600. A profile type field 604 includes a space for entering the type of transaction that the seller 404 intends to submit. In the exemplary embodiment, the seller 404 may chose between two status options that are accessible through a pulldown 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 transaction profile form to the network interface 110 when the transaction profile form has been completed. The submit button 628 is implemented in accordance with known internet techniques.

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

The following element is the root element for the XML document to be instantiated by the template. It includes a definition of the xpl and tpt namespaces as required by the XML Namespace standard.

<gaz-salθ x lns :xpl="http : // . tradeum . com" xmlr-s : tp t = " ht t : / /www . tr adeum . co " >

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

<tpt : validtill/> The following XML element groups the details of the parties including the buyer 402_and seller 404 of the transaction.

<buyer>

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

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 party in the form in this case in field 604 which is assumed to have been given html field name "status".

<statusxtp : inserttβxt

</buyer>

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

<xpl : any_element/> </partiβs> 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>

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

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

</source> <destination> <state>

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

<tpt terror 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 transaction profile form to the network interface 110 when the transaction profile form 200 has been completed.

The network interface 110 extracts the appropriate information form each field in each 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. Information contained within the HTML seller form 600 is placed within an XML template to create an XML seller transaction profile. A carrier XML transaction profile is formed using the HTML carrier form 700. The XML transaction forms are received at the 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 112 receives a request for a transaction profile form. The network interface 110 receives a request for a transaction profile form. As described above, the market party 102 submits a request for the transaction profile form by indicating the appropriate URL through a Web browser. The URL uniquely indicates to the network interface 1^" 0 the type of transaction profile the market party 102 requires. At step 1004, the network interface 110 transmits a Web page to the local processor 104. The Web page is a transaction profile form having at least one 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 300 from the market party 102 through the communication network 106 in an HTML format.

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

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

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

At step 1014, the received transaction profile is stored within the database 114. In the exemplary embodiment, the transaction profiles are stored in a hierarchical data structure in order to facilitate the matching process by rapidly eliminating broad classes of non-matching profiles from the matching.

At step 1016, the transaction controller 108 creates a 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 parties are included within the ^' transaction profile (e.g. buyer 402 specified himself as buyer 402 and wild cards seller and seller 404 specified himself as seller and wildcards buyer) after intersection details of both parties appear in the intersection result.

At step 1018, the 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 bur rather may wish to describe the transactions that interest them. These desired transactions may include some flexibility of the transaction terms such as delivery dates, the identity of the counter part, quantities and other terms which will occur readily to those skilled in the art. The use of XPL documents allows this flexibility to be captured in a natural way which respects the structure of the XML document. Each XPL element represents a set of XML elements and the XPL element may be inserted in a given place in the document to describe which XML elements would be acceptable at that place in the document. Although the XPL can have a variety of semantics, a convenient example allows each XPL element to represent a set of XML elements which it matches. Each XPL document (i.e. XML document containing XPL elements) can be given a semantics by stating that each XPL document matches a given XML document if their root elements match.

Table 1 XPL element Simple XML elements which match

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

Ordinary XML text Matches identical text only.

<xpl:none/> None

<xpl:any_element/> Any single XML element

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

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

Table 2 below provides an exemplary algorithm utilized by the method of identifying transaction profiles having overlapping limitations in accordance with the exemplary embodiment of the invention. For illustrative purposes, the method discussed in reference to Table 2 provides an exemplary matching technique for identifying two transaction profile expressed in XPL that have overlapping limitations (intersect). The result of the match is a new resulting 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, network interface and server functions. Those skilled in the art will readily apply the teachings and techniques discussed in Table 2 to create computer code in any appropriate computer language for implementing the functionality of the matching process utilized by the transaction system 100.

Table 2

The matching procedure, therefore, determines whether a newly submitted 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 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 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 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 whic 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 104. 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 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 110, 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. The results of the matches are conveyed to the market parties 102 through a Web browser or email. Transaction profiles describing different levels of commitment may be matched allowing a variety of transactions to be performed.

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

APPENDIX I

<car>

<make> BMW

</make> <color>

Black </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

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

1.10 </price>

<transaction-parties> <buyer>

<name>

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

<xpl:any-element-list/> </seller> </transaction-parties> </resistor-sale>

Appendix IV

<resistor-sale> <ohιcιs> <xpl: range min="100"

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

1.10 </price> <transaction-parties>

<buyer>

<name>

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

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

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

Appendix V <resis or-sale> <ohms>

10000 </ohms>

1.10 </price>

<transaction-parties> <buyer>

<name>

Electronics Procurement Inc </name> <state> CA

</state> </buyer> <seller>

<name> Resistors Inc.

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

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

Appendix VI

<gaz-sale xmlns :xpl="http: //www. tradeum.com" xmlns : pt= "http : //www. tradeum. com" >

<buyer>

<tpt:originator>

</tpt : originator>

<xpl: range min="tpt:minquantity" max--"tpt:maxquantity" prefers "up" /> </quantity>

<price>

<xpl: range mins'O" max=" tpt: price" prefers"down" />

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

</source> <destination> <state> <tpt:inserttext field="state">

<tρt: error text="<h2>Please specify our 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>

<year>

</year> <month>

<day>

</day> </date>

<date>

</year> <month>

</month> <day>

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

<tpt: inserttext fields "grade" /> </grade> <RVP>

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

</RVP> <MTBE>

<xpl: range mins"tpt:minmtbe" maχs"tpt:maxmtbe" prefers "up"/> </M BE>

<xpl: range ins"tpt: inethynol" maχs"tpt :maxethynol" prefβr="up"/> </Ethanol> </gaz-sale>

Claims

1. A wild-card data record conforming to 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.

2. A wild-card data record in accordance with claim 1 , wherein the at least one wild card 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.

3. A wild-card data record in accordance with claim 1 , whereby 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.

4. A wild-card data record in accordance with claim 1 , 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.

5. A wild-card data record in accordance with claim 1 , wherein the at least one wild-card data element represents a range of integers.

6. A wild-card data record in accordance with claim 1 , wherein the at least one wild-card data element represents a range of dates.

7. A wild-card data record in accordance with claim 1 , wherein the at least one wild-card data element represents a set of strings.

8. A-wild-card data record in accordance with claim 4 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.

9. A wild-card data record in accordance with claim 1 , wherein the data language is Extensible Markup Language (XML).

10. A wild-card data record in accordance with claim 9, wherein the schema is in accordance with a Data Type Document (DTD) formalism.

11. A wild-card data record in accordance with claim 9, wherein the schema is in accordance with a XML Schema formalism.

12. A wild-card data record in accordance with claim 9, wherein the at least one wild-card element is an XML element.

13. A wild-card data record in accordance with claim 12, wherein the at least one wild-card element belongs to an XML namespace.

14. A wild-card data record in accordance with claim 3, wherein the wild card data record represents a set of all commercial transactions meeting constraints of a potential market party to a commercial transaction.

15. A wild-card data record in accordance with claim 3, wherein the wild card data record represents a set of all resources to which a principal has been granted privileges.

16. A wild-card data record in accordance with claim 3, 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.

17. A wild-card data record in accordance with claim 16, 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.

18. A wild-card data record in accordance with claim 16, wherein: the wild-card data record represents a set of all resource accesses to which a principal has been granted privileges by a first administrator; the second wild card data record represents a set of all resource accesses to which the principal has been granted privileges by a second administrator; and the third wild card data record represents a set of all resource accesses to which the principal has been granted privileges by both the first and second administrators.

19. A wild-card data record in accordance with claim 3, the wild-card data record configured to return a resultant wild-card data record when a union function is applied to the wild-card data record and a second wild-card data record, wherein a set of data records represented by the resultant wild-card data record is equal to a set-theoretic union of the set of data records and a second set of data records represented the second wild-card data record.

20. A wild-card data record in accordance with claim 16, wherein: the wild card data record represents a first set of all resource accesses to which a principal has been granted privileges by a first administrator; the second wild card data record represents a second set of all resource accesses to which the principal has been granted privileges by a second administrator; and the resultant wild-card data record represents a resultant set of resource accesses, wherein the resultant set of resources includes the first set of resource accesses in addition to the second set of resource accesses.

21. A wild-card data record in accordance with claim 2, wherein the wild-card data record represents a set of data records, each of the data records of the data record set resulting from a combination of replacing one of the plurality of wild card data elements with one of the corresponding data record elements.

22. A set of language elements associated with a data language, the data language having a schema defining a structure for data records formed with the data language, the set of language elements comprising: a language element configured for insertion into a first data record conforming to the schema, the language element forming a second data record when embedded into the first data record, wherein the second data record represents a plurality of data records conforming to the schema.

23. A set of language elements in accordance with claim 22, wherein the data language allows a hierarchical data structure having a plurality of sub-trees, the language element representing a sub-tree when inserted into the first data record.

24. A set of language elements in accordance with claim 22, wherein the language element represents a range of integers when inserted into the first data record.

25. A set oflanguage elements in accordance with claim 22, wherein the language element represents a range of dates when inserted into the first data record.

26. A set of language elements in accordance with claim 22, wherein the language element represents a range of data strings when inserted into the first data record.

27. A set of language elements in accordance with claim 22, wherein the data language is hierarchical, the language element representing a set of records with a root equal to the root of the plurality of data records.

28. A set of language elements in accordance with claim 27 wherein each child of the root of the set of records is represented by a corresponding child of a root of the language element.

29. A set of language elements in accordance with claim 23 wherein the language element represents all records if a root of the language element is a subtree wildcard.

30. A set of language elements in accordance with claim 22, wherein the data language is extensible Markup Language (XML).

31. A set of language elements in accordance with claim 30, wherein the schema is in accordance with the extensible Markup Language (XML).

32. A set of language elements in accordance with claim 22, wherein the data language is in accordance with a (DTD).

33. A set of language elements in accordance with claim 32, wherein the schema is in accordance with the (DTD).

34. A set of language elements in accordance with claim 31 , wherein the language element is an XML element.

35. A set of language elements in accordance with claim 34, wherein the set of language elements have a uniquely associated namespace.

36. A set of language elements in accordance with claim 22, wherein each of the plurality of documents represents a commercial transaction meeting constraints of a potential market party to the commercial transaction.

37. A method comprising: receiving a document conforming to a machine readable format, wherein the machine readable format provides an original tag for identifying a single value, the document comprising a wild-card tag associated with the original tag; and interpreting the document as a plurality of documents based on the tag, wherein each document of the plurality of documents conforms to the machine readable format.

38. A method in accordance with claim 37 wherein the machine readable format is a markup language schema.

39. A method in accordance with claim 38, wherein the markup language schema is an extensible markup language (XML) schema.

40. A method in accordance with claim 37, wherein the wild-card tag is configured to identify a single field representing a plurality of values, each value associated with a potential transaction.

41. A method in accordance with claim 40, wherein the wild-card tag is configured to identify a range field representing at least a minimum value associated with a first transaction and maximum value associated with a second transaction.

42. A method in accordance with claim 40, wherein the wild-card tag is configured to identify an upper range field representing a plurality of values greater than a minimum value.

43. A method in accordance with claim 40, wherein the wild-card tag is configured to identify a lower range field representing a plurality of values less than a maximum value.

44. A method in accordance with claim 40, wherein the wild-card tag is configured to identify a wild card field representing an infinite set of values.

45. A method in accordance with claim 40, wherein the wild-card tag has a format conforming to extensible markup language (XML).

46. A method in accordance with claim 40, wherein the wild-card tag is configured to identify a market party field representing a plurality of market parties.

47. A method in accordance with claim 40, wherein the wild-card tag is configured to identify the single field representing a plurality of quantities.

48. A method in accordance with claim 40, wherein the wild-card tag is configured to identify the single field representing a plurality of prices.

49. A method in accordance with claim 40, wherein the wild-card tag is configured to identify the single field representing a plurality of times.

50. A method in accordance with claim 40, wherein the wild-card tag is configured to identify the single field representing a plurality of quality grades.

51. A method comprising: receiving a markup language document conforming to at least a format requirement of a markup language schema, the document comprising a tag conforming to the format; and interpreting the markup language document as a plurality of markup language documents based on the tag, wherein each document of the plurality of markup language documents conforms to the markup language schema.

52. A method in accordance with claim 51 , wherein the tag is configured to identify a single field representing a plurality of values, each value associated with a potential transaction.

53. A method in accordance with claim 51 , wherein the tag is configured to identify a range field representing at least a minimum value associated with a first transaction and maximum value associated with a second transaction.

54. A method in accordance with claim 51 , wherein the tag is configured to identify an upper range field representing a plurality of values greater than a minimum value.

55. A method in accordance with claim 51 , wherein the tag is configured to identify a lower range field representing a plurality of values less than a maximum value.

56. A method in accordance with claim 51 , wherein the tag is configured to identify a wild card field representing an infinite set of values.

57. A method in accordance with claim 51 , wherein the tag has a format conforming to extensible markup language (XML).

58. A method in accordance with claim 51 , wherein the tag is configured to identify a market party field representing a plurality of market parties.

59. A method in accordance with claim 51 , wherein the tag is configured to identify the single field representing a plurality of quantities.

60. Α method in accordance with claim 51 , wherein the tag is configured to identify the single field representing a plurality of prices.

61. A method in accordance with claim 51 , wherein the tag is configured to identify the single field representing a plurality of times.

62. A method in accordance with claim 51 , wherein the tag is configured to identify the single field representing a plurality of quality grades.

63. A method comprising: interpreting a document as representing a plurality of documents based on a tag conforming to a format requirement of a schema; and determining the document is valid if each of the plurality of documents conform to the schema.

64. A method comprising: receiving a document conforming to a machine readable format, wherein the machine readable format provides an original tag for identifying a single value, the document comprising a tag associated with the original tag; interpreting the document as a plurality of documents based on the tag, wherein each document of the plurality of documents conforms to the machine readable format and determining if any of the plurality of documents match other documents by determining if any of the plurality of documents have a set of limitations meeting the corresponding set of limitations in the other documents.