WO2001016826A1 - Electronic commerce communication systems with multiple user-define marketplaces, controlled pricing, and automated purchasing capabilities - Google Patents
Electronic commerce communication systems with multiple user-define marketplaces, controlled pricing, and automated purchasing capabilities Download PDFInfo
- Publication number
- WO2001016826A1 WO2001016826A1 PCT/US2000/018943 US0018943W WO0116826A1 WO 2001016826 A1 WO2001016826 A1 WO 2001016826A1 US 0018943 W US0018943 W US 0018943W WO 0116826 A1 WO0116826 A1 WO 0116826A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- marketplace
- information
- supplier
- buyer
- suppliers
- Prior art date
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
Definitions
- the present invention relates to systems and methods for broadcasting a message to a plurality of receivers and for tracking the responses to the broadcast message.
- the present invention relates to systems and methods that can be used to create private electronic commerce groups called marketplaces and offer membership to these marketplaces to selected buyers and suppliers from a larger public group of general subscribers comprising a plurality of buyers and a plurality of suppliers. More specifically, suppliers and buyers are selectively presented membership to marketplaces created on demand by a marketplace owner or trading partner, thereby providing the suppliers and buyers with an outlet for efficient commercial interaction in furtherance of completing a purchase transaction.
- the supplier when a supplier is asked to submit a bid, the supplier must assemble the appropriate information and submit it to a potential purchaser. If the supplier submits bids to many different purchasers, the supplier must maintain records that identify which bids were submitted to which purchasers and track key dates such as the date that a bid must be submitted, the date that a purchaser will make a purchasing decision or award a contract, and so forth.
- the bid process requires that certain dates be tracked and deadlines identified.
- Present E-mail systems do not allow for the tracking of deadlines.
- an E-mail messages arrives at a particular location, a user is free to read or ignore the message as they wish.
- the only mechanism that exists for identifying desired reply dates is to include such information into the text or body of the E-mail message. It would be desirable to have a system that could remind people of approaching deadlines so that they would not be forgotten.
- a buyer seeking to purchase an item from a supplier electronically may have several concerns with the proximity of the buyer's business to the supplier's business, particularly in regards to service contract items that might require local support. Buyers are also concerned about the quality of goods that are being sold across the electronic community. Traditionally, a buyer is able to inspect the goods prior to making a purchase and most traditional electronic commerce methods, or those methods in place today, do not allow the buyer to inspect the goods. Finally, the price that is often offered across the internet is higher that a buyer might be able to obtain with direct contact to the supplier.
- a system does not presently exist that facilitates all aspects of the procurement process by supporting efficient information exchange between suppliers and buyers.
- systems do not exist that allow a buyer to transmit information to a plurality of suppliers and collect and manage responses from suppliers so that the information contained therein can be analyzed and compared.
- systems do not exist that allow tracking of critical dates and deadlines and that facilitate reminding individuals of key dates and deadlines.
- systems do not exist that allow market participants to selectively create submarketplaces of approved buyers and suppliers to reduce costs and ensure quantity and quality levels for products being purchased.
- systems do not exist that take advantage of available compression and encryption protocols without limiting the outstanding contact and connection opportunities created by the internet.
- the foregoing problems in the prior state of the art have been successfully overcome by the present invention, which is directed to a system and method for coordinating purchasing communications and tracking responses.
- the system and method of the present invention is fully scalable in that the system and method can be adapted to accommodate an unlimited number of suppliers and buyers in the electronic community.
- the invention allows exchange of information between buyers and suppliers not only during the bidding process but prior to the bidding process as well.
- the exchange of preliminary information allows buyers and suppliers to selectively create specific private submarketplaces from the unlimited number of suppliers and buyers in the electronic community.
- a marketplace administrator can create a virtual marketplace by inviting specific buyers and suppliers from the general electronic community to join the proposed submarketplace.
- the advantage of such a system is that multiple, smaller groups or submarketplaces may be created by individual entities within the electronic community. These submarketplaces are often referred to as electronic marketplaces or virtual marketplaces.
- the focus of each submarketplace is to promote commerce between members.
- the community owner or marketplace administrator controls the transactional fees and controls the membership within the community.
- a chamber of commerce may invite its members and selected suppliers and buyers who have ties to the community to participate in the chamber of commerce's electronic marketplace. Participating in the electronic marketplace provides members of the chamber of commerce with an efficient way to support each other through electronic purchasing, as buyers and suppliers.
- Membership in the electronic marketplace does not exclude individuals from also participating in the larger electronic commerce groups for items that are not available or are not offered at a reasonable price by suppliers within the electronic marketplace created by the chamber of commerce. Under these circumstances, a submarketplace allows suppliers to offer better prices to the selected buyers than they might offer to the general public and provides buyers with filtered information pertinate to their desired purchasing transactions and provides buyers with filtered information relative to their purchasing activities.
- the system and method of the present invention utilize a service provider that maintains a central database of information about various buyers, suppliers, products, and services.
- the information about each potential marketplace participant is stored in a data object that is electronically updated by the marketplace participant, the marketplace administrator, or the service provider. All data objects may be grouped by classifications and/or products or product lines.
- a marketplace participant accepts membership into the new marketplace, portions of the information contained in the participant's data object are attached to the marketplace object.
- Buyers or suppliers may extract information from the marketplace object in order to identify goods or services that are available or desired in the marketplace. Thus, buyers may retrieve information about suppliers and products or services offered for sale.
- Suppliers may retrieve information about buyers in order to target advertising or other information relating to critical accounts.
- Such information may also allow suppliers to tailor their goods or services in order to better suit the needs of particular purchasers.
- Marketplace administrators may retrieve information about suppliers and buyers to create other private virtual marketplaces that center to the specific needs of the suppliers and buyers. Under these circumstances suppliers may be willing to offer better prices and more flexible terms to the selected buyers. At the same time, the buyers in the virtual marketplace may agree to longer or larger purchase contracts with the supplier. Often the parameters of the electronic marketplace created by the marketplace administrator will offer additional quality control to both the supplier and the buyer.
- Other purchasing functions offered by the present invention outside of the bidding and request for bids include single stop purchase orders, electronic shopping carts, and proxy marketplace catalogs where multiple suppliers can coordinate with multiple buyers through a single electromc proxy.
- pro-consumer groups certify a group of suppliers as approved to provide services to their buyers. The buyers look to the pro-consumer group as a source for choosing quality suppliers.
- the pro-consumer group could create a marketplace with various product categories containing all of the approved suppliers and all of the buyer members of the group. Thereby creating a multiple supplier to multiple buyer marketplace to facilitate purchasing transactions. Suppliers in this marketplace could be removed if they lose their certification or the marketplace administrator could limit the number of products offered by the supplier to those products meeting the pro-consumer group's quality standards.
- Prior art programs do not allow for the creation of dynamic commerce environments where marketplaces can be created on demand by members who are subscribers to the larger group or by an outside regulating entity.
- the present invention allows all of the subscribers to utilize the present invention to create opportunities for commerce between the participating buyers and suppliers.
- One embodiment of the present invention uses a combination of database and Internet technologies to provide effective sourcing, bidding, purchasing, and messaging between buyers and suppliers. By installing a software component directly onto the user's machine, one embodiment of the present invention is able to implement a data pipe solution using common Active
- ADO Data Object
- the component is a purchasing program using ODBC compliant databases and internet communication technologies to increase the data transfer rates between various users within the system.
- the present invention can export bid information between suppliers, buyers, and other systems using standard internet data files, ASCII, EDI,
- ODBC ODBC
- a component object model allows participants access to data through standard Microsoft® programming interfaces, meaning that marketplace participants can send files using any format or file type that the participant desires, although the use of standard file types or typical internet protocols such as .xls, .doc, .bmp, .gif, .jpg, or .htm, is preferred. Many of these file types include some form of compression which can significantly reduce the number of bytes needed to transfer between parties participating within the marketplace. Encryption can then be conducted on the compressed files adding additional security to the data transmissions.
- An example of the typical encryption standard used in the present invention is 128 bit using SSL certificates from VeriSign, Inc., however, it is clear that enhanced or relaxed encryption standards could be applied to the present invention without affecting the objects and advantages over similarly protected procurement systems.
- the present invention supports a bidding process that may be summarized as follows.
- a vendor enters information into the database in order to allow potential buyers to identify the various products or services offered by the vendor.
- the vendor can submit company profiles which describe the company.
- the vendor may also submit information on products or product lines offered for sale.
- the company and product lines may be grouped into various classifications in order to help purchasers locate suppliers of a particular type or class of goods or services.
- the vendors may submit this information to the database through electronic means, such as the internet, or through paper of fax if the vendor has no electronic link to the service provider.
- Buyers may also submit similar types of information to allow suppliers to identify information about particular buyers and about the goods or services that are needed or required by a particular buyer.
- the submitted information may be updated as often as a buyer or supplier wish in order to maintain currency.
- the service provider collects submitted information and stores it into a database organized to allow rapid access to desired information.
- a database may be stored in a single central location where vendors and buyers may dial in and access the database, or copies of portions of the database may be distributed to marketplaces, buyers, and suppliers as desired.
- Such a distributed database method may be preferred in order to allow rapid access to information by a buyer or supplier without the need to contact a centralized database location. If such a distributed database is used, mechanisms can be put in place in order to update the local databases stored by the suppliers or buyers.
- An essential aspect of the marketplace configuration is the ability of participating suppliers or buyers to modify information from the database for exclusive display within the marketplace, for example, adjusting the normal product list and discounts offered. This allows the marketplace object containing product pricing information to vary from the information held in a central or regional database.
- the buyer can browse the marketplace object using various criteria. For example, the buyer may select suppliers by company name, by key words, by classifications, or any other manner that allows rapid access to desired information. As the buyer browses the marketplace object, the buyer can assemble a list of suppliers that will receive a request for a bid within the marketplace. If the buyer has not previously joined a marketplace containing the relevant suppliers, the buyer may initiate a search of the database to assemble a list of suppliers. Once this selection is made the buyer can either send a request for bid to the suppliers or create a new marketplace including the suppliers and make the request within the marketplace.
- the buyer may decide that the transaction is merely a one time purchase, calling for a direct request for bid sent to the supplier. Alternatively, the buyer may decide that the proposed purchasing transaction would be better received by a new marketplace.
- the buyer creates the marketplace and invites the list of suppliers to join the marketplace.
- One advantage of this configuration is that the buyer may have similar periodic purchasing transactions and the marketplace would already be created for the next transaction.
- a data cast message is a message that will be broadcast to the selected suppliers requesting a bid on desired goods or services.
- a data cast message may contain such information as a text message, dates of importance including the date that the data cast message was sent, the date that a response is due, and the date that one or more reminders will be sent.
- the data cast message may also contain attached documents such as specifications, scanned pictures, or any other type of electronic or scanned document.
- the data cast message may also contain a series of prompts entered by the buyer. These prompts are used to prompt a supplier for information that should be returned with the bid. For example, prompts can include such information as the total parts cost, the total labor cost, miscellaneous charges, amount of goods supplied, total bid cost, or any other type of information desired by a buyer. These prompts are text strings and there is no limit on the text of prompt. Thus, a buyer is free to request information in categories that he or she desires to compare from various suppliers.
- the buyer In addition to the data cast message, the buyer also creates a data cast object.
- the data cast object serves as a central unit of information that contains not only the data cast message, but also responses received from various suppliers. Thus, when the data cast object is created, the data cast object has locations set aside to store information from the responses that will be received from the various suppliers.
- responses As responses are received from various suppliers, they can be stored in the data cast object.
- the data cast object thus can be passed from one individual or organization to another and will contain all information relating to a particular bid.
- the present invention allows not only broadcast of information but also tracking and storage of responses in a manner that minimizes the likelihood of lost information.
- the buyer After the buyer creates the data cast message and data cas ⁇ object, the buyer sends the data cast message to the suppliers previously identified by browsing the database.
- all communication between a buyer and the suppliers is performed electromcally.
- Such electronic communication allows automation of responses and automatic storage of responses into the data cast object as explained.
- the data cast message can be sent via facsimile or printed and mailed in an envelope. It should be noted that a buyer is free to update a data cast at anytime. Such an update will necessarily generate an updated data cast message.
- the updated data cast message can be sent to suppliers as previously described. Such an updated data cast message supersedes and replaces any previous messages.
- vendors When vendors receive a data cast message from a buyer, the vendors may store the data cast message in a response database. This allows vendors to track important information and dates received from a plurality of buyers. If a vendor receives a data cast message via E-mail or other electronic communication, when the vendor opens the document, the information contained in the data cast message is displayed to the supplier. The displayed information includes the sequence of prompts previously described. This allows a vendor to submit information desired by a particular supplier. The vendor may also include additional information such as text and/or scanned or electronic documents. After the vendor has assembled his or her bid, the vendor can respond using E-mail. If a vendor does not have access to electronic communications, then fax, printed letters or telephone calls may be substituted. However, such methods are not preferred since it does not allow automated storing of responses.
- the buyer gathers the responses and stores information from the responses into the data cast object previously created.
- information from the responses into the data cast object previously created.
- An analogy to the data cast object may be a folder or file where all information received regarding a particular bid can be placed The file can then be carried from one individual or location to another and will contain all information necessary to process and analyze the various responses received.
- Using a data cast object also opens up a wide variety of options. For example, the buyer may choose to collect information and store it into the data cast object.
- the buyer may choose to pass the data cast object to the service provider and allow the service provider to collect responses from the suppliers and store them into the data cast object.
- the service provider can then be responsible for other tasks such as sending out reminders, following up on suppliers that have not responded, and so forth. Once all information has been collected into the data cast object, the service provider can pass the data cast object to the buyer for analysis.
- the original data cast message created by a buyer may contain dates for one or more reminders to be sent to the suppliers. As these dates approach, the system can automatically send a reminder to those suppliers that have not yet responded to the bid request. As previously described, such reminders may be sent by anyone who has the data cast object.
- the buyer can then analyze the information received. For example, information stored in the data cast object may be extracted and sent to an analysis module for comparison. Since a data cast message contains a series of prompts used by suppliers when responding, the information or responses to the series of prompts may be extracted and placed into a spreadsheet program. The various bids may then be compared and analyzed using the spreadsheet program. Other types of analysis modules may also be used or developed in order to analyze the responses received from the various suppliers.
- An alternative embodiment allows a trading partner or administrator to create a submarketplace with controlled pricing capabilities including at least one buyer and at least one supplier selected by the trading partner from a database of general subscribers to the larger electronic commerce communication system.
- the pricing capabilities controlled by the trading partner include establishing association costs and individual transaction fees within said submarketplace.
- the trading partner may also require a flat fee, a graduated fee, or a transactional fee from the supplier or the buyer for any successfully completed purchasing transaction. Selection of the suppliers may be made by the trading partner according to product pricing, quantity and quality information or geographical information extracted from a supplier data cast database.
- Buyers may be selected by the trading partner based on purchasing information extracted from a similar buyer data cast database of general subscribers to said electronic commerce communication system.
- the submarketplace utilizes the data cast object to exchange product and pricing information between buyers and suppliers within the submarketplace.
- the trading partner may also choose to pass the data cast object to the submarketplace and allow the submarketplace to collect responses from the suppliers and store them into the data cast object.
- the submarketplace can also be responsible for other tasks such as sending out reminders, following up on suppliers that have not responded, and so forth. Once all information has been collected into the data cast object, the submarketplace can pass the data cast object to the buyer for analysis. Once the parties have reached an agreement, the submarketplace permits the exchange of purchasing information between the buyer and the supplier.
- the purchasing information exchanged between the buyer and the supplier may include at least one electronic purchase order form. Multiple electronic purchase order forms may be generated from a single marketplace purchase order form. The multiple purchase order forms are then distributed to selected suppliers as dictated by the original buyer's purchase selections, each electronic purchase order form indicating only the information corresponding to the purchase transaction between the buyer and the specific supplier. The submarketplace continues to track the progress of the purchasing transaction through the data cast object until receiving verification that desired product is received by the buyer from the supplier. Accordingly, it is a primary object of this invention to provide a system and method for communication coordination and response tracking that facilitates all aspects of the bid process from initial selection of products or suppliers through analysis of responses.
- Other objects of the present invention include: providing a system and method for communication coordination and response tracking that uses a centralized repository of information to collect responses received; providing a system and method for communication coordination and response tracking that allows a buyer to customize the information requested by entering a sequence of prompts; providing a system and method for coordinated communication and response tracking that allows information received in responses to be placed into an analysis module in order to analyze and compare responses; providing a system and method for coordinating commumcation and response tracking that facilitates exchange of information between a plurality of buyers and a plurality of suppliers; providing a system and method for communication coordination and response tracking that allows market participants to selectively create marketplaces of approved buyers and suppliers from a larger plurality of buyers and a larger plurality of suppliers to reduce costs, increase efficiency of marketing efforts, and ensure availability of desired quantity and quality levels for products being purchased; providing a system and method for coordinating communication and response tracking that use available compression and encryption protocols while maintaining internet compatibility; and providing a system and method for coordinating communication and response tracking that promotes the creation and administration of submarket
- Figure 1 is a top level diagram of one embodiment of the present invention
- Figure 2 is a diagram illustrating a distributed database accessed by buyers and suppliers of the present invention
- Figure 3 A and 3 B are a top level flow diagrams of one embodiment of the present invention.
- Figure 4 is a flow diagram illustrating the details of one implementation of the local database maintenance processing block of Figure 3 A;
- Figure 5 is a flow diagram of one implementation of the data cast creation processing block of Figure 3 A;
- Figure 6 is a flow diagram illustrating one implementation of the supplier communication processing block of Figure 3 A; and Figure 7 is a flow diagram illustrating one implementation of the data cast analysis block of Figure 3 A;
- Figure 8 is a flow diagram illustrating the details of new member creation, new marketplace creation, and general electronic community solicitation of one implementation of the present invention
- Figure 9 is a top level diagram of one electronic marketplace embodiment of the present invention. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
- Embodiments of systems of the present invention may comprise a general purpose computer.
- a general purpose computer may have any number of basic configurations.
- a general purpose computer may comprise any or all of a central processing unit (CPU), one or more specialized processors, system memory, mass storage such as a magnetic disk, an optical disk, or other storage device, an input means such as a keyboard and/or mouse, a display device, and a printer or other output device.
- a system implementing the present invention can also comprise a special purpose computer or other hardware system and all should be included within its scope.
- Embodiments within the scope of the present invention also include computer readable media having executable instructions.
- Such computer readable media can be any available media which can be accessed by a general purpose or special purpose computer.
- Such computer readable media can comprise RAM, ROM, EEPROM, CD ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired executable instructions and which can be accessed by a general purpose or special purpose computer. Combinations of the above should also be included within the scope of computer readable media.
- Executable instructions comprises instructions and data which cause a general purpose computer or special purpose computer to perform a certain function or a group of functions.
- the present invention is designed to facilitate communication between a plurality of buyers 10 and a plurality of suppliers 12.
- the invention supports a bidding process all the way from the initial selection of suppliers to the broadcasting of a request for bid, collection of responses from selected suppliers, and analysis and comparison of the responses received from the suppliers.
- Initial information about buyers 10 and suppliers 12 is exchanged via service provider 14.
- Service provider 14 collects information submitted by buyers 10 and suppliers 12 and stores the collected information into central database 16.
- central database 16 may contain information regarding a particular buyer or supplier as well as information regarding products or services needed by a particular buyer or offered by a particular supplier.
- Information stored in central database 16 may preferably be accessed via key word, classifications, or any other manner that allows easy access by a buyer or supplier to the information stored in central database 16.
- the information stored in central database 16 may be accessed through service provider 14 or, alternatively, a portion of the information in central database 16 may be copied by a buyer 10 or supplier 12 into a local database such as local database 18 or local database 20.
- central database 16 it may be preferable to distribute portions of central database 16 to various local databases, such as local database 18 or local database 20. This will allow a buyer or supplier to access desired information locally rather than establishing contact with service provider 14 in order to access central database 16.
- Such a distributed database model often gives faster access to desired information, but introduces the additional complexity of maintaining current copies of local databases in a variety of locations. However, particular buyers or suppliers may wish to assume a larger share of the maintenance responsibilities for faster access to desired information.
- the present invention facilitates communication between buyers 10 and one or more suppliers 12. Such communication may be achieved through service provider 14 as indicated in Figure 1, or may be direct from a buyer to one or more suppliers as indicated by arrow 22.
- Supplier 12 submits information to service provider 14 to be included in central database 16. Such information may include, for example, company profile information describing the company. Classification information may also be submitted illustrating the types or classes of services or goods provided by a particular company. Additionally, supplier 12 may also submit information regarding the products, product lines, services, and the like offered by the supplier. Classification information for the products and/or services offered by a particular supplier may also be submitted. In short, supplier 12 may submit any information into central database 16 that would be helpful for a buyer in locating and selecting supplier 12. In certain embodiments, it may be desirable to limit the type of information submitted by a supplier to a predefined set of fields in order to provide consistency and uniformity in central database 16.
- central database 16 serves as a repository for information useful in allowing buyer 10 to locate suppliers 12 that offer goods or services of interest.
- central database 16 may also store information relating to buyers.
- buyer 10 may also be allowed to submit information to be stored in central database 16.
- Such information may include, for example, company profiles containing information about the company. Additionally, a company may submit classifications of goods or services that are routinely purchased or desired by a particular buyer. In addition, more detailed information regarding the types of goods or services purchased by a particular buyer may also be submitted.
- central database 16 may store any information that would be useful in allowing supplier 12 to locate buyers of interest.
- buyer 10 it may be desirable to allow buyer 10 to submit any type of information. In other embodiments, it may be desirable to require buyer 10 to submit certain information with the option of submitting additional information. In other embodiments, perhaps only a predefined set of information is submitted by a buyer. Including buyer information into central database 16 allows supplier 12 to browse central database 16 in order to identify the goods or services desired in the marketplace. This may allow a supplier to gauge the size of a particular market or may allow a particular supplier to locate and contact buyers wishing to purchase specific goods or services. In addition, such information may allow supplier 12 to tailor goods or services to the particular needs of a segment of the market.
- a buyer wishing to purchase goods or services may browse central database 16 or a local database, such as local database 18, in order to identify suppliers that offer goods or services of interest to the buyer.
- Buyer 10 may assemble a list of suppliers of interest. Buyer 10 may then use this list to distribute information to suppliers, either directly or indirectly through service provider 14.
- the list of suppliers may be used by the marketplace administrator to specify invited members of a private marketplace created by the buyer.
- the present invention allows not only for an initial broadcast message requesting bids for goods or services, but also facilitates sending follow-up reminders in order to help suppliers remember approaching deadlines.
- Suppliers receiving a broadcast message requesting bid information will respond with the requested information. Responses are collected from various suppliers and stored together in order to keep all information in a single location.
- buyer 10 may directly collect responses and assemble the appropriate information.
- such actions may be performed by service provider 14.
- Still other embodiments have the marketplace object or marketplace admimstrator performing these actions.
- the information may then be transferred to buyer 10.
- Buyer 10 can then examine and analyze the information in order to make purchasing decisions.
- FIG. 2 an embodiment is illustrated showing the database structure of the present invention and the relationship between central database 16 and local databases, such as local database 34 and local database 36.
- service provider 14 maintains a central database, shown generally in Figure 2, as 24.
- Central database 24 can contain a wide variety of information useful to suppliers 12 and buyers 10.
- supplier 12 may use the information stored in central database 24 to locate information about potential buyers of offered services or products.
- Buyer 10 may use the information in central database 24 in order to locate suppliers of goods or services.
- central database 24 may contain information that allow buyer 10 and suppliers 12 to accomplish their objectives.
- central database 24 contain information regarding both suppliers and buyers
- other embodiments of the present invention may contain only information relating to suppliers or only information relating to buyers. Still other embodiments mandate that only the available goods or services be generally available and that the release of specific buyer and seller information be controlled by the marketplace parameters.
- central database 24 may contain company profiles of suppliers. This is illustrated in Figure 2 by suppliers information 26.
- Company profiles may contain any information necessary or useful for allowing a buyer to find more information about a particular supplier.
- supplier profiles may contain such information as a supplier ID, the company name, the address of the company, various telephone numbers where the company may be reached, whether the supplier is an "approved" supplier, contact information at the supplier, various text fields containing information such as a brief company profile, notes, and so forth.
- a wide variety of additional information may be incorporated into a supplier profile. E-mail addresses, internet home pages URL, or any other type of information may be provided in a company profile.
- a supplier profile contain contact information, as well as addresses, telephone numbers, E-mail addresses, and so forth in order to allow a buyer to be able to contact a particular company.
- a company profile have description information sufficient to allow a buyer to select a supplier from among other suppliers in the database.
- Some embodiments also support buyer profiles in central database 24.
- buyer information 28 represents the company profiles submitted by buyers into central database 24.
- Company profiles for buyers may contain similar information to the company profiles for suppliers.
- company profiles for buyers may contain, for example, company name, ID code, address information, telephone numbers, fax numbers, E-mail addresses, internet web page URL, contact information, and so forth.
- central database 24 may also contain classifications.
- classifications are illustrated in Figure 2 by classification information 30.
- classifications may comprise, for example, a classification ID, a classification description, and other information necessary to identify a particular classification.
- Company profiles (either buyer or supplier) and products may then link to these various classifications in order to identify the classes of goods or services offered by a particular company.
- linking them to a class will help locate groups or classes of products or services available in the database.
- Central database 24 may also comprise product information. This is illustrated in Figure 2 by product information 32. Such product information may contain a product
- a supplier ID in order to identify the supplier that offers this particular product and link the product to the supplier
- an item number or ID in order to identify the supplier that offers this particular product and link the product to the supplier
- an item number or ID in order to identify the supplier that offers this particular product and link the product to the supplier
- an item number or ID in order to identify the supplier that offers this particular product and link the product to the supplier
- an item number or ID in order to identify the supplier that offers this particular product and link the product to the supplier
- an item number or ID in order to identify the supplier that offers this particular product and link the product to the supplier
- an item number or ID in order to identify the supplier that offers this particular product and link the product to the supplier
- an item number or ID in order to identify the supplier that offers this particular product and link the product to the supplier
- class information scanned photographs, audio clips, video clips, and any other type of information necessary to identify a particular product in the database.
- companies may submit product information for all products or services offered by the company.
- central database 24 may be the only database in the system and all requests for information may go to the central database. In other embodiments, it may be desirable to distribute some of the information in central database 24 to local databases.
- local databases are illustrated, for example, by local database 34 and local database 36.
- Local database 34 represents a local database used by supplier 12 in order to access relevant information.
- Local database 36 represents a local database accessed by buyer 10 to retrieve relevant information.
- local database 34 may comprise relevant buyer profile information.
- buyer profile information 38 contains the local buyer information desired by supplier 12.
- buyer profile information 38 may represent a subset of buyer profile information 28 of central database 24.
- local database 34 may also comprise product information 40 and classification information 42.
- product information 40 and classification block 42 also represent a subset of the information contained in central database 24.
- supplier 12 it would be desirable to allow supplier 12 to select information contained in local database 34.
- supplier 12 may be allowed to browse central database 24 and identify those records that should be downloaded to local database 34 for local access. In other embodiments, it may be more desirable to download all buyer information to supplier 12. Still other embodiments allow a solicited participant to determine how much of their record is included in the local marketplace database through the marketplace object. Such details are considered to be implementations specific and not critical to this invention. All that is required is that local database 34 contain that information necessary or desired by supplier 12.
- Local database 36 contains all information needed or desired by buyer 10.
- local database 36 may comprise supplier profile information 44, product information 46, and classification information 48. Supplier information 44, product information 46, and classification information 48 may represent a subset of the information contained in central database 24. As previously explained, by keeping a copy of information locally, access to the information may be speeded up.
- Database access/update processing block 50 represents a process running on service provider 14, that maintains central database 24 and sends information to supplier 12 and buyer 10 for their respective local databases.
- Database update message 52 may contain any information that a supplier or buyer wishes to submit to central database 24. Such information may comprise, for example, the company profile information previously described, the classification information previously described, or the product information previously described.
- the format of database update message 52 is not critical and it does not matter whether a single universal message is used or whether specific messages are used for the various types of information that are submitted to central database 24.
- database access/update processing block 50 receives database update message 52, database access/update processing block 50 extracts the appropriate information from database update message 52 and places the information into central database 24.
- suppliers or buyers interested in that record may be informed that new information has been added to central database 24.
- Such a mechanism may be useful, for example, to ensure that a local database has the most current information available in central database 24.
- Transport link 54 represents an example of means for transferring information.
- Transport link 54 is intended to illustrate a generic transport mechanism and not any particular type of transport. It is preferred, however, that transport link 54 be an electronic communication medium. This allows messages exchanged between supplier 12, buyer 10, and service provider 14 to flow electronically without the need to manually enter information into central database 24, local database 34, or local database 36. If, however, a particular supplier or buyer does not have access to an electronic transport medium, then facsimile, telephone, or paper mail may be used to exchange appropriate information. Such a transport mechanism will, however, necessitate the entering of information into the appropriate database by hand. It is anticipated that most, if not all, communication will be electronic due to the widespread availability of electronic communication media including the internet, local area networks, wide area networks, dial-up communications, and other electronic communication means.
- Information request message 56 may be a request to update a portion or all of the appropriate local database. For example, in the embodiments where a supplier or buyer selects the information that is contained in its local database, information request 56 may identify those records of database 34 that are to be checked for currency. On the other hand, if the embodiment requires that a local database contain all appropriate information from central database 24, then information request 56 be interpreted to transfer all relevant information from local database 24 to the appropriate local database.
- embodiments within the scope of this invention may comprise means for identifying records that should be updated.
- Such a means may comprise, for example, a date stamp or other means to recognize the latest version of a database or a portion of a database.
- records may be compared for currency between database versions. It is, however, preferred that a simple mechanism be used in order to speed the process of maintaining a local database and keeping a local database current with respect to the central database.
- database access/update processing block 50 receives information request 56, database access/update processing block extracts the appropriate information from central database 24 and returns that information to the buyer or supplier that requested it. Such information may be returned, for example, in database information message 58.
- Database information message 58 may comprise any information from central database 24 that needs to be transferred from service provider 14 to supplier 12 or buyer 10.
- service provider 14 may keep track of the records in the various local databases. When new information is submitted that affects a particular record of the database, then the updated record may be automatically sent to the appropriate buyers or suppliers by service provider 14. Such an approach would eliminate the need for information request messages to update local databases. As another alternative, service provider 14 may periodically contact each supplier or buyer that maintains a local database and provide updated information. Other mechanisms are also possible and all that is required for the present invention is that the local database maintained by a particular supplier or buyer be able to be updated as new information is received by service provider 14.
- FIG. 3 A and 3B a diagram illustrating one embodiment of the present invention is presented. The process of submitting requests for bids to suppliers and for receiving and tracking responses is presented in conjunction with Figures 3 A and 3B. In Figure 3 A, the details of the processing that occurs on buyer 10 have been expanded.
- Embodiments within the scope of this invention may comprise means for maintaimng a local database.
- both buyers and suppliers may maintain local databases, such as local database 34 or local database 36 of Figure 2.
- the means for maintaining a local database is illustrated, for example, by local database maintenance processing block 60.
- Local database maintenance processing block 60 is responsible for maintaining local database 36.
- local database maintenance processing block 60 is responsible for requesting updates from central database 24 and receiving update information and storing it back into local database 36.
- local database update request message 62 As previously explained in conjunction with Figure 2, such a function may also be accomplished by using information request message 56.
- information request message 56 is illustrated for the purpose of indicating that specific information may be requested from central database 24.
- Local database update request message 62 is a general message intended to update all information in local database 36.
- information request message 56 may be used in Figure 3 to request a new record from central database 24.
- Local database update request 62 may then be used to maintain the requested records in a current state.
- Service provider 14 returns requested information in local database update information message 64 or database information message 58.
- Service provider 14 returns requested information in local database update information message 64 or database information message 58.
- a buyer wishes to send a bid request message to one or more suppliers and receive information from them, the process starts with the buyer browsing a database containing information about suppliers and products.
- a database may be local, such as local database 36, or may be a central database such as central database 24.
- the buyer would access local database 36.
- the embodiments within the scope of this invention may therefore comprise means for accessing a database comprising information about suppliers and products offered for sale by the supplier. Any mechanism that allows accessing and browsing of an appropriate database can be used.
- such means is incorporated into data cast creation processing block 66.
- a message and response tracking object is created.
- Embodiments within the scope of this invention may also, therefore, comprise means for creating a message and response tracking object.
- data cast creation processing block 66 Such means is also illustrated by data cast creation processing block 66.
- data cast creation processing block 66 the purpose of data cast creation processing block 66 is to allow a buyer to browse information in local database 36, select a list of suppliers to receive a request for bid, and create a message and response tracking object.
- a key difference between the present invention and the prior art is the use of a message and response tracking object as a central repository for all information regarding a bid and responses received from various suppliers.
- the process of creating a message and response tracking object is illustrated in Figure 3A.
- the message and response tracking object is an object that comprises the broadcast message that will be sent to one or more suppliers and one response tracking object for each of the suppliers that the broadcast message is sent to.
- the broadcast message contains the information sent to the suppliers about the bid and each response tracking object is adapted to store information received in response to the broadcast message.
- a user creates a data cast message, such as data cast message 68.
- Data cast message 68 contains all the information that a supplier would need to respond to a particular bid. Such information is drawn, for example, from data cast information and message block 70. Data cast information and message block 70 represents information either retrieved or entered by a user in order to create data cast message 68. Data cast message 68 is the message that will be broadcast to each of the selected suppliers. Thus, data cast message 68 may contain any type of information that a supplier would need in order to respond to a request for bid. Such information may include, but is not limited to, identifiers indicating the sender, the data cast, the user, or any other type of identifiers needed in the data cast message. Data cast message 68 may also comprise date information.
- Such date information may comprise the date that the data cast message was created or sent, the date or dates that reminders should be sent to suppliers that have not yet responded, the due date of the bids, and any other dates that identify milestones or deadlines that should be met.
- Additional information that may be included in data cast message 68 may include a purchase order number, the subject of the bid, a message that is to be displayed to the supplier containing instructions or other information, the status of the bid, a sequence of prompts that are to be displayed, attached files representing additional information, specifications, scanned documents, etc., and information regarding the analysis module that will be used to analyze the responses. Although not all embodiments may require all these information fields, many data cast messages may contain this type of information.
- One unique feature of the present invention is the ability for a user to enter a sequence of prompts that will be displayed to a supplier.
- the sequence of prompts represent individual data items that should be returned when the supplier submits his or her bid and can represent areas of comparison between competing bids.
- a sequence of prompts may comprise a parts subtotal, a labor subtotal, miscellaneous charges associated with the bid, a quantity or amount provided, the total price of the bid, or any other information that should be displayed to the supplier and that should be submitted by the supplier in response to the bid.
- the sequence of prompts are text fields that are displayed to the supplier.
- the information requested by the prompt is limited only by the needs and desires of the buyer. Thus, a buyer can request any type of information in the prompts.
- sequence of prompts can represent areas of comparison between bids and may be used by an analysis module for such a purpose.
- receiver objects 72 In addition to data cast message 68, the process of creating a data cast also creates a response tracking object for each of the suppliers that are to receive data cast message 68.
- response tracking objects are illustrated by receiver objects 72.
- Receiver objects 72 allows information received in response to data cast message 68 to be stored into a message and response tracking object.
- receiver objects 72 may contain data fields needed to store any appropriate information received from a supplier in response to data cast message 68.
- receiver objects 72 may comprise ID information necessary to identify the data cast, the response, the sender, the supplier, or any other type of identifying information.
- receiver objects 72 may contain information about the company submitting the bid.
- receiver objects 72 may contain fields to store information requested by data cast message 68. Thus, receiver objects 72 may contain locations to store the responses to the various prompts sent in data cast message 68. Finally, if any analysis module is to be used, receiver objects 72 may contain information that allows such an analysis module to extract relevant information and analyze or display such information for analysis by a user. The use of an analysis module in conjunction with the present invention is described in greater detail below.
- data cast object 74 serves as a central repository for all information regarding a particular data cast.
- data cast object 74 comprises data cast message 68 and receiver objects 72, one for each supplier that will receive data cast message 68.
- a good analogy of data cast object 74 is a folder or file that contains all information relating to a particular bid. Thus, as information is sent and received that relates to a particular bid, such information may be placed into data cast object 74.
- Such a data cast object may be used to send and receive information to and from the identified suppliers.
- Embodiments within the scope of this invention therefore, comprise means for sending broadcast information to identified suppliers.
- FIG 3 A such means is illustrated, for example, by supplier communication processing block 76.
- supplier communication processing block 76 extracts data cast message 68 from data cast object 74 and broadcasts data cast message 68 to the identified suppliers.
- response information is stored into data cast object 74 by supplier communication processing block 76.
- This process is illustrated in Figure 3 by response 78 being stored into data cast object 74.
- Supplier communication processing block represents one example of means for storing information from responses into a message and response tracking object.
- data cast message 68, and data cast object 74 may contain critical date information such as the deadline for bids to be received and one or more reminder dates. This makes it extremely easy to generate reminder messages and broadcast them to those suppliers that have not responded to the bid request.
- supplier communication processing block 76 can monitor the dates in data cast object 74 and, when appropriate, generate reminder message 80 and broadcast reminder message 80 to those suppliers that have not yet responded by the reminder date.
- reminder messages may contain any appropriate information needed to remind a supplier of the deadlines.
- Such a reminder message may, therefore, vary anywhere from a simple reminder text message to a complete rebroadcast of data cast message 68.
- the present invention facilitates analysis of bid information.
- the present invention may utilize a separate analysis module to analyze the information received from a supplier.
- Embodiments within the scope of this invention may thus comprise means for analyzing information received from the suppliers.
- data cast analysis block 82 may be any type of analysis module adapted for analyzing or comparing information received from the various suppliers.
- data cast analysis module 82 is a spreadsheet program.
- Information received from the various suppliers may be placed into the spreadsheet program to allow analysis and comparison of the various bids received from the suppliers.
- data cast message 68 may comprise a plurality of prompts that identify specific information items requested from a supplier. Each supplier should therefore respond with specific items corresponding to each prompt. Each prompt may therefore represent a row in a spreadsheet program and each information item received from each individual vendor may be placed in a column of the spreadsheet. This would allow a rapid comparison of the amounts for each particular information prompt.
- Using a spreadsheet also allows further analysis on the information received from various suppliers. For example, trade off analysis, or other types of analysis may be performed to make intelligent purchasing decisions.
- the first step is for a company to submit company, classification, and/or product information. This action is performed by buyers and/or suppliers.
- This action is performed by buyers and/or suppliers.
- Service provider 14 receives database update message 52, extracts the appropriate information and stores it into central database 24.
- the information may be transferred from central database 24 to local database 36 either through information request message 56 or through database update request 62.
- maintenance of the global database is handled by the service provider and update of the local database by transferring information to the local database is handled by a combination of the service provider and the buyer and/or supplier.
- the bid process begins when a buyer browses the database and identifies a list of suppliers that should receive a request for bid.
- the buyer also creates a message and response tracking object such as data cast object 74, using the supplier list and other information such as the data cast message information previously described.
- the created data cast object comprises the data cast message that will be sent to the suppliers as well as a receiver object for each supplier on the supplier list. Because the data cast object forms a unit of information that contains both broadcast and response information relating to a bid, the data cast object can serve as a magnet for responses and may be passed from individual to individual. For example, once the data cast object has been created the next step is to send the data cast message to the various suppliers.
- this step may be performed by the service provider.
- a buyer may transfer a data cast object to the service provider and the service provider can be responsible for broadcasting messages and receiving responses from the various suppliers.
- the service provider can be responsible for broadcasting messages and receiving responses from the various suppliers.
- reminder message 80 sent to suppliers 12 by supplier communication processing block 76.
- such a function may also be performed by the service provider if the data cast object is transferred to the service provider and if responsibility for sending reminders is transferred to the service provider along with the data cast object.
- the responses are collected and stored into the data cast object. As indicated in the Table above, this step may also be performed either by the buyer or the service provider. In the embodiment illustrated in Figure 3A and 3B, supplier communication processing block 76 of the buyer performs this step. Alternatively, if a data cast object is transferred to service provider 14, the data cast object may serve as a magnet for the responses. As responses are received by the service provider, the responses may then be stored into the data cast object.
- the data cast message and response tracking object may be transferred to an individual, department, or other location for analysis of the bid.
- an analysis module such as data cast analysis block 82 of Figure 3 A, may be used to display or analyze the data received.
- the analysis of supplier responses is typically performed by the buyer. However, since all information relating to a data cast is contained within a single object, the object may be stored or transferred internally to various departments for analysis.
- data cast message 68 contains deadline and reminder information
- client software on supplier 12 may docket these dates in an internal docket or calendaring system in order to automatically track deadlines as they approach.
- responses sent in response to data cast message 68 may be stored in response database 84 in order to allow a supplier to track the bids that have been submitted.
- FIG 4 the details of one implementation of local database maintenance processing block 60 of Figure 3 A are presented.
- local database processing block 60 is responsible for ensuring that local database 36 is properly updated.
- Figure 4 begins with decision block 86 which identifies whether the local database needs to be updated.
- local database 36 may be updated on a periodic basis so that local database maintenance processing block 60 sends a request to service provider 14 on a periodic or regular schedule in order to receive any new information.
- such an update may be performed manually. For example, a buyer may wish to manually update the database information before creating an important bid.
- local database processing block 60 may request an update to ensure that local database 36 is current.
- updates may be initiated by service provider 14.
- Such options have been previously described in conjunction with Figure 2 and any of such options will work in Figures 3 A and 3B.
- step 88 sends a request to service provider 14.
- a request may be local database update request message 62 or, as described in conjunction with Figure 2, may be an information request such as information request message 56. All that is necessary, is that service provider 14 be notified via an appropriate mechanism that an update to the local database is being requested.
- step 90 receives the updated information from service provider 14.
- update information may arrive in local database update information message 64 or database information message 58 as illustrated in Figures 3 A and 3B.
- step 92 indicates that the information in local database 36 should be updated. If multiple messages are needed to update the local database, then information may be stored in the local database as each message is received. Alternatively, all messages may be stored and then the local database updated at one time.
- data cast creation processing block 66 may represent means for creating a message and response tracking object and means for accessing a database comprising information about suppliers and products. These functions are more specifically illustrated in Figure 5.
- step 94 illustrates that the first function to be performed is to allow a user to browse the local database and to assemble a list of suppliers.
- This step thus represents one example of means for accessing a database comprising information about suppliers and products.
- local database 36 preferably allows easy access to information stored in the database. For example, a user may access various classifications in order to identify all suppliers or products that fall in certain classifications. As another example, it may be desirable to allow key word searches on various data fields in local database 36. In essence, it is desirable to allow a user to browse information contained in local database 36 in an intuitive manner in order to reduce the time it takes to locate suppliers that offer appropriate goods or services. As suppliers are located, the user should be able to add them to a distribution list.
- step 96 indicates that the next action is to allow the user to enter data cast information and a message body.
- a function may be performed for example, by presenting the user with a form or template having various fields that can be filled out in order to create the appropriate information. Any of the fields previously described in conjunction with data cast message 68 of Figures 3 A and 3B may be presented to a user. Where automatic generation of an appropriate field is available, it may be preferable to present a default value in a field and allow a user to change the default value if desired.
- a database of past messages or data cast messages may be kept in order to allow a user to bring up a past message and copy one or more fields into the current data cast message.
- a data cast message may contain a series of prompts that will be displayed to a supplier and that identify particular pieces of information the buyer requires. If all that is necessary is a final price be submitted, then the user can enter a single prompt for the final amount of the bid. If, however, the buyer wishes greater detail, then the buyer can enter a series of prompts that will be displayed and that identify information that should be returned by the supplier.
- the series of prompts provides a convenient point of comparison for the various bids.
- the prompts provide a convenient point of comparison for the various bids and may be use in various ways to analyze and compare the bids.
- step 100 the next step is to create the data cast message. This is indicated in Figure 5 by step 100.
- step 100 After a user has entered or retrieved the information required by steps 94, 96, and 98, all information necessary for a data cast message should be available. Thus, data cast message 68 may be created at step 100.
- step 102 indicates that receiver objects are created.
- a response tracking or receiver object is created for each of the suppliers on the supplier list. This ensures that when a response is received from a particular supplier that appropriate space has been allocated and exists to store the information received in the response.
- step 104 then assembles the data cast message and the receiver objects into a single data cast object.
- a data cast object represents but one example of a message and response tracking object that forms a contained unit of information that is used throughout the present invention.
- Step 104 is an example of means for creating a message and response tracking object.
- supplier communication processing block 76 of Figure 3A is responsible for all communications between the suppliers and the buyer.
- supplier communication processing block 76 is responsible for all communications between the suppliers and the buyer.
- the embodiment illustrated in Figures 3A and 3B indicates that this function is performed by the buyer, in alternative embodiments, the data cast object may be passed to the service provider and the service provider would perform analogous functions.
- supplier communication processing block In communicating with the suppliers, supplier communication processing block must be able to handle three specific events. The first event is that a response has been received from a particular supplier. The second event is that a reminder message should be sent to one or more suppliers. The final event is that a data cast message should be broadcast to a list of suppliers. In Figure 6, these three events correspond to decision blocks 106, 108, and 110. Referring first to decision block 106, supplier communication processing block 76 tests whether a response has been received. If such a response has been received, then execution proceeds to step 112 where appropriate information is extracted from the response and placed into the corresponding receiver object in the data cast object. Any of the information previously described in conjunction with Figures 3A and 3B may be stored into the receiver object. The key point is that placing such information into the receiver objects allows data cast object 74 to become a contained unit of information that can be operated upon. After step 112, execution proceeds back to the start to await the next event.
- supplier communication processing block 76 tests whether a reminder message should be sent.
- a reminder date will trigger a reminder message to be sent to those suppliers that have not responded by the reminder date.
- step 114 creates the reminder message and sends a copy to the suppliers that have not yet responded.
- a reminder message may be a simple text message that reminds a supplier that they have not yet responded or may be more complex containing various information up to, and including, all information in original data cast message 68.
- supplier communication processing block 76 tests whether a data cast message should be sent. Strictly speaking, such a decision block may not be necessary if only three events are sent to supplier communication processing block 76. If supplier communication processing block 76 only receives notification of the three events identified in decision blocks 106, 108, and
- decision block 110 may be safely eliminated since by default if execution proceeds through decision block 106 and decision block 108 the only remaining event is that a data cast message should be sent.
- step 116 the data cast message is extracted from the data cast object.
- a message and response tracking object such as data cast object 74, may comprise the data cast message that is to be sent to the various suppliers. Step 116 extracts this message. Execution then proceeds to step 118 where the data cast message is broadcast to the designated suppliers. Execution then proceeds back to the start to await the occurrence of the next event.
- Figure 7 one implementation of data cast analysis block 82 of Figure 3A is presented. As previously explained, the present invention is ideally suited to using separate analysis modules to display or analyze the responses received from the various suppliers. This is because all information is collected into a central repository that can be passed from location to location and individual to individual.
- step 120 indicates that the first step of the analysis module is to extract response information from the data cast object.
- information may be stored that identifies what information should be extracted from the response and placed into an analysis module. For example, company information may be extracted and displayed as a header over a company's bid.
- the information returned in response to the various prompts sent in the data cast message may be extracted and displayed in a spreadsheet or other analysis module.
- step 120 extracts the appropriate information and formats it for use by the analysis module.
- step 122 transfers or places the response information into the analysis module.
- Such a process may require information to be transferred to the analysis module or that a handle or link to the information be passed to the analysis module so that the analysis module may be able to extract or reference the appropriate information.
- Step 124 indicates that after the information has been placed into the analysis module, then the analysis module should display the response information and allow the user to analyze the data.
- the goal of this step is to allow a user to display or analyze information in appropriate ways in order to make sound purchasing decisions. If such analysis requires a plurality of analysis modules or a suite of analysis tools, then the process of the present invention can be adapted to accommodate such a suite.
- the information is transferred into a spreadsheet program, such as Microsoft® Excel.
- Excel or another windows compliant spreadsheet program is utilized, the present invention may use the various functionality provided by the spreadsheet program to transfer information from data cast object 74 to the spreadsheet program.
- Microsoft has defined a standard called OLE that allows information from one program to be linked and embedded into another program.
- information from data cast object 74 may be linked or embedded into a spreadsheet program using this technology.
- Other methods may exist on other computers to allow a similar process to be performed. If appropriate analysis tools do not exist, then such analysis tools may be created and made part of the present invention.
- a single message and response tracking object such as data cast object 74 of Figure 3A
- a folder may be created where all information received is placed. This folder can then become the repository of information and can act like a single message and response tracking object. All that is required for the present invention is a single location or repository for all information regarding a particular data cast that can be transferred and that can serve as a magnet for communications received from the various suppliers.
- FIG. 8 a flow diagram illustrating one implementation of the electronic community (e. COMMUNITY) is illustrated.
- Decision block 126 identifies whether a new member of the e.COMMUNITY needs to be created. Normally, membership to the larger e.COMMUNITY will be granted to individuals without imposing limitations. However, the service provider does maintain the ability to regulate access to the general electronic community. While Figure 8 demonstrates three unique features possible within the e.COMMUNITY, they should not be viewed as necessary limitations on the embodiment rather as independent implementations. These functions are: the creation of member records; the creation of commerce subgroups; and general commerce activities.
- Processing block 128 collects new member information including location of business, contact information, and basic product information to be stored on the central database for the general community. Buyers can provide their company profile and contact information. Suppliers can modify any and all aspects of their profiles, contact information, manufacturers, products, and classifications at any time, to ensure that the information presented to the buyers is correct and up-to-date. Managers may even choose which suppliers can be viewed and selected for bids by the buyers under them. Once the desired information has been collected, execution block 130 submits this information for inclusion within the central database of the e.COMMUNITY.
- Processing block 132 establishes the new member's membership within the e.COMMUNITY providing the individual with access keys and codes to allow it the ability to make general e.COMMUNITY solicitations, to participate in private marketplaces, and to create new marketplaces.
- the data flow branch returns the new member to the home state 134 of general e.COMMUNITY activities. If decision block 126 returns a negative response for the creation of a new member, the data flow branch allows an existing member to login and leads the member directly to the home state 134 for general e.COMMUNITY activities.
- An update feature similar to the new member-creation branch exists for members to update their information in the central database.
- a member, a service provider, or an e.COMMUNITY administrator may update information within the member object for access by other members within the community.
- the members of the e.COMMUNITY may choose to make solicitations or requests for bid to the general e.COMMUNITY, to respond to solicitations, to create new marketplaces, and to participate in various other community commerce transactions.
- Another important feature of this e.COMMUNITY model is the ability of a member to create a new electronic marketplace.
- the preferred method used by members is to utilize "on the fly" or "on demand” marketplace creation techniques. "On demand" marketplace creation is when the marketplace administrator is allowed to create an electronic marketplace containing suppliers and purchasers with common categorical features.
- Processing block 138 presents a series of prompts allowing the administrator to establish various marketplace parameters, including but not limited to, the transactional costs imposed upon suppliers and/or purchasers, price change regulation, the size of the marketplace, the product or category focus of the marketplace, pricing groups, regions served, proxy suppliers, and the membership or individual cost of participation within the marketplace.
- Both Buyers and Suppliers may be charged for the privilege of joining a marketplace. This charge may be either a flat fee, for example $100, or a transaction fee, such as 2% of wholesale price of goods sold via the system.
- the marketplace administrator can also decide that joining the marketplace will be free to buyers and/or suppliers.
- the marketplace administrator decides to regulate price changes, all price changes made by suppliers participating in the market must be approved or made by the marketplace administrator. This feature can protect the buyers and suppliers by allowing the marketplace administrator to notify interested parties of certain price changes. This control feature also allows the marketplace administrator to provide third party certification concerning product pricing at the time the purchase transaction is closed.
- Another marketplace parameter regulated by the administrator is the size of a marketplace. The administrator may limit the number of buyers or the number of suppliers participating in the marketplace. One method of size regulation is through advertising on a general electronic community list which contains all the marketplaces that are open to new enrollment of suppliers or buyers. Suppliers wishing to join a marketplace created by someone else can view and apply for membership from a list of all available marketplaces.
- Suppliers and Buyers may also remove themselves from membership in a specific marketplace, potentially causing the released marketplace to be added to the available list.
- the marketplace administrator may also allow prospective member buyers or suppliers to view a list of suppliers and their products already in the marketplace.
- a further control available to the marketplace administrator is the ability to set the categories of products within the marketplace, to determine the price offered to buyers from the suppliers in the marketplace.
- Pricing groups can be established for each product category. Pricing groups are assigned a base price for each product and the price seen by a buyer for a product is based on a margin percentage or override value.
- An additional control given to a marketplace administrator is the ability to proxy suppliers; namely, the marketplace administrator will appear to the buyers in the marketplace as the source of the product objects.
- the product objects are owned and maintained by another supplier who has contracted with the marketplace administrator to distribute their product.
- Purchase orders received by the marketplace administrator are then electronically routed to the suppliers who own the products being purchased and the products are either sent to the marketplace administrator for further distribution to the buyer or sent directly to the buyer from the actual supplier.
- the marketplace administrator is also given the ability to group the suppliers into a marketplace by region and allow the buyers in the marketplace the option to select only those suppliers in a marketplace from own region. Some marketplace administrators may find it useful to give selected responsibilities over a specific category or function (e.g., membership, pricing, or regional coordination) to another administrator.
- This category administrator can make and regulate changes to a supplier's products within the category and establish pricing groups of buyers for the category just like the marketplace administrator. This feature is useful when the marketplace grows too large for a single marketplace administrator to effectively handle all of the product categories.
- the marketplace administrator can determine the extent of authority that the category administrator is granted within various product categories. Additional marketplace parameters include whether the new marketplace will be offered to buyers based on regions as a local Public Marketplace or will the buyers be "hand-picked" creating a more Private Marketplace.
- a Public Marketplace is a marketplace where many suppliers make their products available to all companies in a specified region.
- a Private marketplace is a marketplace where many suppliers make their products available to specific Buyers.
- selection block 140 allows the new administrator to select the invitees from the central database 16 of e.COMMUNITY members for the new marketplace. This selection may be done in a variety of ways, either by addressing the specific invitees or by compiling a group of individuals who sell a specific product category or product with purchasers interested in these products. Once these individuals have been selected, execution block 140
- Decision block 144 determines whether the individuals have accepted or rejected the invitation to join the marketplace. Should the invitation return a negative response, the notification block 146 alerts the marketplace administrator of the decision by an individual invitee not to join the marketplace. Decision block 148 then allows the marketplace administrator the opportunity to add or select a replacement to the marketplace for the individual who declined the invitation to join. If the administrator decides to choose a replacement, the marketplace administrator returns to processing block 140 and is allowed to select additional invitees from the central database 16. While a central database 16 is used in Figure 8, a local database, categorical database, or dispersed database could be used.
- processing block 150 adds the individual member to the marketplace. This is accomplished in part by attaching a supplier's products to the marketplace object and attaching the purchaser's contact information within the reach of the suppliers through the marketplace object.
- decision block 152 checks to establish whether the marketplace has a sufficient number of participants to open for purchasing transactions. Factors which prevent the marketplace from opening can include only having suppliers or vendors respond to the initial invitation, or not satisfying the minimum number of marketplace participants. If the marketplace status does not satisfy the underlying marketplace parameters, the notification block 146 will alert the marketplace administrator to the potential need to add or select additional participants for membership within the marketplace.
- the decision block 152 will return a positive response and move to the execution block 154 opening the marketplace for general commerce to all members within the marketplace. This action does not prevent additional members from accepting invitations and joining the marketplace later, it merely allows those who respond early to begin trading.
- the administrator following notification block 146 may decide an adjustment of the markplace parameters is necessary. Once these changes to the marketplace parameters are made, the administrator may open the marketplace by moving to the execution block 154.
- Another method of commerce available to members of the e.COMMUNITY is the ability to make general e.COMMUNITY solicitations. Processing block 156 collects the information from the individual desiring to make such a solicitation including details about the product being offered or the request for bid being made.
- Processing block 158 collects the information and creates a data cast module similar to those previously mentioned.
- Execution block 160 filters solicitation based on the member settings which establish the types of contact desired by each e.COMMUNITY member, thereby eliminating junk solicitation not conducive to business.
- Execution block 160 is an optional block in the preferred embodiment as some suppliers and vendors may prefer an open format to the filtered environment offered by this embodiment. The remainder of the process conforms with the previous data cast discussion.
- Processing block 162 creates a message object containing the information to be included within the data cast and to be sent to each of the recipients of the solicitation.
- Processing block 164 creates the receiver objects including the responses to the message object from each of the individuals responding to the solicitation.
- Execution block 166 assembles the message and receiver objects into the data cast object.
- Processing block 168 transmits this data cast object back to the original solicitor.
- execution block 170 extracts the information from the data cast object to display all of the response information.
- Execution block 172 allows the user to complete the transaction either by making a purchase or by allowing the request for bid to expire without a successful solicitation.
- Figure 9 illustrates an electronic community 174 where a plurality of buyers and suppliers may conduct purchasing transactions.
- Figure 9 is also a top level diagram of an electronic marketplace 176 using a flexible repository that is not entirely dependent upon a central database 16.
- the preferred embodiment calls for a marketplace administrator 178 to select the participants for the electronic marketplace 176 from a central database 16 containing all of the suppliers and buyers participating in the electronic commerce community.
- Alternative embodiments do not require using a central database, for example, the suppliers and buyers may be asked to create their information for each electronic marketplace 176 when they accept membership.
- Other embodiments allow a local database containing all of the local suppliers and buyers to be substituted for the central database 16 of the service provider.
- An additional substitute for the central database 16 includes a categorical database, containing all of the members of the electronic community 174 who have listed a particular category of products, as one that they desire to participate in.
- Another substitute is a dispersed database containing suppliers and vendors approved by a purchasing supervisor, manager, or administrator. In this manner, the dispersed database regulates which suppliers a company's purchasing agents may contact.
- the marketplace administrator 178 creates the marketplace, designates the properties within the marketplace, creates all of the marketplace categories, selects which suppliers may join, and chooses the buyers that may access and subscribe to the marketplace.
- the suppliers represent vendors, retailers, wholesalers, and manufacturers that the marketplace administrator has invited to join in the marketplace. They are allowed to post their products in the marketplace categories.
- Buyers represent purchasers, procurement groups, and consumers selected by the marketplace administrator to subscribe to the marketplace for the purpose of bidding and buying from these suppliers.
- the marketplace administrator may also function as either a supplier or buyer within the marketplace.
- participants in the marketplace may have multifaceted roles that include both buyer and supplier functions.
- the electronic marketplace 176 may be created by a marketplace administrator 178 for one enterprise or for multiple commercial groups. Access and transactional fees to the electronic marketplace 176 are controlled by the marketplace administrator 178 for the enterprise.
- the marketplace administrator 178 may also act as a proxy supplier for the electronic marketplace 176 so that the buyers see the marketplace administrator 178 as the supplier rather than the actual drop-ship supplier.
- a marketplace object 180 will contain all of the product information and participant information. This allows the marketplace object 180 to be passed between the marketplace participants like a file folder containing all of the relevant information.
- Additional features included within the preferred embodiment of the electronic marketplace include: a means for Purchase Order tracing to allow the buyer to check the complete history and the current status of a Purchase Order; and means for Split Purchase Order issuance, allowing multiple suppliers to be issued a purchase order from one buyer purchase order.
- This feature is particularly useful when the marketplace administrator has established themselves as a proxy supplier. In effect, the buyer only needs to pay the proxy supplier and the proxy supplier will pay the suppliers.
- the marketplace administrator 178 may place an enterprise name in the Tool
- Supplier 182 represents a supplier within the electronic community 174 who is not invited to join the electronic marketplace.
- Supplier 184 represents a vendor who is invited to join but decides not to join the marketplace.
- Supplier 186 represents a supplier who is invited to join but chooses only to attach some of the supplier's products for display with the marketplace object.
- Supplier 188 represents a supplier who is invited to join the marketplace and attaches all of his products to the marketplace object.
- Supplier 190 represents an individual operating as both a vendor and buyer within the marketplace. This characteristic enables the individual to both view and add product objects to the marketplace object.
- Buyer 192 represents a buyer within the electronic community 174 who is not extended an invitation to join the electronic marketplace.
- Buyer 194 represents a buyer who is invited but does not join the marketplace.
- Buyer 196 represents a buyer who joins the marketplace and makes a purchase from supplier 200.
- Buyer 198 represents a buyer who joins the marketplace after receiving an invitation and makes a request for bid but makes no further transaction.
- the marketplace administrator 178 can be either a buyer, vendor, or a separate entity charged with regulating the operation of the electronic marketplace 176. All of the aforementioned suppliers and buyers are members of an electronic community 174 of subscribers to a larger marketplace. The marketplace administrator 178 does not need to be a member of the electronic community 174, however; the most common type of marketplace administrator 178 is a member of the electronic community 174 instigating the creation of the smaller private electronic marketplace 176.
- the electronic marketplace 176 represents a separate private marketplace from the larger electronic community 174.
- the electronic marketplace 176 contains a marketplace object 180 which may be viewed by the vendors and suppliers who have accepted invitations to join the marketplace 176.
- the electronic marketplace 176 is given responsibility to maintain the purchasing standards established by the marketplace administrator 178 and to send the necessary invitations to the suppliers, vendors, and buyers within the electronic community 174.
Abstract
Description
Claims
Priority Applications (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
EP00945337A EP1242930A4 (en) | 1999-09-02 | 2000-07-12 | Electronic commerce communication systems with multiple user-define marketplaces, controlled pricing, and automated purchasing capabilities |
CA002382948A CA2382948A1 (en) | 1999-09-02 | 2000-07-12 | Electronic commerce communication systems with multiple user-defined marketplaces, controlled pricing, and automated purchasing capabilities |
AU59300/00A AU5930000A (en) | 1999-09-02 | 2000-07-12 | Electronic commerce communication systems with multiple user-define marketplaces, controlled pricing, and automated purchasing capabilities |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US38874799A | 1999-09-02 | 1999-09-02 | |
US09/388,747 | 1999-09-02 |
Publications (2)
Publication Number | Publication Date |
---|---|
WO2001016826A1 true WO2001016826A1 (en) | 2001-03-08 |
WO2001016826A8 WO2001016826A8 (en) | 2002-09-26 |
Family
ID=23535339
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/US2000/018943 WO2001016826A1 (en) | 1999-09-02 | 2000-07-12 | Electronic commerce communication systems with multiple user-define marketplaces, controlled pricing, and automated purchasing capabilities |
Country Status (4)
Country | Link |
---|---|
EP (1) | EP1242930A4 (en) |
AU (1) | AU5930000A (en) |
CA (1) | CA2382948A1 (en) |
WO (1) | WO2001016826A1 (en) |
Cited By (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
GB2367395A (en) * | 2000-03-16 | 2002-04-03 | Ibm | Managing e-commerce |
GB2373071A (en) * | 2001-03-08 | 2002-09-11 | Supplynetone Ltd | Online shopping |
GB2380565A (en) * | 2001-10-03 | 2003-04-09 | Hewlett Packard Co | Electronically operated supply chain |
EP1654622A2 (en) * | 2003-08-04 | 2006-05-10 | Ebay Inc. | Method and apparatus for deploying high-volume listings in a network trading platform |
SG126685A1 (en) * | 2001-11-13 | 2006-11-29 | Singapore Network Services Pte | A payment method for on-line purchases |
US7305702B2 (en) * | 2002-01-09 | 2007-12-04 | Xerox Corporation | Systems and methods for distributed administration of public and private electronic markets |
Citations (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5710887A (en) * | 1995-08-29 | 1998-01-20 | Broadvision | Computer system and method for electronic commerce |
US5842178A (en) * | 1996-02-22 | 1998-11-24 | Giovannoli; Joseph | Computerized quotation system and method |
US5890139A (en) * | 1995-12-08 | 1999-03-30 | Fujitsu Limited | Answering method and system in online shopping |
US5895454A (en) * | 1997-04-17 | 1999-04-20 | Harrington; Juliette | Integrated interface for vendor/product oriented internet websites |
US5903877A (en) * | 1996-09-30 | 1999-05-11 | Lucent Technologies Inc. | Transaction center for processing customer transaction requests from alternative media sources |
US5930767A (en) * | 1997-05-28 | 1999-07-27 | Motorola, Inc. | Transaction methods systems and devices |
US5933813A (en) * | 1995-04-13 | 1999-08-03 | Eldat Communication Ltd. | Sales promotion data processor system and interactive changeable display particularly useful therein |
-
2000
- 2000-07-12 AU AU59300/00A patent/AU5930000A/en not_active Abandoned
- 2000-07-12 EP EP00945337A patent/EP1242930A4/en not_active Withdrawn
- 2000-07-12 WO PCT/US2000/018943 patent/WO2001016826A1/en not_active Application Discontinuation
- 2000-07-12 CA CA002382948A patent/CA2382948A1/en not_active Abandoned
Patent Citations (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5933813A (en) * | 1995-04-13 | 1999-08-03 | Eldat Communication Ltd. | Sales promotion data processor system and interactive changeable display particularly useful therein |
US5710887A (en) * | 1995-08-29 | 1998-01-20 | Broadvision | Computer system and method for electronic commerce |
US5890139A (en) * | 1995-12-08 | 1999-03-30 | Fujitsu Limited | Answering method and system in online shopping |
US5842178A (en) * | 1996-02-22 | 1998-11-24 | Giovannoli; Joseph | Computerized quotation system and method |
US5903877A (en) * | 1996-09-30 | 1999-05-11 | Lucent Technologies Inc. | Transaction center for processing customer transaction requests from alternative media sources |
US5895454A (en) * | 1997-04-17 | 1999-04-20 | Harrington; Juliette | Integrated interface for vendor/product oriented internet websites |
US5930767A (en) * | 1997-05-28 | 1999-07-27 | Motorola, Inc. | Transaction methods systems and devices |
Non-Patent Citations (1)
Title |
---|
See also references of EP1242930A4 * |
Cited By (12)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
GB2367395A (en) * | 2000-03-16 | 2002-04-03 | Ibm | Managing e-commerce |
AU777344B2 (en) * | 2000-03-16 | 2004-10-14 | International Business Machines Corporation | System and method for evoking policy based E-commerce |
GB2373071A (en) * | 2001-03-08 | 2002-09-11 | Supplynetone Ltd | Online shopping |
GB2380565A (en) * | 2001-10-03 | 2003-04-09 | Hewlett Packard Co | Electronically operated supply chain |
SG126685A1 (en) * | 2001-11-13 | 2006-11-29 | Singapore Network Services Pte | A payment method for on-line purchases |
US7305702B2 (en) * | 2002-01-09 | 2007-12-04 | Xerox Corporation | Systems and methods for distributed administration of public and private electronic markets |
EP1654622A2 (en) * | 2003-08-04 | 2006-05-10 | Ebay Inc. | Method and apparatus for deploying high-volume listings in a network trading platform |
EP1654622A4 (en) * | 2003-08-04 | 2008-04-23 | Ebay Inc | Method and apparatus for deploying high-volume listings in a network trading platform |
US8473381B2 (en) | 2003-08-04 | 2013-06-25 | Ebay Inc. | Method and apparatus for deploying high-volume listings in a network trading platform |
US8762244B2 (en) | 2003-08-04 | 2014-06-24 | Ebay Inc. | Method and apparatus for deploying high-volume listings in a network trading platform |
US10387929B2 (en) | 2003-08-04 | 2019-08-20 | Ebay Inc. | Methods and systems for deploying high-volume listings in a network trading platform |
US11164225B2 (en) | 2003-08-04 | 2021-11-02 | Ebay Inc. | Methods and systems for deploying high-volume listings in a network trading platform |
Also Published As
Publication number | Publication date |
---|---|
CA2382948A1 (en) | 2001-03-08 |
EP1242930A1 (en) | 2002-09-25 |
WO2001016826A8 (en) | 2002-09-26 |
AU5930000A (en) | 2001-03-26 |
EP1242930A4 (en) | 2003-08-06 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US6014644A (en) | Centrally coordinated communication systems with multiple broadcast data objects and response tracking | |
US7430523B1 (en) | Automated competitive bidding system and process | |
US8560396B2 (en) | Intelligent agents for electronic commerce | |
EP0876652B1 (en) | Intelligent agents for electronic commerce | |
US7664682B2 (en) | Methods and systems for electronic commerce facility client-based presentation offer management | |
US20050055306A1 (en) | User-defined dynamic collaborative environments | |
US20020099611A1 (en) | Formation of horizontal, vertical and diagonal databases in an extranet based e-commerce platform | |
US20020059132A1 (en) | Online bidding for a contract to provide a good or service | |
US20020027567A1 (en) | Listing network for classified information | |
US20020055888A1 (en) | Internet-based commerce system | |
US20010011222A1 (en) | Integrated procurement management system using public computer network | |
US20020120554A1 (en) | Auction, imagery and retaining engine systems for services and service providers | |
US20010047305A1 (en) | System and method for conducting business-to-business communications | |
WO2001071635A2 (en) | Managing orders based on budget restrictions in a procurement management system | |
WO2000030005A1 (en) | Electronic commerce search, retrieval and transaction system | |
EP1242930A1 (en) | Electronic commerce communication systems with multiple user-define marketplaces, controlled pricing, and automated purchasing capabilities | |
EP1770617A1 (en) | User-defined dynamic collaborative environments | |
WO2001040895A2 (en) | E-commerce market-place using an extranet platform | |
Bhusry | E-commerce | |
WO2002077897A1 (en) | Digital map ranking system | |
JP2002007901A (en) | Electronic mall system, providing method of electronic mall service, and information providing system | |
El-Sheikh | Business-to-business electronic commerce | |
Alghafli | Electronic commerce: A study to develop a general model for the cyber-mediaries during the electronic commerce age | |
JP2003187165A (en) | Bill issuing system and method | |
JP2001357245A (en) | Method, system, and database for electronic commerce mediation |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AK | Designated states |
Kind code of ref document: A1 Designated state(s): AE AL AM AT AU AZ BA BB BG BR BY CA CH CN CU CZ DE DK 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 MD MG MK MN MW MX NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT UA UG US 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 AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE 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) | ||
WWE | Wipo information: entry into national phase |
Ref document number: 2382948 Country of ref document: CA |
|
WWE | Wipo information: entry into national phase |
Ref document number: 59300/00 Country of ref document: AU |
|
WWE | Wipo information: entry into national phase |
Ref document number: 2000945337 Country of ref document: EP |
|
REG | Reference to national code |
Ref country code: DE Ref legal event code: 8642 |
|
WWP | Wipo information: published in national office |
Ref document number: 2000945337 Country of ref document: EP |
|
AK | Designated states |
Kind code of ref document: C1 Designated state(s): AE AL AM AT AU AZ BA BB BG BR BY CA CH CN CU CZ DE DK 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 MD MG MK MN MW MX NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT UA UG US UZ VN YU ZA ZW |
|
AL | Designated countries for regional patents |
Kind code of ref document: C1 Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZW AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG |
|
WR | Later publication of a revised version of an international search report | ||
WWW | Wipo information: withdrawn in national office |
Ref document number: 2000945337 Country of ref document: EP |
|
NENP | Non-entry into the national phase |
Ref country code: JP |