WO2001084449A1 - Appareil, systeme et procede permettant de gerer des profils transactionnels representant differents niveaux de participation des parties prenantes a un marche - Google Patents

Appareil, systeme et procede permettant de gerer des profils transactionnels representant differents niveaux de participation des parties prenantes a un marche Download PDF

Info

Publication number
WO2001084449A1
WO2001084449A1 PCT/US2001/014306 US0114306W WO0184449A1 WO 2001084449 A1 WO2001084449 A1 WO 2001084449A1 US 0114306 W US0114306 W US 0114306W WO 0184449 A1 WO0184449 A1 WO 0184449A1
Authority
WO
WIPO (PCT)
Prior art keywords
transaction
fransaction
profile
accordance
profiles
Prior art date
Application number
PCT/US2001/014306
Other languages
English (en)
Inventor
M. Zvi Schreiber
Amit Gal
Original Assignee
Vert Tech Llc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Vert Tech Llc filed Critical Vert Tech Llc
Priority to AU2001259430A priority Critical patent/AU2001259430A1/en
Publication of WO2001084449A1 publication Critical patent/WO2001084449A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/02—Marketing; Price estimation or determination; Fundraising

Definitions

  • the invention relates in general to electronic markets and more specifically to managing transaction profiles submitted by market parties through a communication network.
  • Communication systems are increasingly being used to provide a medium for facilitating commercial transactions, advertising and the exchange of information.
  • the popularity of the Internet has allowed vendors to provide information regarding their products and services, as well as advertise, to a large number of potential customers. Buyers can purchase products and bid electronically through the Internet network.
  • Conventional systems are further limited in that only predetermined discrete terms may be presented to buyers and sellers prohibiting the submission of unique 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. 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.
  • 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.
  • 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.
  • 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.
  • the transaction server provides transaction information to the appropriate market parties.
  • the transaction information may contain a variety of info ⁇ nation and is dependent on the type of transaction profile submitted by the particular party.
  • the transaction info ⁇ nation includes a resulting transaction profile that contains a description of the overlapping limitations on values of characteristic parameters of the proposed transactions.
  • 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.
  • 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.
  • 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.
  • GUI graphic user interface
  • 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 fonn 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 a flow chart of a method of identifying transaction profiles having overlapping limitations.
  • FIG. 12 is an illustration of a example of the use of indexing in accordance with the exemplary embodiment of the invention.
  • FIG. 1 is block diagram of a transaction management system 100 in accordance with an exemplary embodiment of the invention.
  • market parties 102 which may be individuals or electronic trading systems, submit transaction profiles through local processors 104 (user terminals) connected to a communication network 106.
  • a transaction server 112 identifies related transaction profiles, provides information to appropriate market parties 102, commits market parties 102 to transactions and provides other services based on the content of the transaction profiles received.
  • the transaction profiles include limitations to a suggested transaction acceptable to the market party 102 submitting the transaction profile. Since the limitations may allow for more than one value or transaction term, the transaction profile may describe more than one suggested transaction acceptable to the market party 102.
  • the limitations may be values, character strings, or other symbols that limit or define transaction attributes such as transaction terms, market party names, locations, times, dates, product specifications, model numbers, catalog numbers, sizes, quantities or any other information that may be used to describe a transaction.
  • 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.
  • each group includes at least two transaction profiles having overlapping transaction limitations.
  • the terms of the two groups may be related to different types of transactions, subject matter or industries.
  • 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.
  • 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).
  • TCP/IP Transmission Control Protocol/Internet Protocol
  • HTTP Hypertext Transmission Protocol
  • HTTP Hypertext Markup Language
  • 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.
  • the communication network 106 may utilize Ethernet techniques.
  • the communication network 106 may be any network or combination of networks suitable for performing the functions described herein. Examples of other suitable data formats include extensible Markup Language (XML), Standard Generalized Markup Language (SGML), serialized Java objects, and custom vector formats.
  • the communication network 106 may include wireline Internet networks as well as wireless communication systems capable of transmitting the information and messages between the local processors 104 and the transaction server 112.
  • the transaction server 112 includes a transaction controller 108, a network interface 110 and a database 114.
  • 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, 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.
  • 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.
  • Transaction controller 108 may require a transaction controller 108 utilizing a multiple CPU SUN Solaris box with several gigabytes of RAM.
  • the transaction server 112 may be any type of computer processor, processor a ⁇ angement 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.
  • RAM Random Access Memory
  • the transaction controller 108 may be implemented in accordance with Enterprise Java Bean (EJB) to allow management by a Web application server.
  • EJB Enterprise Java Bean
  • the network interface 110 facilitates communication between the transaction controller 108 and the communication network 106 and is implemented using as a Web servlet.
  • 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.
  • 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.
  • HTTP POSTs HyperText Transfer Protocol
  • 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 CORB A for system-to- system trading.
  • CGI Common Gateway Interface
  • Microsoft Active Server Pages and Java Server Pages for browser based trading and direct TCP/IP communications or methods such as Java RMI and CORB A 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
  • ODMG Application Program Interface or vendor specific interfaces and access to relational databases may be through JDBC, ODBC and other commercial and proprietary drivers.
  • JDBC Joint Database Controller
  • ODBC ODBC-based Virtual Database Controller
  • Multiple computers and storage mechanisms can be used to maintain the database 114 allowing the information to be distributed across several machines. Redundant synchronized copies of the database may be maintained to provide reliability.
  • the local processors 104 facilitate communication between the market parties 102 and the transaction controller 108 through the network interface 110 and the communication network 106.
  • the local processors 104 may be any type of processor, microprocessor, computer, personal computer (PC), laptop computer, personal digital assistant (PDA) or processor arrangement or processor combination capable of performing the functions described below.
  • 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.
  • 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.
  • 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.
  • 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 co ⁇ espond to fields in the template.
  • the market party 102 enters information into designated fields within the Web page GUI to create a transaction profile.
  • the transaction profile is transmitted to the transaction server 112 through the communication network 106 using a HTTP POST command and Transfer Control Protocol/Internet Protocol (TCP/LP) techniques.
  • TCP/LP Transfer Control Protocol/Internet Protocol
  • 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.
  • the transaction controller 108 transmits a notification or other transaction information to selected market parties 102.
  • 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.
  • Each of the market parties 102 obtains a transaction profile form from the transaction controller 108 through the communication network 106.
  • 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.
  • URL Universal Resource Locator
  • 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.
  • the network interface 110 transmits a Web page in accordance with Hypertext Markup Language (HTML).
  • HTML Hypertext Markup Language
  • Those skilled in the art will recognize that other types of markup languages 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.
  • GUI Graphic User Interface
  • 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.
  • the market parties 102 may receive information such as the identity of the other market parties 102 having overlapping interests, statistical information, information regarding the other transaction profile limitations. If the identified transaction profiles are firm offers, the parties are committed to a transaction. Otherwise, the market parties 102 may use the transaction information to continue pursuing an agreement with the parties to enter into a transaction. Combinations and adaptations of the above methods provide a sophisticated transaction management system 100 allowing a wide variety of transactions, reports and analysis.
  • FIG. 2 is a block diagram of an exemplary transaction profile template 200.
  • the transaction profile template 200 is a data structure implemented using XML and includes fields for receiving the information entered by the market party 102 in the transaction profile form. As explained above, the market party 102 enters information into a Web page displaying the transaction profile form when submitting the transaction profile.
  • the completed transaction profile form is transmitted through the communication network 106 and received by the network interface 110.
  • the network interface 110 converts the HTML completed transaction profile form to a an XML transaction profile by extracting the appropriate information from the HTML transaction profile and placing it within the transaction profile template 200.
  • the transaction profile template 200 includes a transaction profile classification 202 and a transaction profile description 204.
  • the transaction profile classification 202 provides technical aspects of the transaction profile and includes a profile type indicator 206, an expiration date 208, and a market party designator 210.
  • the profile type indicator 206 describes the type of profile that is being submitted by the market party 102.
  • 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.
  • a market party 102 can reduce the risk of undesirable consequences due to market fluctuations.
  • 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.
  • 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 transaction term rather than a transaction profile classification 202.
  • the transaction profile description 204 includes at least one field (212-220) for a transaction term.
  • 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.
  • the value contained in quality grade minimum 216 field and the value in the quality grade maximum 218 field define a range of values co ⁇ esponding to the quality grade.
  • 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.
  • the data represented in a transaction profile may have a hierarchical structure using XML. This allows groups of parameters 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.
  • 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.
  • safety features have been grouped as children elements of ⁇ safety-features> and are thus wild-carded with a single
  • 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.
  • 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.
  • 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.
  • 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.
  • transaction terms may be described as ranges or may include wild cards co ⁇ esponding 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 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 wliich 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).
  • 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.
  • 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.
  • 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.
  • RFQ request-for- quotation
  • Other market parties 102 may learn of the expression of interest through a search request or through automatic notification upon overlap with their own soft match request and submit an offer limited to the particular market party 102 submitting the soft match transaction profile.
  • the transaction controller 108 forwards transaction information related to market parties 102 submitting transaction profiles having overlapping limitations to the searcher.
  • the transaction mformation includes the identity of market parties 102 submitting requests for soft matches and market parties 102 providing firm offers.
  • 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. This can occur, 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 prefe ⁇ ed 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. The identity of the submitter may be omitted for other reasons, however. The identity may not be included in transaction information, for example, if the type of transaction profile would not be considered to be relevant in another market party's 102 transaction profile.
  • Appendices III and JN illustrate exemplary buyer and seller transaction profiles useful for discussing a matching criteria based on the detailed characteristics of the market parties 102.
  • 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 IN 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.
  • 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.
  • 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.
  • GUI graphic user interface
  • the web servlet 304 retrieves a transaction profile template 200 stored in an XML format either on the network interface 110 or in memory accessible to the network interface 110.
  • the Web servlet 304 transmits the transaction profile template 200 to the local processor 104 where it is displayed to the market party 102 through a GUI 302 as a transaction profile form 306.
  • 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.
  • XSLT extensible style sheet language transformations
  • XSLT is a language that provides a flexible process for the transformations of XML documents to or from other languages or types of XML documents.
  • 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 a transaction profile in a HTTP 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.
  • 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 transaction profiles that will not match the incoming transaction profile.
  • 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.
  • 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.
  • 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.
  • 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.
  • the market provider 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.
  • 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 transaction attributes including transaction terms such as price, quantity, catalog numbers, locations, and colors.
  • the resulting transaction profile is transmitted in an XML format to the network interface 110.
  • the network interface 110 After receiving a resulting transaction profile (322), 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.
  • 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.
  • WAP Wireless Access Protocol
  • An enterprise system 326 provides backend procurement and sales services for the transaction management system 100.
  • the enterprise system 326 is an Enterprise Resource
  • ERP Planning
  • 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.
  • the market parties 102 may be any type of potential participants in a transaction.
  • 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.
  • a reinsurance transaction may include market parties 102 categorized as assume and cede.
  • 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.
  • the buyers 402, sellers 404 and transaction enablers 406 are potential participants in a commercial market of gasoline.
  • 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 co ⁇ esponding 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.
  • the transaction profile template 200 follows any formal XML Data Type Document (DTD) or Schema accepted by the particular market.
  • DTD Data Type Document
  • 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.
  • 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 110 provides a transaction profile form as an HTML Web page using HTTP techniques.
  • 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 ba ⁇ el of gasoline.
  • 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 ba ⁇ els the buyer 402 is willing to buy.
  • the maximum quantity field 512 provides an entry location for the maximum number of ba ⁇ els 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 prefe ⁇ ed grade of oil to be purchased.
  • 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.
  • the buyer 402 may enter tolerance values for defining the gasoline.
  • an RVP field 518 allows the buyer 402 to specify a range for the Residual Vapor Pressure (RVP) of the gasoline.
  • An oxygenates section 520 allows the buyer 402 to enter the desired tolerance values for MTBE and ethanol as a percentage of volume of the gasoline.
  • a shipment location field 522 allows a buyer 402 to enter the location to which the oil should be delivered. In the exemplary embodiment, a state may be designated using a pull-down menu and a zip code can be entered manually by the.buyer 402.
  • a transaction information request field 524 allows the buyer 402 to request the number of days for which the transaction profile will be stored in the transaction server 112. The buyer 402 will receive updates reporting any new matching transaction profiles submitted during the pending period of the transaction profile.
  • 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 pull-down menu including a search request and a soft match (expression of interest).
  • a minimum price field 606 allows the seller 404 to enter a minimum price the seller 404 is willing to receive per ba ⁇ el of gasoline. The seller 404 enters the appropriate mimmum 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 ba ⁇ els the seller 404 is willing to sell in a transaction.
  • the maximum quantity field 612 provides an entry location for the maximum number of ba ⁇ els 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 prefe ⁇ ed 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.
  • the seller 404 may enter tolerance values for defining the gasoline.
  • 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.
  • 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.
  • 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.
  • the following XML element groups the details of the buyer 402 and seller 404 of the transaction.
  • the following template command will generate details of the submitter (in this case acting as buyer 402).
  • the details are retrieved from the database 114 based on the logon name.
  • the command tp inserttext is a template command which represents a value to be filled in by the submitting party in the form in this case in field 604 which is assumed to have been given html name status.
  • 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.
  • the price element is a range which the buyer 402 has a hard-coded mimmum of "0" in the template and a maximum to be filled in from field 606.
  • a prefe ⁇ ed attribute is used to indicate the direction in which any price range should be resolved upon clearing.
  • An e ⁇ or message can be generated using the template convention below. This template convention allows an e ⁇ or message to be specified as a child of tptansertext. If no value is entered for the relevant field, the template will not be instantiated and the e ⁇ or will be returned to the user.
  • the "xphdaterange" 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.
  • 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 mimmum number of ba ⁇ els 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 ba ⁇ els 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 prefe ⁇ ed grade of oil to be shipped.
  • 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 co ⁇ esponding to the type of transaction profile.
  • 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.
  • each incoming transaction profile is compared to all stored transaction profiles to identify nonempty 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.
  • 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.
  • 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.
  • the a ⁇ ows 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.
  • the transaction controller 108 will call reporting logic which will decide which market parties 102 to notify.
  • 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 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).
  • XSLT extensible Styling Language Transformation
  • 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.
  • a resulting transaction profile 900 resulting from the intersection of two or more expressions of interest (soft match) may include one ore more transaction attributes represented by ranges, wild cards or partial wild cards.
  • the exemplary resulting transaction profile 900 in FIG. 9 co ⁇ esponds to a soft match scenario.
  • the resulting transaction profile includes transaction information 918 co ⁇ esponding 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 na ⁇ owly 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.
  • the transaction server 112 receives a request for a fransaction profile form.
  • the network interface 110 receives a request for a fransaction profile form.
  • the market party 102 submits a request for the fransaction profile form by indicating the appropriate URL through a Web browser.
  • the URL uniquely indicates to the network interface 110 the type of transaction profile the market party 102 requires.
  • the network interface 110 transmits a Web page to the local processor 104.
  • the Web page is a fransaction profile form having at least one fransaction that the market party 102 can modify or use to describe a transaction term or other parameter.
  • the fransaction server 112 receives the transaction profile at step 1006.
  • the network interface 110 receives the completed transaction profile form 300 from the market party 102 through the communication network 106 in an HTML format.
  • the network interface 110 converts the fransaction 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 fransaction profile template 200.
  • the fransaction profile is received at the fransaction controller 108.
  • the XML template containing the extracted information is received by the fransaction controller 108 from the network interface 110.
  • the fransaction controller 108 identifies at least two fransaction profiles meeting the limitations of each of the other of the at least two fransaction profiles.
  • the transaction controller 108 analyzes the limitations as described by the each transaction profile to determine overlapping fransaction criteria. The matching process is described in further detail below in reference to FIG. 11.
  • the received transaction profile is stored within the database 114.
  • 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.
  • the fransaction controller 108 creates a fransaction profile result vector co ⁇ esponding to the matches found for the transaction profile.
  • the fransaction information included in the transaction profile result vector may include the identity of the market parties 102 submitting fransaction profiles having overlapping limitations, and the actual fransaction profile or details therefrom.
  • 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.
  • the transaction profile result vector is converted into an HTML formatted transaction information Web page 600.
  • the fransaction information Web page 600 is transmitted to the appropriate market party 102.
  • the info ⁇ nation is presented to the market party 102 through the Web browser using known techniques.
  • FIG. 11 is a flow chart of a method of identifying fransaction profiles having overlapping limitations in accordance with the exemplary embodiment of the invention.
  • the method discussed in reference to FIG. 11 provides an exemplary matching technique for identifying two fransaction profile expressed in XPL that have overlapping limitations (intersect).
  • the result of the match is a new resulting fransaction profile, which represents the intersection of the original fransaction profiles submitted by the two market parties 102. If no match is found, the intersection is an empty set that can be expressed, for example, as an XPL element, " ⁇ xpl:none/>".
  • all co ⁇ esponding elements in matching transaction profiles must match (be the same). Otherwise, the fransaction profiles are not considered to match. This rule applies recursively to all child elements of all the elements in the profiles. Even if only one pair of co ⁇ esponding elements does not match, the result is an empty intersection.
  • the element to be compared is set to the first element in the transaction profiles.
  • the matching engine determines if the element is a pure XML or an XPL. If the matching engine detects an XPL command such as "xpl:", it is determined that the element is an XPL element and the procedure continues at step 1106. Otherwise the procedure continues at step 1108.
  • the matching engine performs an XPL matching procedure.
  • the predetermined rules dictate whether an XPL element of one fransaction profile matches the co ⁇ esponding element in another fransaction profile.
  • the matching engine determines if the XML element in the recently submitted fransaction profile matches the stored fransaction profile that is under examination by determining if the two XML elements are identical. If the elements are not identical, the matching engine determines that the two transaction profiles do not match and the procedure continues at step 1110 where the comparison is labeled as an empty set. Otherwise, the procedure continues at step 1112.
  • step 1114 it is determined whether the XPL element matches in the two transaction profiles as indicated by the procedure in step 1106. If the two XPL elements match, the procedure continues at step 1112. Otherwise, the method continue at step 1110 where the comparison is labeled as an empty intersection.
  • the matching engine determines if the fransaction profiles contain more elements that must be compared. If more elements exist, the element to be compared is incremented by one at step 1116 and the procedure returns to step 1104 to continues the comparison for the next element in the transaction profiles.
  • the procedure determines whether additional fransaction profiles need to be compared at step 1118. If more fransaction profiles must be examined, the matching engine retrieves the next potential matching fransaction profile from the database at step 1120 and returns to step 1102 where the procedure is repeated for the next transaction profile. Otherwise, the procedure continues at step 1122.
  • the matching engine 314 accesses the results of the matching procedure by determining whether any matching transaction profiles have been identified. If no transaction profiles have been identified (i.e. all intersections between the recently submitted transaction profile and the transaction profiles in the database 114 result in an empty intersection), the procedure continues at step 1124.
  • the matching engine generates a message indicating that the no matching fransaction profiles have been found.
  • the message results in the creation of a transaction profile result vector representing a no intersection scenario (no overlapping limitations).
  • the transaction information indicating that no matching transaction profiles have been found is forwarded to the market party 102 submitting the transaction profile and the fransaction profile is stored in the database 114 for further comparisons to other transaction profiles submitted at a later time.
  • the procedure continues as step 1126 where the transaction profiles are prioritized as described above.
  • the matching procedure determines whether a newly submitted fransaction profile is compared to stored fransaction profiles to determine if any of the stored fransaction profiles have overlapping limitations.
  • the matching engine 314 determines if the stored transaction profiles meet the fransaction criteria described in the newly submitted fransaction profile.
  • the matching engine could intersect each incoming fransaction profile with all stored profiles and pass all non-empty intersections to the reporting 316 and/or clearing engines 318. Time and resource efficiency, however, may be gained by using indexing techniques to na ⁇ ow the set of potential matching transaction profiles. Large categories of i ⁇ elevant profiles (i.e. profiles which certainly cannot match) can be eliminated by indexing as described immediately below.
  • the matching engine performs an indexing procedure to efficiently match fransaction 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 fransaction 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 fransaction profile is added to the list of potential match reports to be passed to the reporting 316 and/or clearing engines 318.
  • the fransaction profiles are indexed using a standard free index based on the value of a specific parameter.
  • the resistance of a resistor is selected from the fransaction profile expressed in XPL using the XML path resistor-sale/ohms.
  • a standard search free 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 fransaction profile with a well defined resistance (i.e.
  • the index can be used to find all the stored fransaction profiles with equal resistance.
  • the fransaction 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 limited to the case where many of the stored transaction profiles (and also the incoming fransaction profile) do not have well defined values for resistance but rather have wild cards or ranges or inter-dependence between the resistance and another parameter such as price.
  • the exemplary embodiment also has an indexing scheme refe ⁇ ed 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). This allows concepts from mathematical set-theory to apply.
  • fransaction profiles may be stored at the nodes of a directed acyclic graph (DAG) with the following properties.
  • DAG directed acyclic graph
  • root - there is a single root element which is the fransaction profile which represents the set of all transactions (or of all transactions matching the schema of the marketplace) Ordering - if there is an edge from transaction profile p to fransaction profile q then p is a superset of q.
  • FIG. 12 is an illustration of an example of the use of indexing.
  • the transaction profile 1200 describes smith offering to sell his Blue Ford. All Cars 1202 is the root. The ordering is clearly preserved since every Blue Ford 1204 is a Ford 1206. The nodes are clearly unique. Transitive reduction can be tested by determining that it would be broken if we added an edge directly from All Cars 1202 to Blue Fords 1204 for example. Completeness may also be checked. Closure is also satisfied since the intersection of Blue Cars 1208 with Fords 1206 is Blue Fords 1204. This structure is suitable for containing transaction profiles with wild cards which semantically are sets, whereas many traditional indexes assume that discrete values are being stored.
  • 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.
  • 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 fransaction 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 fransaction 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 fransactions to be performed.

