WO1999060537A2 - Method and system for facilitating transactions - Google Patents

Abstract

Electronic transactions are facilitated by populating a platform with objects corresponding to each necessary aspect of the transaction. Customer requirements, transactional channels and provider's products are characterized within corresponding objects. Relationships, both desired and actual, are characterized by notation. The notation facilitates interrelation of agreeable corresponding objects to facilitate a transaction. Transactions are monitored in real-time throughout the course of the transaction and propensities of the parties to the transaction are established and used to determine a future course of commercial conduct for the parties.

Description

METHOD AND SYSTEM FOR FACILITATING TRANSACTIONS

RELATED APPLICATIONSCLAIM OF PRIORITY This application claims the benefit of U.S. Provisional Application

60/086,071, filed May 20, 1998.

FIELD OF THE INVENTION

The present invention relates to systems and methods for conducting computer-based transactions. More particularly, the present invention relates to methods and systems for populating a computer based trading platform with objects relating to product sources, brokers, agents or consumers, then facilitating hyper- efficient transactional interconnection between corresponding objects.

BACKGROUND

Commercial exchange is a critical element in the advancement of civilization. In ancient times, the farmer traded his crops to the trapper in exchange for furs, to the lumberjack in exchange for building materials and to the soldier in exchange for protection. This system was manifestly inefficient. Absent effective communication media, the farmer relied on word of mouth to convey the availability of his crops for barter. Similarly, a lumberjack might go hungry because he was unaware of a surplus of crops and a shortage of building supplies not far away.

Print media, telephone, radio, television and now the internet have successively advanced the effectiveness of information exchange in the commercial context. This increased effectiveness notwithstanding, a lingering requirement of these media is concurrence in time and space between one providing an opportunity for commercial exchange and one receptive to such an opportunity. Specifically, an offer for goods placed on the internet is only effective if one seeking such goods stumbles across the location of the offer during the pendency of the offer. It is axiomatic that the effectiveness of commercial exchange can be enhanced as both the breadth and overlap of those placing offers and those receptive to offers is increased. It is similarly fundamental that the efficiency of commercial exchange can be increased as other traditional detractors from commercial exchange, such as lack of a sufficient channel for exchange or lack of an appropriate individual to facilitate the exchange, are reduced or eliminated. Significantly, transactional efficiencies can often be increased by introduction of an intermediary, or "broker" to facilitate commercial exchange between parties.

Within the context of commercial transactions, the role of the broker is well known. Brokers provide a communications network that links buyers and sellers who are often numerous and geographically dispersed. In exchange for providing this communications network, brokers are rewarded with a commission upon successful completion of a transaction.

This model of the brokered transaction between a buyer and a seller has been applied to industries as diverse as the stock exchange, insurance, wholesale vegetables and exotic automobiles. In fact, brokered transactions account for billions of dollars of sales annually on a worldwide basis. Accordingly, this unrelenting demand and increased need for brokerage services has caused reevaluation of the basic concept of brokering in hopes of developing a superior vehicle for facilitating commercial transactions.

Inefficiency within this conventional brokerage model is found, first and foremost, with the broker. Typically, brokers have a certain level of expertise or specialization regarding a particular product or group of products. While a broker may be an authority on pork belly futures, it is quiet unlikely that he would be able to provide any meaningful assistance in brokering a transaction related to life insurance. Similarly, a mortgage broker who might be very capable of serving his client's needs in obtaining the best and most appropriate home mortgage would likely be unable to broker a transaction involving a classic automobile.

Aside from the limited capabilities of typical brokers, consumers are sometimes resistant to dealings with brokers. Many brokers have a reputation for selectively advocating only certain products to consumers, their recommendations not necessarily being in the customer's best interest. Broker compensation is yet another important factor in the dynamic of conventionally brokered transactions. Typically, brokers are paid a commission based on the products they sell. Commissions for individual products are very often established on a product-by-product or a deal -by -deal basis. More specifically, insurance company A may have a more beneficial policy to a particular consumer than company B, but because company B offers a greater brokerage commission, the broker may be tempted to more aggressively market the products of company B. Accordingly, companies who rely on brokerage services for the sales of their products are forced to pay brokers commissions that are calculated, at least in part, on the "going rate" for commissioned sales of similar products. Obviously, this adds an additional transactional cost which is ultimately paid by the consumer.

In addition to the aforementioned negative aspects of conventional brokering practices as they pertain to the consumer, yet another serious limitation exists. Specifically, because of the specialization of brokers within a particular class of products, a consumer who desires to initiate several brokered transactions must locate a different broker for each different category of products. Not only are there logistical difficulties posed by having to locate such brokers, the practical difficulty of having to deal with a different broker for each different product can also be daunting and time consuming. Finally, another shortcoming with the conventional brokerage model is evident from the seller's standpoint. Sellers must attempt to regulate brokers who are, in many cases, acting on behalf of the seller. For instance, because a significant amount of information about a particular product must be delivered from a seller to a buyer via the broker, the seller must somehow insure that the broker selling the seller's product has an adequate level of understanding concerning the products he is brokering. Without this level of understanding, inefficiencies in the commercial exchange can be increased.

For the many advances in electronic commerce which have benefited commercially brokered transactions, little has been done to solve these basic problems. Accordingly, a need exists for a method and system for facilitating transactions which overcomes the above specified limitations of the conventional models of commercial exchange. There is an additional need for such a system which can be implemented using existing computer and electronic communication devices. There is another need for such a method and system of commercial exchange in which the introduction of parties is done in such a manner as to increase the likelihood of an ultimate commercial exchange between the parties. A further need exists for such a method and system that facilitates identification of peripheral parties and channels most advantageous to execution of the commercial exchange. Finally, a need exists for a method and system which, while satisfying the previously stated needs, provides mechanisms for continually improving the effectiveness and efficiency of commercial exchanges undertaken therein.

SUMMARY OF THE INVENTION

The present invention meets the needs described above by providing a computer-based platform for facilitating, processing and settling a transaction without the limitations of the conventional brokerage model.

First, the present invention allows introduction of potential components of a transaction to the platform. A basic premise of the platform is that each component of a transaction can be classified as either a customer, an offer or a channel. For the platform to facilitate processing and settling a transaction, these components become transactional participants for the purpose of facilitation of commercial transactions between customers and offers.

The platform may be "constructed" in an object-oriented environment, the platform being populated with component objects each corresponding to a component of a transaction. Within each component object resides at least one related member object, a member object being populated with member information. Examples of such member information within a member object or named objects might be member profile, member products, member services, member details, member preferences, member needs and member capabilities, to name a few.

After the platform has been populated with member objects falling within each of the three component objects necessary to effect the transaction, an identification means identifies potentially compatible components of the transaction from among the pool of potential transaction components residing on the platform. This may be accomplished by an interrelational means for interrelating various member objects based on corresponding member information contained within the member objects. The desire of a party to conduct a transaction is embodied in the interrelation. The interrelation is accomplished by use of an articulated notation ("Notation") which provides interrelational criteria.

Once the interrelational criteria has been introduced to the platform by an articulated Notation, requirements match and the propensities of each potentially compatible component of the transaction are evaluated. The results of the evaluation are then discriminated to separate the potentially compatible components of the transaction into categories including undesirable components of the transaction and compatible components of the transaction. Thereafter, compatible components of the transaction are presented to each party corresponding to the compatible components of the transaction. Finally, the transaction is executed (processed and settled) between agreeable opposing corresponding parties to the transaction.

Potential transactions are modeled by a notational "language". A Notation is constructed of elements corresponding to a plurality of component objects. More specifically, the Notation may be constructed of specific member objects from within their respective component objects, and may reflect the commercial desires of the individual or group desiring to conduct a platform-based transaction. Once the plurality of component objects have been selected, they are interrelated within the Notation by at least one operator. The operator has predetermined interrelational characteristics capable of defining interrelations between the object components of the Notation. Importantly, operators can be active or passive. When the platform and the related Notation are implemented, a method for optimizing electronic transactions is realized. Specifically, objects populating the platform interrelate according to the articulated Notation to find other compatible objects. As the evaluation process takes place, the exchange of information between parties may be monitored in real-time throughout the course of the exchange. Exchanged information can be used to establish, for each potential party to a transaction, a propensity for that party. Once propensities have been established for a statistically significant number of potential and actual parties to a transaction, quantitative, stastistical and hypothetical assessment of these propensities and their related parties can be made so that a future course of commercial conduct based on the assessment of these propensities can be implemented. Importantly, the interrelation between objects populating the platform are multiplexed so that a party desiring to undertake a commercial transaction can simultaneously examine available offers and channels corresponding to a multitude of different transactions without being encumbered by logistical and other limitations of conventional brokerage systems. Accordingly, it is an object of the present invention to provide a method and system for facilitating transactions which overcomes the above specified limitations of the conventional models of commercial exchange. It is another object of the present invention to provide such a system which can be implemented using existing computer and electronic communication devices. Yet another object of the present invention is to provide a method and system of commercial exchange in which the introduction of parties is done in such a manner as to increase the likelihood of an ultimate commercial exchange between the parties. A further object of the present invention is to provide a method and system that facilitates identification of peripheral parties and channels most advantageous to execution of the commercial exchange. A final object of the present invention is to provide a method and system which, while satisfying the previously stated needs, provides mechanisms for continually improving the effectiveness and efficiency of commercial exchanges undertaken therein.

BRIEF DESCRIPTION OF THE DRAWINGS Fig. 1 is a diagram of an exemplary embodiment and exemplary environment for operation of the present invention.

Fig. 2 A depicts an exemplary graphic representation of an exemplary template for information fields.

Fig. 2B depicts an exemplary graphic representation of an exemplary template for information fields.

Fig. 3 depicts a representative example of a customer needs template. Fig. 4 depicts an exemplary offer profile template

Fig. 5 depicts a template corresponding to an offer needs template.

Fig. 6A depicts an exemplary handoff compilation in accordance with an embodiment of the present invention. Fig. 6B depicts an exemplary handoff compilation in accordance with an embodiment of the present invention.

Fig. 6C depicts an exemplary handoff compilation in accordance with an embodiment of the present invention.

Fig. 6D depicts an exemplary handoff compilation in accordance with an embodiment of the present invention.

Fig. 7 depicts an exemplary customer handoff compilation in accordance with an embodiment of the present invention.

Fig. 8 depicts an exemplary hand back template in accordance with an embodiment of the present invention. Fig. 9 A depicts an exemplary hand back template in accordance with an embodiment of the present invention.

Fig. 9B depicts an exemplary hand back template in accordance with an embodiment of the present invention.

Fig. 10 is a graphical snapshot of the status of an agreed transaction. Fig. 11 is an exemplary screen shot of a yield screen in an embodiment of the present invention.

Fig. 12 illustrates an exemplary presentation of information which may be gleaned from transactions occurring on the Platform.

Fig. 13A depicts an exemplary breakdown graph useful in the method of the present invention.

Fig. 13B depicts an exemplary breakdown graph useful in the method of the present invention.

DETAILED DESCRIPTION The present invention satisfies the foregoing criteria. Stated generally, the present invention comprises a system and method for facilitating, processing and settling a transaction without the limitations of the conventional brokerage model. More specifically, a trading platform is populated with objects related to customers, offers and channels, which are, themselves, objects on the platform. Through interaction between objects populating the platform, customers, offers and channels are identified, monitored and matched to facilitate commercial transactions. THE PLATFORM

Fig. 1 is a diagram of an exemplary embodiment and exemplary environment for operation of the present invention. Generally, the platform 10 of the system is implemented on a distributed hardware and software infrastructure and is populated with component objects corresponding to each necessary component for a commercial transaction. Because all commercial transactions require a buyer, a seller and a channel for exchange ("participants"), the platform 10 of the system is populated with a corresponding customer object 20, offer object 40 and channel object 60. The specific relationships between the participants to the transaction will be later described.

Each of the category or "component" objects 20, 40 and 60 are populated by respective related member objects. The customer component object 20 is populated by member objects corresponding to particular customers. For example, Customer 1 ("Cl") 22, Customer 2 ("C2") 24, Customer 3 ("C3") 26 and Customer 4 ("C4") 28 are each representative member objects which relate to (and populate) customer component object 20.

Each member object, such as member object 24 relating to Customer 2, is constructed of information derived from templates. The templates are analogous to forms which contain information relative to the customer and the customer's desire to engage in a particular type of commercial transaction. Regarding Customer 2 24, the C2 member object 24 may be populated by a details template 30, a profile template 32 and a needs template 34. Although these templates can exist in any of a virtually unlimited array of formats and contain a virtually unlimited array of content, the details template 30 might, for instance, contain information pertaining to Customer 2 such as residence, employer, age, gender and a multitude of other "background-type" bits of information. The profile template 32 might contain information such as that pertaining to Customer 2's buying history, product preferences and the like. The Customer needs template 34 might typically contain information regarding the specific product or service (or a multitude of products or services) in which Customer 2 is interested. Within the context of the customer component object 20, each member object is populated with information so that the system, through its later-described functionality, can identify potential compatibility between customers, offers and channels.

In the same fashion as the customer component object 20, an offer component object 40 also resides on the Platform 10 as a necessary component of the platform's tertiary market space. The offer component object 40 is populated by a virtually unlimited number of offer member objects such as 42, 44, 46 and 48. Each offer member object corresponds to a particular offer that a participant on the Platform 10 desires to make available to prospective customers via the Platform 10. For example, offer member object "Ol" 42 may correspond to an offer from an automobile dealership desiring to sell an automobile or group of automobiles to certain buyers. Offer member object "O2" 44 may correspond to a life insurance policy that is available to qualified individuals, the member object 42 being populated by template "T-02" 45 which contains information regarding the specifics of the offer. These member objects can also contain behavior or methods such as quotation calculations. Importantly, templates can be used to describe the transactional relationship between members and salient information and methods. Technically, in the preferred embodiment, templates are not contained by members, but serve as a "view" on the member for the purpose of a transaction. For simplicity of explanation, however, various members may be casually indicated as "containing" certain templates. In the case of a life insurance policy, for instance, specifics would be numerous and would range from information regarding the type of policy (such as term or whole life), qualifications required of those who desire to obtain the policy and, of course, the cost of the policy. Offer component object "03" 46 may correspond to a sale of livestock such as cattle from a breeder to a cattle farmer. Returning to the mortgage example, offer member object "04" 48 may be an offer of a particular mortgage product by an entity such as a mortgage company. For offer member object 48, as for other member objects populating the Platform 10, the offer member object 48 is populated by an array of templates, such as "Tl-04" (50) and "T2-04" (58), shown as representative examples. There is no practical limit to the number of templates populating a given corresponding member object, either in the offer, customer or channel component objects. In the context of offer member objects, the more complicated the product, the more information-intensive the details and the more restrictive the customer selection process, the more templates would likely exist.