Abstract

Selon l'invention, un serveur transactionnel (112) reçoit une pluralité de profils transactionnels provenant d'une pluralité de parties prenantes (102) à un marché. Les profils transactionnels comportent une limitation définissant une transaction suggérée et indiquant le niveau de participation prévu par la partie proposante (102). Le serveur transactionnel (112) identifie les profils transactionnels qui comportent des limitations se chevauchant. Dans un mode de réalisation, les parties prenantes (102) au marché comportant différents niveaux de participation sont identifiées et les parties prenantes au marché se voient notifier d'autres profils transactionnels ayant des intérêts similaires, ce qui permet aux parties prenantes au marché comportant différents niveaux de participation d'observer le marché électronique.
PCT/US2001/014306 2000-05-03 2001-05-03 Appareil, systeme et procede permettant de gerer des profils transactionnels representant differents niveaux de participation des parties prenantes a un marche WO2001084449A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU2001259430A AU2001259430A1 (en) 2000-05-03 2001-05-03 Apparatus, system and method for managing transaction profiles representing different levels of market party commitment

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US56416400A 2000-05-03 2000-05-03
US09/564,164 2000-05-03

Publications (1)

Publication Number Publication Date
WO2001084449A1 true WO2001084449A1 (fr) 2001-11-08

Family