As previously described in the context of customer component objects, templates populating an offer member object such as offer member object 48 may include a profile template 50 and a needs template 58. Importantly, within the context of the Platform 10, templates may be constructed to accomplish far more than simply collecting and relaying information. More specifically, as indicated within profile template 50, a template may be able to determine a state 52, calculate an algorithm 54 or perform a method 56. As a result, a template such as profile template 50 may be constructed so that it can execute a complex series of transactional dynamics and, ultimately, make a determination as to whether a particular customer (as characterized by a customer member object) is a suitable party to complete an offered transaction. Importantly, the previously described general mechanics of facilitation and execution of commercial exchange comprise a new and improved method for conducting such transactions. This new method will be hereafter discussed with reference to relating structure and functionality. If a particular offer member object is determined to be not compatible with a particular customer member object, an alternative embodiment of the present invention may identify particular shortcomings in the customer member object in question and then, through a linking process, refer the customer member object to a different offer member object, presumably offered by the same offeror. This linking process may exist in addition to typical "matching" processes inherent implemented in the preferred embodiment of the platform 10. More specifically, the channel acts as a mediator in matching customer and offer.

To complete a transaction between customer and offer, a channel must be identified. The channel component object 60 is populated with a plurality of channel member objects such as "Chi" 62, "Ch2" 64, "Ch3" 66, "Ch4" 68. Each channel member object 62, 64, 66 and 68 corresponds to a "commercial conduit" for exchanging goods, services, money and the like between customers and offeror s desiring to consummate a commercial transaction. For example, channel member objects may comprise conventional mail, electronic mail, Internet, cash-on-delivery (COD) and many more. As with member objects of other components, channel member objects such as "Ch3" 56 are populated by related templates "T-Ch3" 70, wherein the particular requirements, needs, etc. of the particular channel member are expressed. For instance, if channel member object "Ch3" 66 related to the Internet, template T -Ch3 70 (and any other associated templates relating to member object Ch3 66) might require information relating to requirements for Internet access such as communication link type, computer type and capabilities, etc.

If a customer corresponding to a customer member object has indicated a willingness to participate in a specific transaction over the Internet, and if a particular Offeror corresponding to an offer member object has indicated a similar interest, both parties may be "quizzed" for appropriate information (if not already available on templates corresponding to the particular customer member object or offer member object). If information gleaned from both the customer member object and offer member object satisfy the needs and requirements of the channel member object, and if the agreement as to the specifics of the commercial transaction are otherwise agreeable between the customer and the Offeror (and their related member objects), the transaction may be completed via the particular channel member object corresponding to a particular channel. For instance, the information is either attached persistently to the member where it is deemed immutable to the current transaction, where it is considered perishable. For example, "address details" would be persistent and reusable, whereas "number of seats on an airplane" would be transient to the transaction. Referring now to Figs. 2 A and 2B, an exemplary graphic representation of an exemplary template for information fields is shown. The template may be used to formulate a customer profile input such as customer profile template 32 shown in Fig. 1 and described hereinabove. The templates may be self-completed, completed over the phone, the internet, on paper or in person. More generally, templates are populated by the platform in the activities of subscription, demand and supply elicitation that make up transactions.

Although the information provided by, and collected within, a template such as the customer profile template 32 may be formatted and arranged in any variety of arrangements without materially altering the functionality of the template, a graphic, tabular representation such as that indicated in Figs. 2A and 2B is a preferred arrangement. Accordingly, information contained in customer profile template 32 is arranged in columnar form, wherein each column corresponds to a portion of information generic to subject area. Subject areas may occupy one row of the template. As an example, referring to the first row of the template shown in Fig. 2A, information relating to annual income is captured. More specifically, the system name 210 for the first row is "annualincome" 212. The field name 220 is Annual Income 222 and the description column 230 allows description of the requirement. Option column 240 provides options 242 (should they be relevant) and column 250 provides a simple text hint 252 to assist individual or agent should the information requested by the row of the template 32 be unclear. Question column 260 may contain any number of prompting questions 262 to be asked of the user during the "quizzing" process. The prompting questions 262 may appear in the form of video prompts on a computer screen, audio prompts via telephone, questions posed by a live agent, or the like. Finally, response column 270 contains a response field 272 for entry of the customer's response to the inquiry regarding annual income.

Within a template, fields relating to an informational category may also be structured in any number of ways. For instance, referring specifically to employment status 214, the consumer may be limited to selection between a predefined set of options 244 from within the option column 240. Similarly, fields within the template 32 may be linked. Referring now to Fig. 2B, a "number of applicants" field 226 in column 220 is linked to the "other applicants income" field 228. If a particular customer indicates that there is more than one applicant, the consumer will be asked to provide certain information regarding the other applicant. This method of linking is known as "simple linking" in which a particular answer in one field of the template precipitates a request for information in a different field of a template. "Complex linking" is also available in the preferred embodiment of the present invention. By complex linking, a customized mathematical arrangement can be implemented whereby various different fields can be scored or otherwise weighed so that component information is considered and transactional decisions are made based on a predictable sliding scale. In such an arrangement utilizing weighted variables, certain answers to certain questions may immediately disqualify a particular customer for consideration for a particular offer. Short of that, though, if a customer provides a certain response to a first field, a certain response to a second field, and a certain response to a third field, additional information may be required that would not have been required had the customer's responses in the first, second, or third fields been different. Similarly, referring back to the mortgage example, if a mortgage company desires to "spread the word" about its products and services in a particular geographical target area, the mortgage company may choose to impose more lenient or "sliding" qualification standards based on the potential customer's residence. In other words, if an individual in the targeted area desires to obtain a mortgage, the prerequisites for obtaining such funding may be less stringent for that particular customer than for a customer from a different area where the mortgage company is not so concerned about increasing its market share. This and other analogous functionality can be "built in" to templates in the present invention by utilizing complex linking principles.

When the customer has completed the customer profile template, the template 32 then exists within the related customer member object 24 to be used when identifying a potential match for the customer's needs from members of the offer component object 40. Storage of information such as that which is captured on the template 32, in addition to the many other varieties of information collected and developed by the present invention, may be accomplished using any variety of well known storage media and techniques. Because such media and techniques are well known and vary greatly in their configurations and implementations, specific choices as to which media and techniques will be selected is determined by such factors as the physical configuration of the particular embodiment of the invention, as well as the capacity and system requirements of such an embodiment.

A characterization of what a customer is actually looking for may be captured on a customer needs template 34, as depicted in Fig. 3. Fig. 3 depicts a representative example of a customer needs template 34. The customer needs template 34 of Fig. 3 comprises columns relating to field name 310, description 320, options 330, hint 340, questions 350 and default 360. Each row contemplates an aspect of a product the customer may need. In the present example of a residential mortgage, rows for subject areas such as mortgage amount 312, loan term 314, loaned to value 316 and qualification 318 are shown. As with the previously described customer profile template 32 shown in Figs. 2 A and 2B, the fields of the customer needs template 34 defined by the columns and rows enable a customer to indicate the type of product desired. For example, field 342 provides an explanation of mortgage amount row 312. More specifically, the field 342 allows input as to the amount the customer wishes to borrow.

Certain fields, such as loan term field 364, contain a default number in the case of loan term field 364, the default is 25 years. Other fields such as loan-to-value description field 326 execute a calculation. Furthermore, in qualification row 318, an explanatory field 328 provides explanation as to the applicability of the field, and question field 358 requests information regarding a current qualification amount, in the event that the mortgage sought is a re-mortgage.

Referring now to Fig. 4, an exemplary offer profile template 50 is shown. In the preferred embodiment, offer profile template 50 comprises columns corresponding to system name 410, field name 420, description 430 and options 440. Rows are headed by subject headings such as providername 412, providerphone 414, productname 416 and incentivetype 418. As with the other previously described templates, the columns further elaborate the specific information requested by the template 50. Additionally, informational fields may be constructed so as to predefine a certain group of options, such as has been done for the incentivetype 418 row, under the options 440 column. More specifically, field 448 provides several selection options relevant to incentive type 418.

Referring now to Fig. 5, a template corresponding to an offer needs template 58 is shown. Again, as with the other previously described templates, columns correspond to categories of information and rows correspond to individual informational items. In the depicted offer needs template 58 example, columns correspond to system name 510, field name 520, description 530 and options 540. An example of some of the specific information corresponding to rows is accountantsletter 512, employmentstatus 514, finacialproblems 516 and property type 518. Visual inspection of the exemplary offer needs template 58 reveals that fields exists for input of information, elaboration on information and selection between information options.

In an embodiment of the present invention, executive summary or "handoff information compilations may be created to facilitate information exchange between parties. The purpose of a handoff is for the settlement of the transaction between the parties. The handoff contains information appropriate and necessary for such settlement. A handoff to the offer member is analogous to an application form while a handoff to the customer member represents the specific terms of the arrangement agreed. Such a handoff compilation 80 is depicted in Figs. 6a-6b. Generally, handoff compilations are created by selectively merging predetermined template subsets from among parties whose mutual desire for commercial exchange have been agreed bilaterally. Handoff compilation 80 reflects the compilation of information such as that which might be provided to a mortgage provider if there is a correspondence between a customer member object and an offer member object as determined by. In such a situation, information could be gleaned from templates populating each of the respective member objects and compiled into a form such as handoff compilation 80. As depicted in Figs. 6a-6b, a handoff compilation of this type may include columnar categories such as system name 610, field name 620, description 630, options available 640 and context 650. For each bit of relevant information important to the particular mortgage provider, a set of information categories 660 are provided. Such information categories may include title 662, surname 664, suffix 666 and date of birth 668. Obviously, for the mortgage provider to have enough information regarding the potential products and customers, considerably more information fields would be necessary. Examples of other such representative information fields are also depicted in Figs. 6a-6b. Notably, the depicted handoff compilation 80 contains a column for context information 650. It is advantageous in the present invention to categorize transactions and potential transactions in terms of their contexts. In the preferred embodiment of the present invention, contexts are expressed in terms of a notational language, examples of which are seen in column 650 and will be later explained in detail.

Referring now to Fig. 7, a similar handoff compilation 82 is developed to effect a handoff of information to the customer. In a fashion similar to the handoff compilation 80 to a mortgage company, the handoff compilation 82 to the customer also comprises columns 710 specifying categories of information and informational fields 720 comprising information that would be relevant and helpful to the customer in determining whether it would be advantageous to proceed with this transaction under the present terms. When a customer and an offer correspond, certain information about each is

"handed back" to the other for the purpose of further evaluation. This "hand-back" may be facilitated by the accumulation and presentation of certain information in template form such as hand-back template 84, an example of which is depicted in Fig. 8. More specifically, hand-back template 84 reports progress on leads which have been handed off to a content provider, which may be an entity supporting a particular offer. As with other previously referenced templates, hand-back template 84 comprises a series of columns and any number of rows necessary to convey relevant information in a meaningful way. In the illustrated example of Fig. 8, hand-back template 84 comprises a column for field to be tested 810, test 820, and fields to be tested against 830. Each of these columns may be exercised against information such as mortgage amount 812, mortgage term 814 and number of applicants 816. The description of an exemplary hand-back process continues in Figs. 9a and 9b (Fig. 9b being a continuation of Fig. 9a), with hand-back template 86. Hand-back 86 is similarly comprised of columns such as customer criteria 910, test 920 and mortgage criteria 930. For each column, information rows exists such as applicant status 940. Applicant status rows 940 may contain a variety of fields for information related to the applicant or applicants, some of the informational fields being contingent upon responses provided in previous fields. Specifically, in row 942, a particular response to inquires in row 942 may precipitate a necessity for entry of information in row 944. Similarly, information received in row 944 may precipitate a need for inclusion of information in row 946. A similar dynamic exists with respect to rows 950 and 952, which may require entry of information should an answer in row 942 precipitate response. Fig. 9B is, as previously mentioned, a continuation of Fig. 9 A and includes numerous additional rows for inclusion of additional material necessary for analysis of the potential transaction after hand-back. There is no practical limitation to the number, type or configuration of templates used to convey information to and from the potential parties to a transaction. The preceding examples are provided for illustration and not limitation. NOTATION

In the present invention, the "vocabulary" for articulation of the semantics of a business transaction between participants is accomplished by a notational language (the "Notation"). The Notation is a relationship-modeling language for all commercial participants in transactions taking place on the Platform 10. The Notation describes the particular three participant dynamics of the market space— the system, correspondingly, has these notational interpreters communicatively interconnected into its behavior. The Notation makes it possible to document, and therefore manage, the past, present and likely future relationships between multiple parties, simultaneously.

The Notation may incorporate a number of advantageous features. First, the Notation is precise and can be used to contractually define all components of a transaction, calculate the exact value of settlements of the transactions, perform regulatory and data protection audits of transactions, etc. Second, the Notation is constructed so that it can be directly projected to Java and other object codes and, therefore, it is usable to facilitate rapid application development. Third, the Notation can serve as a succinct language to communicate and implement the dynamics of the commercial exchange. Advantageously, one such dynamic is the absence of a requirement for algorithms to have single linear solutions nor for values to be rational numbers. The Notation can facilitate communication of certain market attributes (like creditworthiness, for instance) completely and accurately, without having to disregard or "freeze" the non-linear elements in order to manage them robustly on a production computer system. The Notation is designed for dynamic co-dependent phenomena, like supply and demand functions, risk and underwriting exposures, and the like.