ID=24253396

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2001/014306 WO2001084449A1 (fr) 2000-05-03 2001-05-03 Appareil, systeme et procede permettant de gerer des profils transactionnels representant differents niveaux de participation des parties prenantes a un marche

Country Status (2)

Country Link
AU (1) AU2001259430A1 (fr)
WO (1) WO2001084449A1 (fr)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5615109A (en) * 1995-05-24 1997-03-25 Eder; Jeff Method of and system for generating feasible, profit maximizing requisition sets
US6188989B1 (en) * 1995-06-16 2001-02-13 I2 Technologies, Inc. System and method for managing available to promised product (ATP)

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5615109A (en) * 1995-05-24 1997-03-25 Eder; Jeff Method of and system for generating feasible, profit maximizing requisition sets
US6188989B1 (en) * 1995-06-16 2001-02-13 I2 Technologies, Inc. System and method for managing available to promised product (ATP)

Also Published As

Publication number Publication date
AU2001259430A1 (en) 2001-11-12

Similar Documents

Publication Publication Date Title
US7865406B2 (en) Methods and systems for electronic commerce facility client-based presentation offer management
US6549904B1 (en) Auction notification system
US7072857B1 (en) Method for providing online submission of requests for proposals for forwarding to identified vendors
US8260682B2 (en) Systems and methods for online selection of service providers and management of service accounts
US7099849B1 (en) Integrated media management and rights distribution apparatus
US8370269B2 (en) System and methods for electronic commerce using personal and business networks
US10074127B2 (en) Generating a recommendation
US7428505B1 (en) Method and system for harvesting feedback and comments regarding multiple items from users of a network-based transaction facility
Muther Customer relationship management: Electronic customer care in the new economy
US20150127502A1 (en) Method and system for processing multiple transaction descriptions received from a client at a network-based transaction facility
US20050055306A1 (en) User-defined dynamic collaborative environments
US6952219B2 (en) System and method for color-coding objects having multiple attributes
WO2000039729A1 (fr) Procede et systeme de traitement et de transmission de donnees electroniques de mise aux encheres inversees
US20080147625A1 (en) Physical item data record creation via cloning a data object in an accessible collection
US20050131799A1 (en) Enhanced online auction method apparatus and system
US7480638B1 (en) Method and system automatically to remind parties to a network-based transaction to comply with obligations established under a transaction agreement
US20070208778A1 (en) Transferring information & records via a data structure for a physical item in the control of a user
US20110099191A1 (en) Systems and Methods for Generating Results Based Upon User Input and Preferences
US20020103721A1 (en) Dynamic catalog for on-line offering and bid system
WO2000054204A2 (fr) Echange de produits et services sur l'internet
WO2002017194A1 (fr) Dispositif, systeme et procede de gestion de transactions entre des parties a un marche provenant de multiples classes de parties a un marche
US20020095325A1 (en) System and method for environmental health and safety management
US20160300271A1 (en) System for offer and acceptance based online classified ads
WO2002023451A1 (fr) Dispositif, systeme et procede pour la constitution de profils de transaction resultants
WO2001088821A1 (fr) Appareil, systeme et procede de gestion de profils de transactions representant differents niveaux d'engagements de partenaires commerciaux

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CR CU CZ DE DK DM DZ EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE TR BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase

Ref country code: JP