Fourth, the Notation can be used to easily and quickly design, manufacture, distribute and settle highly sophisticated risk-based products and services.

In its implementation in the present invention, a Notation for a commercial transaction is constructed by selecting "words" corresponding to a plurality of component objects populating the Platform 10, the component objects relating to offer objects, customer objects and channel objects. The words corresponding to the plurality of component objects are then interrelated within the Notation by at least one operator, the operator having predetermined interrelational characteristics. In an embodiment of the present invention, the notation may be generated by a platform licensee, an exchange manager or another party or mechanism having access to the core platform.

In sum, the Notation represents the possible dynamics in the market space. If a new category of offers is agreed, the objects corresponding to the Notational description of potential transactions are created by developers. As these objects are named in the Notation, the system knows what to do with them.

In a preferred embodiment of the present invention, operators such as " . " , " I ", ":", "::" and ">" may be implemented. In the preferred embodiment of the present invention, the " . " operator is the membership operator for indicating that a particular individual is a member of a particular class. For example, the Notation "MirrorCustomers.Angie" indicates that Angie is a member of a class of people who subscribe to a publication known as the Mirror. Similarly, the Notation "TeleAgents.Marjorie" indicates that Marjorie is a member of the class of people known as TeleAgents.

The transaction operator may be denoted as " | " and may convey participation of objects in relationships. In other words, for a potential transaction, a supplier makes available its supply to the customer category and the customer must register a demand for the supplier category. Category to category templates describe possible relationships, such as the Notation "MirrorCustomers | TeleAgents" , which indicates that Mirror customers may be accessed on the TeleAgent channel. Similarly, the Notation "TeleAgents | MortgageOffers" indicates that members of the TeleAgent channel can sell mortgage offers. From yet another perspective, the Notation "MortgageOffers | Mirror Customer" indicates that mortgage offers can be sold to MirrorCustomers. When a category framework exists, an individual member of a category can subscribe its supply or demand to the other category. As an example, the Notation " MortgageOffers. Abbey | MirrorCustomers" indicates that the Abbey mortgage offer is available to be sold to MirrorCustomers. Similarly, the Notation "MortgageOffers | MirrorCustomers.Angie" indicates that Angie has subscribed her demand for the MortgageOffer category. In other words, Angie has indicated that, as a Mirror customer, she is interested in obtaining a mortgage offer.

Importantly, the Notation may be implemented to express transactional context. Transactional contexts present a view of participants in a commercial transaction. Two types of context are identified: A passive context contains the actual or derived values that describe an object's interface with another object or category, while an active context contains the behavior of an object that describes its relationship with another object or category. In general, a passive context contains the informational content salient to the relationship between the participants and a transaction. An active context, on the other hand, provides the models which enable one participant to take action relative to another participant. An active context references the appropriate passive contexts which provide the input for its models, then directs execution of the specified action. More specifically, a passive context may represent the requirements or properties of the member of a category that forms its interface to a subscribed category. For example, the Notation "MortgageOffers | MirrorCustomers.Angie" indicates that Angie has subscribed her demand for a mortgage offer. This demand is expressed in terms of "requirements", which are articulated by the following transactional context: "MortgageOffers: MirrorCustomers. Angie". This is a demand side context containing the properties of Angie that relate to her requirements of a mortgage offer. In other words, this Notation relates to the amount and other terms of the mortgage she wishes to apply for. This set of values is mirrored by the following supply side passive context: "MirrorCustomers. Angie: MortgageOffers", which represents the properties of Mirror customer Angie that all members of the MortgageOffers categories are interested in. The difference between the context is subtle— the demand side context speaks for the customer member, while the supply side context speaks for all members of the supplier category with respect to the customer member. For a transaction to take place, a supplier member must have subscribed its supply to the customer category. This implies the following transaction: " MortgageOffers. Abbey | MirrorCustomers" and yields the following passive transactional context: "MirrorCustomers: MortgageOffers. Abbey", which details the requirements of the Abbey mortgage offer that apply to all Mirror customers. Yet another passive transactional context related to the example transaction is "MortgageOffers. Abbey: MirrorCustomers", which refers to the supply characteristics of the Abbey offer available to all MirrorCustomers, such as the interest rate and cashback offered. These contexts relate to the requirements and preferences of the respective parties and represent the properties of the member side that are supplied to facilitate a transaction. These contexts are termed "passive" because they describe generic requirements and do not describe any preference or propensity for the relationship.

When a transaction has been agreed, duplex passive contexts can be used to describe the outcome. For example, the passive context "MortageOffers. Abbey: MirrorCustomers. Angie" represents the outcome of the transaction with respect to the customer, such as the mortgage quotation and the terms Angie requires. The flip context, "MirrorCustomers. Angie: MortgageOffers. Abbey" describes the outcome for the content provider, such as the contact and settlement details needed to activate the commercial transaction.

Transactional active contexts utilize the appropriate values in the passive context to form a view of the transaction from the perspective of one participant to another . In the active context " MortgageOffers . Abbey : : MirrorCustomers . Angie " , two things are represented. First, the active context is used to determine whether the requirements of Angie for a mortgage offer are met by the Abbey member. If the answer is known, the active context can be used to select or deselect the Abbey offer for Angie. Second, the active context represents the probability that Angie will proceed to a transaction on the Abbey offer, along with the value of the transaction, factoring in the probability of successful completion of the transaction. This information can be useful to the Abbey mortgage company in comparing its mortgage offer to comparable products. More specifically, "blind" information regarding other mortgage companies may be made available to Abbey by the platform so that Abbey can adjust its practices or criteria in order to increase its profitability, if it so desires. The requirements and probability methods are models using the parameters from the appropriate passive contexts.

The mirror of the above stated active context can be expressed "MirrorCustomer. Angie:: MortgageOffers. Abbey", which indicates whether member Angie meets the requirements of Abbey for a Mirror customer, as well as the probability that the Abbey offer will proceed to a transaction with Angie, along with the value of the offer. The compound requirements can be used to describe whether a transaction between the parties is possible, while the compound probability can be used to indicate the likelihood of success of a transaction between the parties, along with the value of the offer.

In the preferred embodiment of the present invention, the Notation extends to describe other transactional relationships. For example, a generic interrelationship between categories can be modeled using: MirrorCustomers ::LoanOffers, which represents the probability that a customer sourced from the Mirror will be good candidate for a loan. This allows the possibility of targeting a MirrorCustomer for loan products without knowing the characteristics of that customer; only that she was sourced from the Mirror customer base. In this instance, aggregated Mirror customer, or "Meta-member" characteristics will be substituted, as described below.

A Meta-member of a category is an aggregated description of a categories' membership. The Meta-member can be used in the absence of an actual member to allow propensity modeling with active contexts. For example, the relationship "MirrorCustomers:: MortgageOffer. Abbey" can be used to calculate the propensity of the Abbey offer for a customer sourced from the Mirror. Meta- members generally have distributions instead of values for their attributes. The distribution for income, for example, may be different for a Mirror customer as opposed to a customer of a different publication which may be generally purchased by a different socio-economic class. This distinction is helpful in targeting inventory.

The syndication of content can be expressed constructs such as MorgageOffers: :BuildingInsuranceOffers, which represents the likelihood that a transaction involving a mortgage will yield a transaction involving building insurance. Further, MortgageOffers. Abbey ::BuildingInsuranceOffers.CU describes a relationship between two specific offers. More specifically, an agreement between content providers that will encourage or stipulate that the CU BuildinglnsuranceOffer is to be sold with the Abbey mortgage. Notation Example

Still referring to the above-referenced mortgage example, the following specific example demonstrates use of the Notation in the example of transactional flow. First, an offer must be published for a customer source. In the present example, the mortgage provider ("Abbey") publishes an offer to be advertised to the Mirror customer base. Characteristics of the offer, such as quotation, terms and conditions, are captured in templates within the Abbey offer member object. The requirements to qualify a Mirror customer for the mortgage are also specified. This action is represented by the Notation "MirrorCustomers | MortgageOffers. Abbey". From a supply context, the Notation would be " MirrorCustomers : MortgageOffers . Abbey " , which Notation provides the quotation in terms and conditions for the offer to the Mirror customer base. From a demand context, the Notation would be "MortgageOffers. Abbey: MirrorCustomers" from which the qualification requirements from the Mirror customer base are provided.

Next, the offer is configured for a particular channel type. In other words, requirements must be provided of the offer to be sold over a particular channel (such as the telemarketing channel) such as the agent's qualifications. The product class of the offer is also given at this time. This relationship can be expressed as "TeleAgents | MorgageOffers. Abbey". More specifically, from a demand context, "TeleAgents: MortgageOffers. Abbey" provides the qualification requirements for a TeleAgent, while "MortgageOffers. Abbey: Tele Agents" provides the product class for the TeleAgent channel from a supply context. After an offer has been configured for a channel type, a channel must be registered for a customer source. By doing this, an agent ("Marjorie"), is registered to sell the customer source profile. The agent gives her preferred lifestyle of Mirror customer. The form for this notation may be "MirrorCustomers | TeleAgents. Marjorie" . From a supply context, the Notation may be "TeleAgents. Marjorie: MirrorCustomers" , which provides the agent name for the channel member to the Mirror customer base. On the other hand, from the demand context, "MirrorCustomers: TeleAgents. Marjorie", provides the handling and communication preference regarding the Mirror customer base. A channel must be registered for an offer category indicating that Marjorie subscribes to sell mortgage offers. Agent Marjorie may provide information such as her skill level and her product preferences. Accordingly, the Notation may be "TeleAgents. Marjorie | Mortgage Offers" with a demand context of "MortgageOffers: TeleAgents. Marjorie", which provides the product preferences for the TeleAgent for the mortgage category. From the supply context,

"TeleAgents. Marjorie: MortgageOffers" provides the skill attributes offered by the Agent to the Mortgage category.

Next, a contact may be initiated when a customer, Angie, phones an agent ("TeleAgent") after seeing a Mirror promotion. It will be understood and appreciated that contact may be made in a variety of other ways, such as in person, over the Internet, by e-mail or the like. Angie's lifestyle indicators may also indicate that she has a particular preferred Agent if she has used the service before. This action is captured in the Notation "TeleAgents | MirrorCustomers.Angie" or, from the supply context, "TeleAgents: MirrorCustomers. Angie", which provides lifestyle indicators of the customer. From a demand context, "Tele Agents: Mirror Customers. Angie" provides the Agent preferences for the customer. When contact is actually established, Angie's lifestyle and Agent preference are used in conjunction with Agent Marjorie 's name and preferred lifestyle characteristics to match the participants. In other words, "MirrorCustomers.Angie I TeleAgents. Marjorie". In the active context, "MirrorCustomers.Angie:: TeleAgents. Marjorie" is constructed from

"MirrorCustomers. Angie. TeleAgents" and "MirrorCustomer: TeleAgents. Marjorie" . Similarly, the active context "TeleAgents. Marjorie: : MirrorCustomers. Angie" is constructed from "TeleAgents: MirrorCustomers. Angie" and "Tele Agents: Mirror Customers. Angie". The requirements functions of the active contexts are used to facilitate the match, while the probability functions are used to identify an agent as the best agent for the customer.

Once contact with an agent has been established, the customer requests an offer category. In the present example, customer Angie confirms interest in a mortgage product. She provides her requirements such as loan amount and term. She also supplies employment and financial information for qualification purposes. Such a relationship can be expressed as "MirrorCustomers.Angie | MortgageOffers" . In the demand context, the customer's requirements for a mortgage product are captured by "MortgageOffers: MirrorCustomers. Angie" and the qualifications of the customer for products in the mortgage category are captured by the supply context notation "MirrorCustomers. Angie:MortgageOffers".

At this point, a compatible customer, offer, and channel have been identified by comparison of information contained in templates relating to the corresponding requirements of the other portions of the transaction. Referring now to Fig. 10, the status of the agreed transaction is depicted graphically. More particularly, customer 24, offer 48 and channel 68 have each "matched" the needs and requirements of the other so that the prerequisites for a transaction involving each of the three is possible.

In terms of the Notation, the relationship between the customer 24 (Angie) and the offer 48 (Abbey Mortgage Offer) is illustrated by interaction dynamic 1020. Interaction dynamic 1020 is a simple graphical representation of the notation "MortgageOffers. Abbey | MirrorCustomers.Angie" . The respective active contexts of the notation corresponding to interaction dynamic 1020 are contained in context description 1025.

Similarly, the interrelation between the Abbey Mortgage offer 48 and the Channel 68 (TeleAgent Marjorie) is depicted graphically by interaction dynamic 1060. The notation corresponding to interaction dynamic 1060 is "MortgageOffers. Abbey | Tele Agents. Marjorie" . The respective active contexts corresponding to the notation are depicted in context description 1065.

Finally, the interaction between Channel 68, (TeleAgent Marjorie) and customer 24 (Mirror Customer Angie) is depicted graphically by interaction dynamic 1040. The notation corresponding to interaction dynamic 1040 is " MirrorCustomers . Angie | TeleAgents . Marjorie " . This Notation yields active contexts contained in context description 1045.

The active contexts indicated in context descriptions 1025, 1065 and 1045 are important and useful in the implementation of the present invention. By implementing these contexts, degrees of suitability and compatibility between potential parties to a transaction can be fully evaluated. For example, with regard to context description 1025 detailing interrelations between customer 24 and offer 48, the active contexts filter the inventory the customer requires and is qualified to be sold while the probability functions prioritize the inventory that is most likely to result in a transaction. Similarly, regarding context description 1065 detailing the interaction between the offer 48 and channel 68, the requirements functions of the relevant contexts filter the inventory the agent is qualified to sell while the probability functions prioritize the inventory the agent is most effective at selling. With regard to the filtering and prioritization functions indicated by the above referenced contexts, these functions are accomplished in a well known manner according to pre-established filter and prioritization criteria, which criteria can be established on a case-by-case or platform-by-platform basis.

From the previously described functionality of the Platform 10 and the novel implementation of the Notation in the present invention, a unique method and system for facilitating transactions is apparent. More succinctly, business conducted on the Platform 10 by offerors and others desiring to sell products or services construct offers by populating offer member objects with templates corresponding to the particulars of the offer and the requirements of the offerer for suitable complimentary parties to the transaction. Customers seeking to obtain products or services construct customer member objects comprising information relating to themselves as well as their desires and limitations regarding a particular product of products. Information relating to channels through which transactions may be accomplished also populate the Platform 10. Channel member objects are constructed of information relating to the particular channel, its benefits, costs and limitations. Once the tertiary market space is populated with member objects from each of the offer, customer and channel transaction components, a Notation is constructed and submitted to the Platform 10. An evaluation as to whether a transaction according to terms referenced by the Notation can be accomplished is performed. If agreement can be reached between one or more sets of member objects from each of the offer, customer and channel transactional components residing on the Platform 10, the agreeing member objects may then be prioritized according to additional preferences indicated by the parties corresponding to the particular member objects. Prioritization allows a particular person or entity corresponding to a particular member object to individually evaluate compatible members of other component objects, all of which agree with the entities' predetermined criteria which populate the entities' respective member objects. The entity is then free to choose transactional partners from among a pool of presumably acceptable candidates.

Importantly, the present invention facilitates instant, remote multiplexing of interactions between parties on terms predefined by the parties. More specifically, a customer corresponding to a customer member object may use a particular channel (such as the TeleAgent channel) to submit simultaneous requests for respective transactional partners relating to distinct and diverse products or services. For example, a customer may use a favorite TeleAgent to submit Notations relating to the possible purchase of automobiles, insurance and plumbing services. In each case, the exchange of information between potential parties to a transaction may be monitored in "real time" throughout the course of the exchange.

The benefits of such an arrangement are numerous. In theory, one TeleAgent (also referred to as a "call center operator") could act as an "agent" for every offer from every content provider on the platform 10. This is a substantial benefit to the content providers because they are not required to maintain their own call centers or TeleAgents. Additionally, content providers do not need to rely on their own advertising for two reasons. First, platform-based advertising will attract to the Platform 10 consumers who need a variety of different products by implementation of "generic" advertising. In this context, the term "generic" means advertising that is not dedicated to a single product or class of products. Even if a customer was "lured" to the Platform 10 because of interest in one product, interest in a second product may surface as a result of interaction with the customer's TeleAgent. Secondly, because transactions on the Platform 10 can be monitored at every step from start to finish, content providers may be charged for a portion of the advertising cost based only on the number of transactions completed or handed off as a result of referrals from the particular advertising source, thereby resulting in advertising costs which are proportional to the benefit of the particular advertising piece. In other words, if sales of a particular product allowed for 3 % of the total sales attributable to a single advertising piece, the seller of the 3 % of goods is charged only 3 % of the cost of the advertising piece. In a preferred embodiment of the present invention, the "real time" exchange of information between potential participants to a transaction on the Platform 10 is monitored by a the system. Typically, the system allows access to statistics and records relating to transactions which are failed, completed and in process. These statistics and records are updated in real time. By providing this information to interested parties, propensities of individuals, groups of individuals, offers, offerors, channels and the like can be assessed both statistically and hypothetically and feedback provided to interested parties so that the profitability of their respective business practices can be increased. Particularly, the system may monitor items such as volumes, distributions, yields and conversions/outcomes in order to provide more effective e-traffic management, risk capping, enhanced channel utilization, flexible underwriting margins and exchange fees to provide increased profitability.

For instance, such an increase in profitability due to better informed channel utilization could be realized, for example, when the system discovers that only 3 percent of callers from California meet the requirements for handoff with a particular product offered by a particular content provider, as opposed to 32 percent of callers from other states. To improve efficiency, the system may be configured to "cut off channels from California for reasons including unacceptable risk factors or tolerances in the transaction, thereby limiting access to the content provider's products by consumers from California. An example of the format and content of information that may be available via the system's reporting capability is shown at Fig. 11. Fig. 11 is a screen shot of a yield screen 1100 in which columns 1120, 1125, 1130, 1135, 1140 and 1145 correspond to percentage participation in various stages of the transaction, as well as certain fixed information regarding each transaction in a particular class of transactions. Rows 1160, 1165, 1170 and 1175 are rows corresponding to particular products that are offers for sale via the Platform 10. In legend field 1110, it can be seen that the statistics contained on the yield screen 1100 have been statistically summarized on a "per one thousand calls" basis. Also indicated in legend field 1110 is the fact that 90% of requests received from perspective customers corresponded to products existing in inventory within the Platform 10.

Subscription column 1120 indicates what percentage of callers inquired about a particular class of products. It can be seen that, for instance, 30% of individuals who sought to conduct a transaction on the Platform 10 inquired as to the availability of mortgage products, while 22% of the callers inquired about each of the building insurance, contents insurance, and personal loans products. Referring back to callers who were interested in mortgage products, particularly the information in row 1160, demand screen column 1125 indicates that, for the 30% of callers interested in mortgage insurance, 67% of the available products met the consumer's requirements. Similarly, supply screen column 1130 indicates that of the 67% of mortgage offers meeting consumers requirements, 90% of the consumers inquiring as to those products met the offers requirements. Settlement ratio, column 1135, indicates the percentage of calls in which both the consumer's requirements and the offeror 's requirements were met, 48% resulted in an offer being proposed and a "handoff being proposed and accepted.

Revenue may be generated in a variety of ways in the implementation of the present invention. In a preferred embodiment, categories of products contain a negotiated conversion price. A conversion price is simply an amount of money that a party (most frequently the content provider) is willing to pay for delivery of a customer who meets the content provider's criteria. In conversion price column 1140, the negotiated conversion price for mortgage products is £150. Establishment of a conversion price column readily yields information concerning conversion rate in column 1145, as well as settlement yield and gross settlement amounts.

The ability of the method of the present invention to multiplex offers and channels is readily apparent in Fig. 11. Notably, requests per call field 1180 indicates that, for each call made by a consumer, 1.5 requests for products or services were made. A result of this type is expected when a wide array of products and services are offered through a single contact point (the agent). This arrangement represents a significant advancement in the efficiency of channel marketing and, from the perspective of the consumer, offers a significance advance in the ease of identifying and obtaining products and services. Finally, total field 1185 indicates a total number of calls during a given period as well as totals in other financially related categories.

Yet another aspect of the present invention which may be implemented by a context manager to assist content providers in improving profitability is depicted in Fig. 12. Fig. 12 illustrates an exemplary presentation of information which may be gleaned from transactions occurring on the Platform 10. Specifically, Fig. 12 depicts an example of the ability of the present invention to continuously monitor transactions occurring on the platform 10 and provide the information to a content provider for both analysis and action. In particular, the content provider breakdowns 1200 address breakdowns of category performance for two different companies, "Company A", "Company B" and Companies A and B together. As earlier described, the present invention allows monitoring of commercial transactions at each stage of the transaction. Breakdown graph 1220 illustrates a response to a context provider's request for a cumulative summary of a breakdown of category performance for the two companies who are selling the same product on the Platform 10. Also contained in breakdown graph 1220 is a demand graphic 1222 indicating the number of consumers who posed initial interest in products offered by Company A and

Company B. Supply graphic 1224 indicates the number of individuals who met the requirements of Company A and Company B from among the number of consumers who are initially interested in the products. Offer Proposed graphic 1226 indicates the number of consumers to whom an offer for sale was actually made, while Hand- Off Proposed graphic 1228 indicates the number of recipients of offer proposals who actually proposed a hand-off. Finally, Hand-Off graphic 1230 indicates the number of "deals" that were closed for both Company A and Company B via the platform 10. This unique accumulation and presentation of information can be manipulated so as to be particularly beneficial to content providers. For instance, in breakdown graphs 1240 and 1260, a direct comparison between Company A and Company B can be accomplished. In accordance with the present invention, this comparative information could be provided to Company A and Company B for use in comparing the commercial viability of their products, as opposed to those of their competition. Optimally, this information could be obtained for a wide variety of competitive entities seeking to sell similar products via the Platform 10. Additionally, it can be foreseen that this information may be provided to companies under varying degrees of anonymity.

The present invention also enables further evaluation of information between content providers. For instance, still referring to Fig. 12, should Company B desire to identify shortcomings in its particular products as compared to those of Company A, the context provider could provide Company B with information relative to the specific supply criteria or offer proposal thresholds employed by Company A. Company B could then identify differences between products offered by Company A and Company B and would then have an opportunity to adjust the particulars of its offers to be more competitive. Yet another example of the improved method of doing business which can be realized pursuant to implementation of the present invention is illustrated in Figs. 13a and 13b. Figs. 13a and 13b are breakdown graphs 1310, 1320, 1330, 1340 and 1350. The context manager, when implementing the functionality of the present invention hereinbefore described may access, inspect and make advantageous business recommendations to content providers based on information such as that which is contained in the breakdown graphs of Figs. 13a and 13b. Specifically referring to breakdown graphs 1310, information is displayed such as Company B offer proposals 1312, Company A offer proposals 1314 and combined Company A and Company B offer proposals 1316. Referring to breakdown graph 1320, the Company A and Company B offer proposals 1316 of breakdown graph 1310 is further evaluated. In this further evaluation, it can be seen the distribution of hand-offs between Company B, Company A and those hand-offs which were rejected. As can be seen in breakdown graphs 1330, 1340 and 1350, there are multiple ways that information can be accessed, evaluated and displayed in order to effect the functionality of the present invention. It should be understood and appreciated that the forms of display illustrated both in Fig. 12 and Figs. 13a and 13b are exemplary in nature and not intended to be limiting in any way.

Alternative embodiments will become apparent to those skilled in the art to which the present invention pertains without departing from its spirit and scope. Accordingly, the scope of the present invention is determined by the appended claims and is supported by the foregoing description.

Claims

CLAIMSI claim:

1. A computer-based platform for enabling transactions, the platform comprising:

(a) a plurality of component objects, each component object corresponding to a component of a transaction, the component of the transaction being from the group of components including customers, offers and channels;

(b) each component object of the plurality of component objects comprising at least one related member object;

(c) each member object populated with member information from categories comprising: member profile, member products, member services, member details, member preferences, member needs, member capabilities; and

(d) an interrelator for interrelating a plurality of member objects based on corresponding member information between the respective member objects in accordance with an articulated Notation, the articulated Notation providing interrelational criteria.

2. The computer-based platform of claim 1, wherein the member information is collected on a template.

3. The computer-based platform of claim 2, wherein the template supports simultaneous storage, calculation and interrelation of information between member objects based on both active and passive information.

4. A method for facilitating, processing and settling a transaction, the method comprising the steps of: (a) introducing a plurality of potential components of the transaction to a platform, each potential component of the transaction corresponding to a corresponding desire of a corresponding potential party to the transaction;

(b) identifying potentially compatible components of the transaction from among the plurality of potential components of the transaction;

(c) evaluating a propensity of each of the potentially compatible components of the transaction;

(d) discriminating the potentially compatible components of the transaction into categories comprising undesirable components and compatible components of the transaction;

(e) presenting a compatible component of the transaction to an opposing corresponding party to the transaction; and

(f) executing the transaction between agreeable opposing corresponding parties to the transaction corresponding to compatible components of the transaction.

5. The method of claim 4, wherein the step of discriminating is based on the propensity of the potential compatible components of the transaction, the propensity being evaluated within a context.

6. A method for modeling a transaction comprising the steps of:

(a) constructing a notation for a potential transaction, the notation including correspondences to a plurality of component objects of the transaction selected from a group of component objects of the transaction including offer objects, customer objects and channel objects; and (b) interrelating the plurality of objects within the Notation with at least one operator, the operator having predetermined interrelational characteristics.

7. The method of claim 6, wherein the objects contain non-linear components.

8. The method of claim 6, wherein the predetermined interrelational characteristics are active.

9. The method of claim 6, wherein the predetermined interrelational characteristics are passive.

10. The method of claim 6, wherein the Notation is software-neutral.

11. A method for using a modeled transaction to facilitate a transaction comprising the steps of:

(a) modeling a transaction by creating a Notation for the transaction, the Notation including first correspondences to a first plurality of objects selected from a group of objects including offer objects, customer objects and channel objects;

(b) interrelating the first plurality of objects within the notation with at least one operator, the operator having predetermined interrelational characteristics;

(c) comparing the notation to a second plurality of objects from the group of objects to identify a second correspondence to a second object from the second plurality of objects; and

(d) in the event of the second correspondence, reporting the second correspondence to a plurality of parties associated with the second object of the second correspondence.

12. A method for optimizing electronic transactions, comprising the steps of:

(a) providing an instant and remote multiplexed exchange of information between a plurality of parties on terms predefined by the parties;

(b) monitoring the exchange of information between the plurality of parties in real-time throughout the course of the exchange of information to create monitored information;

(c) using the monitored information to establish for each party a propensity of the party, the propensity comprising weighted variables;

(d) facilitating quantitative, statistical and hypothetical assessment of the propensity of the party; and

(e) determining a future course of commercial conduct for each party based on the quantitative, statistical and hypothetical assessment of the propensity of the party.

13. The method of Claim 12, wherein the step of providing an instant and remote multiplexed exchange of information between a plurality of parties further includes the step of consolidating the exchange of information between the plurality of parties into a single channel.

14. The method of Claim 12, wherein the step of using the monitored information to establish for each party a propensity of the party further comprises the step of evaluating factors including weighted variables, transactional history, tendencies, preferences, habits and error margins to determine a desirability of a particular potential transaction.

15. The method of Claim 12, wherein the step of implementing a future course of commercial conduct further comprises the steps of: (a) relaying the desirability of a particular transaction to a plurality of potential parties to the particular transaction;

(b) allowing the potential parties to the particular transaction to manage the particular transaction based on the desirability of the particular transaction.

16. The method of Claim 14, comprising the further step of maintaining the monitored information in a database.