Source: http://www.patentsencyclopedia.com/app/20120245993
Timestamp: 2017-12-18 13:09:15
Document Index: 284312190

Matched Legal Cases: ['application No. 60', 'application No. 60', 'application No. 60', 'application No. 60', 'application No. 60', 'application No. 60', 'application No. 60', 'application No. 60', 'application No. 60', 'application No. 60']

Patent application number: 20120245993
1. A non-transitory computer readable storage medium having embodied thereon a program, the program being executable by a processor to perform a method for providing a discounted deal, the method comprising: providing a merchant account; storing contact information about the merchant; creating by the merchant a limited-time offer for delivery to potential buyers, wherein the offer includes a time period, a condition, and an instruction associated with the delivery of the offer to at least one identifiable classification of potential buyers; presenting updated information associated with the offer; storing information in a buyer profile, the information including an indication of interest from a user, the buyer profile maintained in a memory; associating financial account information with the buyer profile; and updating the buyer profile with new information.
2. The non-transitory computer readable storage medium of claim 1, wherein the new information includes at least one of new transactions, purchases, or payments made by the buyer.
3. The non-transitory computer readable storage medium of claim 1, the method further comprising storing time associated with a payment.
4. The non-transitory computer readable storage medium of claim 1, the method further comprising determining whether the time associated with the payment is within a certain period of time.
5. The non-transitory computer readable storage medium of claim 4, wherein determining if the payment is within a certain period of time includes determining whether the payment is on-time or if the payment is late.
6. The non-transitory computer readable storage medium of claim 1, wherein updating the buyer profile with the new information includes new indications of interest.
7. The non-transitory computer readable storage medium of claim 6, wherein the updating occurs in real-time.
8. The non-transitory computer readable storage medium of claim 1, wherein the at least one identifiable classification relates to at least one particular segment or description related to a group of potential buyers.
9. The non-transitory computer readable storage medium of claim 1, wherein the updated information is available on the merchant account and includes stored data associated with current and past offers where total revenues for offers, the stored data associated with current and past offers presented to the merchant.
10. The non-transitory computer readable storage medium of claim 9, wherein the presented stored data includes an average price paid.
11. The non-transitory computer readable storage medium of claim 10, wherein the average price paid is calculated and updated throughout a specified period.
12. The non-transitory computer readable storage medium of claim 9, wherein the updated information is updated and presented in the form of a chart or graph.
15. The non-transitory computer readable storage medium of claim 14, wherein the financial account information includes additional points or rewards which can be accumulated and stored to a buyer profile.
18. The non-transitory computer readable storage medium of claim 1, wherein the merchant contact information includes at least one of a location associated with the merchant.
19. The non-transitory computer readable storage medium of claim 1, wherein the offer is a one-time offer or an offer that has an accrual function associated with it that tracks a total amount purchased by a particular buyer and determines whether a threshold amount has been reached that enables the buyer to receive the discount or incentive.
20. A method for providing a discounted deal, the method comprising: providing a merchant account; storing contact information about the merchant; creating by the merchant a limited-time offer for delivery to potential buyers, wherein the offer includes a time period, a condition, and an instruction associated with the delivery of the offer to at least one identifiable classification of potential buyers; presenting updated information associated with the offer; storing information in a buyer profile, the information including an indication of interest from a user, the buyer profile maintained in a memory; associating financial account information with the buyer profile; and updating the buyer profile with new information.
21. The non-transitory computer readable storage medium of claim 20, wherein the new information includes at least one of new transactions, purchases, or payments made by the buyer.
22. The non-transitory computer readable storage medium of claim 20, the method further comprising storing time associated with a payment.
23. The non-transitory computer readable storage medium of claim 20, the method further comprising determining whether the time associated with the payment is within a certain period of time.
24. The non-transitory computer readable storage medium of claim 23, wherein determining if the payment is within a certain period of time includes determining whether the payment is on-time or if the payment is late.
25. A system for providing a discounted deal, the system comprising: a processor; a memory; and one or more modules stored in memory and executable by the processor to perform a method including: providing a merchant account; storing contact information about the merchant; creating by the merchant a limited-time offer for delivery to potential buyers, wherein the offer includes a time period, a condition, and an instruction associated with the delivery of the offer to at least one identifiable classification of potential buyers; presenting updated information associated with the offer; storing information in a buyer profile, the information including an indication of interest from a user, the buyer profile maintained in a memory; associating financial account information with the buyer profile; and updating the buyer profile with new information.
26. The system of claim 25, wherein the new information includes at least one of new transactions, purchases, or payments made by the buyer.
27. The system of claim 25, the method further comprising storing time associated with a payment.
28. The system of claim 25, the method further comprising determining whether the time associated with the payment is within a certain period of time.
29. The system of claim 25, wherein determining if the payment is within a certain period of time includes determining whether the payment is on-time or if the payment is late.
30. The system of claim 25, wherein updating the buyer profile with the new information includes new indications of interest.
[0001] This application is a continuation and claims the priority benefit of U.S. patent application number 13/292,971, filed Nov. 9, 2011, and entitled E-COMMERCE VOLUME PRICING, which is a continuation and claims the priority benefit of U.S. patent application Ser. No. 09/922,884, filed Aug. 6, 2001, and entitled E-COMMERCE VOLUME PRICING, which:
[0003] (2) is a continuation-in-part and claims the priority benefit of U.S. patent application Ser. No. 09/426,063, filed Oct. 22, 1999, and entitled MULTIPLE CRITERIA BUYING AND SELLING MODEL, now U.S. Pat. No. 7,818,212;
[0004] (3) is a continuation-in-part and claims the priority benefit of P.C.T. patent application number PCT/US00/11989, filed May 3, 2000, and entitled MULTIPLE CRITERIA BUYING AND SELLING MODEL, AND SYSTEM FOR MANAGING OPEN OFFER SHEETS, which claims priority to: U.S. provisional application No. 60/137,583, filed Jun. 4, 1999, and entitled E-COMMERCE AUTOMATED SELLER SELECTION SYSTEM; U.S. provisional application No. 60/138,209, filed Jun. 9, 1999, and entitled SECURITIZATION OF ACCOUNTS RECEIVABLE; U.S. provisional application No. 60/139,338, filed Jun. 16, 1999, and entitled REAL-TIME OPTIMIZED BUYING BLOCK; U.S. provisional application No. 60/139,518, filed Jun. 16, 1999, and entitled REAL-TIME MARKET PURCHASING; U.S. provisional application No. 60/139,519, filed Jun. 16, 1999, and entitled E-COMMERCE PURCHASING CARD; U.S. patent application Ser. No. 09/342,345, filed Jun. 29, 1999, and entitled CREDIT BASED TRANSACTION SYSTEM AND METHODOLOGY; U.S. provisional application No. 60/142,371, filed Jul. 6, 1999, and entitled TIME VALUE OF MONEY BASED CREDIT CARD FOR MERCHANT; U.S. provisional application No. 60/160,510, filed Oct. 20, 1999, and entitled MULTIPLE CRITERIA BUYING AND SELLING MODEL, AND SYSTEM FOR MANAGING OPEN OFFER SHEETS; U.S. patent application Ser. No. 09/426,063, filed Oct. 22, 1999, and entitled MULTIPLE CRITERIA BUYING AND SELLING MODEL, now U.S. Pat. No. 7,818,212; U.S. provisional application No. 60/162,182, filed Oct. 28, 1999, and entitled MULTIPLE CRITERIA BUYING AND SELLING MODEL, AND SYSTEM FOR MANAGING OPEN OFFER SHEETS; and U.S. provisional application No. 60/173,409, filed Dec. 28, 1999, and entitled MULTIPLE CRITERIA BUYING AND SELLING MODEL, AND SYSTEM FOR MANAGING OPEN OFFER SHEETS; and
[0005] (4) claims priority to U.S. provisional application No. 60/237,474, filed Oct. 2, 2000, and entitled MULTIPLE CRITERIA BUYING AND SELLING MODEL, AND SYSTEM FOR MANAGING OPEN OFFER SHEETS.
Since the capacity is linked between the deal rooms, the available quantity of product falls by the ordered amount in each of the opened deal rooms (96). For example, a seller plans to produce 5000 pieces of product A. The seller opens deal room 1 and deal room 2 and establishes both deal rooms as having 5000 pieces of product A available. If a buyer in deal room 1 purchases 1000 pieces of product A, both deal room 1 and deal room 2 show the available quantity of product A as 4000 pieces. Since the pricing structures within the different deal rooms are different, an order can reduce the price by 10% in one deal room and by only 5% in another deal room.
[0057] Alternatively, the seller can divide the capacity between the two deal rooms. Thus, in the example above, if the seller plans to produce 5000 pieces of product A, the seller can configure both deal room 1 and deal room 2 with 2500 pieces of product A. Thus, if a buyer places an order for 1000 pieces in deal room 1, the available quantity in deal room 1 becomes 1500 pieces, and the available quantity in deal room 2 remains at 2500 pieces. However, buyers participating in both deal rooms are still afforded the advantage of the demand aggregation on 5000 pieces. Throughout the open offer period, the seller maintains the ability to modify various aspects of the offer as deemed necessary. In the last example, if the seller is receiving significantly more activity in deal room 1 than in deal room 2, the seller can reduce the available capacity in deal room 2 by 1500 pieces and add that 1500 pieces to deal room 1. Thus, changing the available quantity in deal room 1 to 3000 pieces and the available quantity in deal room 2 to 1000 pieces. Similarly, the seller can opt to close deal room 2 prematurely and apply the entire available capacity to deal room 1. Sellers are only limited in their modification rights to the extent that any of the buyers would be disadvantaged. Furthermore, any modifications made to a deal room is done in real time; thus, allowing buyers to view the most up to date information at any time.
[0058] Two or more sellers of the same product can also utilize the aforementioned method of employing multiple deal rooms with multiple pricing structures. For example, both a manufacturer and a distributor can be engaged in selling the same products through the system. Since the manufacturer is supplying the distributor with the products, the manufacturer will realize production efficiencies in aggregating product volume between the both the manufacturer's deal rooms and the distributor's deal rooms.
Thus, all parties involved in the transaction will realize cost benefits.
[0059] Moreover, a manufacturer and a distributor of the same product can take advantage of an auto post feature in the system. This feature will immediately post an open offer in the distributor's deal room upon the manufacturer posting an open offer in the manufacturer's deal room. This process includes a distributor receiving a list of products that will be offered in the deal room by the manufacturer. This list is tagged by the distributor to have these products automatically populate in the distributor's deal room along with the requisite lead-time (e.g., a three day difference) between the distributor's receipt of the product and the ship date posted to the buyers.
[0060] The distributor can also specify the price breaks to be added above those provided by the manufacturer (i.e., a starting price of $65/1000 pieces submitted by the manufacturer shows as 125% of that price/same volume to the distributor's customers). The figure applied can be a multiple (1.25), a percentage (125%), set price ($85), etc. along with the requisite price breaks or a flat price and all other information. The system provides the benefit of automatically posting open offers downstream from one deal room to another. Likewise, there can be multiple segments within one deal room based on different customer segments. For example, upon a manufacturer posting an offer in a deal room, three different deal rooms can open for the distributor for three different groups of buyers. The first deal room can specify 125% of the manufacturer's price and a lead-time of three days from the manufacturer's ship date; the second deal room can specify 110% of the manufacturer's price and a lead-time of three days from the manufacturer's ship date; and the third deal room can specify 105% of the manufacturer's price and a lead-time of two days from the manufacturer's ship date. In addition, or in the alternative, other features can also be varied within the different deal rooms, such as pay options and product options. It is to be appreciated that the auto post feature can be used by a plurality of sellers with related products and is not limited to a manufacturer and distributor relationship.
[0061] The feature described above can also work in the opposite direction with a distributor placing an order that triggers a single or aggregated offer from a manufacturer. For instance, a distributor in a family of regionally dispersed distributors has an order for 10,000 units of a product that is needed in five weeks. The distributor can request this order be an aggregated offer posted to the rest of their divisions/deal room participants for aggregation. An open offer is triggered by this request with any price breaks that have been predetermined by the manufacturer. The manufacturer can have an automatic check feature, which can check if the offer is already posted and alert the distributor. The automatic check feature can also check to see whether the offer is within a time frame specified by the manufacturer, whether any options are included in the offer, whether capacity is available to post the offer. Furthermore, a message can be sent directly to the manufacturer's messaging system for a confirmation request before it is posted as an open offer.
[0062] Once this open offer is posted, it will automatically have the requested amount specified by the distributor baseloaded within the offer, and other distributors are notified of the purchasing opportunity. Another offer can automatically populate in the distributor's deal room for their buyers as well. Moreover, the manufacturer can request that another open offer be created in a different deal room at a different pricing structure. For example, a large distributor with access to the trigger functionality requests and posts automatically an aggregated offer from a supplier. This open offer is then baseloaded with the order and presented to the rest of the buyers within that section of the deal room. As more buyers order, the price drops accordingly. The trigger function automatically populates a second open offer to other deal rooms provided by the manufacturer. The pricing structures and quantities can be predetermined in the system and can be changed at any time. A confirmation function can be engaged which requests that the manufacturer validate the option of posting the offer in another deal room.
[0063] Buyers also have the ability to rank the performance of any sellers with whom they have transacted. Sellers can be ranked on criteria such as, on-time delivery, quality of goods, communication, and response time to Requests for Quote (RFQ), Requests for Offers (RFO), and Requests for Product (RFP). Both buyers and sellers can allow other buyers and sellers to view their respective rankings. In addition, buyers and sellers are afforded the opportunity to leave feedback to a buyer or seller in response to a transaction between the parties. Such feedback can be available to the entire user community, thus affording a new buyer the opportunity to view a particular seller's on-time delivery history prior to placing an order with that seller.
[0064] An aggregate offer can have a fixed minimum order quantity or a variable minimum order quantity. In an offer that contains a variable minimum order quantity, a seller can fluctuate the minimum quantity that an individual buyer must order as the total aggregate order changes. For example, an offer can be established to automatically decrease the minimum order quantity from 500 pieces to 100 pieces as soon as the total aggregate order quantity reaches 5000 pieces. Then again, an offer can be created in which no minimum order quantity is required; however, the seller retains the right to cancel the entire order if the quantity does not reach a predetermined level by a specified date and time. Minimum order quantities can be specified per shipping location. This allows sellers to take advantage of shipping aggregation for different ship points.
[0065] The system also has the ability to automatically suggest or create offers based on history or user specifications. These offers can be time or quantity dependent. For example, the system automatically opens an offer for a specified product every two weeks or every time 1000 units of a product are ordered, the order closes and a new order for that product is opened. Offers can also be created automatically based upon a purchasing agreement between a buyer and seller for guaranteed acceptance of product orders throughout a predetermined time period. Thus, the seller can post planned inventory in advance. For example, if a buyer agrees to accept shipment of 100 racks of glass the first week of every month for the next six months, the seller then posts the availability of an additional 50 racks of the same glass for the same week. The original buyer provides a base that absorbs much of the fixed costs associated with the schedule while the incremental 50 racks represents proper capacity utilization at much higher profit margins.
[0066] Buyers have the ability to create conditional orders for a product. Conditional orders are created, for example, when a buyer agrees to place an order if the price drops below a specified level or if the aggregation reaches a certain percentage discount. If, or when, the condition is met, the buyer's order will be automatically placed by the system. Furthermore, the system will recognize when two or more conditional orders can be combined to perfect the condition and thus, place these orders. For example, buyer 1 wants to buy X units of a product if it falls below $5 and buyer 2 wants to buy Y units of the same product if it falls below $5. If quantity X plus quantity Y plus any quantity currently on order is enough to bring the price below $5, both buyer 1's and buyer 2's orders will be placed.
[0067] In view of the foregoing features described herein, exemplary web pages in accordance with various aspects of the present invention will be better appreciated with reference to FIGS. 5-10. It is to be understood and appreciated that the present invention is not limited by the illustrated order of these web pages, as some aspects could, in accordance with the present invention, occur in different orders and/or concurrently with other aspects from that shown and described herein. Moreover, not all illustrated features on the web pages may be required to achieve the advantages of the system in accordance with an aspect the present invention.
[0068] Turning now to FIG. 4, an exemplary Internet web page 120, which provides buyers and sellers with access to a forum for conducting business, is shown. The web page 120 includes hyperlinks for handling both registered and un-registered buyers and sellers of products. For example, registered buyers can select a hyperlink to a registered buyer login screen via hyperlink 125 while non-registered buyers can select a hyperlink to a non-registered buyer registration screen via hyperlink 130. Similarly, registered sellers can select a hyperlink to a registered seller login screen via hyperlink 135, while non-registered sellers can select a hyperlink to a non-registered seller registration screen via hyperlink 140. While separate hyperlinks are shown for buyers and sellers, it will be appreciated that such hyperlinks could alternatively be combined and the status of buyer or seller could be determined during a later stage in the login procedure.
[0069] Turning now to FIG. 5, in accordance with one aspect of the present invention, an exemplary product category web page 150 is shown. Included on this page is a category menu 155, comprising hyperlinks 160 to other product category web pages. The web page 150 also includes a general pull down menu 165, which allows a user to perform such functions as: find help on a particular topic; contact the seller and/or the web page host; update and/or view the user's profile, which includes details such as, the user's login name and password, company information, shipping information, billing information, and any special instructions; view past orders and/or current orders; view and/or edit the favorites menu; search for products, buyers, sellers, etc.; and log out of the system. The product categories menu 155 and the general menu 165 can be included on each web page for ease of navigation throughout the system.
[0070] The product category page 150 includes the category name 170 and a brief description of the category 175. A list of the product's subcategories 180, if available, is shown with hyperlinks 185 to each of the product subcategory's pages (not shown). The product subcategory page is similar in structure and content to the product category page 150. A section containing a summary of products available under the product category is shown. This section includes information such as, the name of the product 190, whether the product has any open offers, aggregate 195 or single 200, how many open offers are available for each product, and a hyperlink 210 to the product details web page. If any open offers exist for this particular product category, a section with a summary of the open offers will be shown. This section can be split into a summary of the open single offers 215 and a summary of the open aggregate offers 220. This open offer summary includes information such as: the product name 225, a hyperlink 230 to an offer details web page, the shipping terms 235, the price 240, the shipping date 245, and a hyperlink 250 to a seller sponsored deal room. Shipping terms are included in both single and aggregate offers and are typically Free On Board (FOB) terms. However, other shipping terms can be provided, such as FAS, CIF, C&F, or any other applicable shipping term. The hyperlink 250 to the supplier sponsored deal room allows a buyer to place an order in connection with one of the offers.
[0071] The product categories menu 155 can also link the user to a catalog (not shown). The catalog can be viewed and arranged by product type, by seller, and/or by pricing. Sellers have the option of blocking access to any or all of their product listings from specified system users. Sellers can also create custom templates for ease of adding a new 25 product listing. A default template is also available by the system host for this purpose. The product listings in the catalog contain details about each product, including the manufacturer/distributor, default pricing and/or price curve, any available options and/or customizations, minimum order quantities, ship terms and links to related products. The catalog can also be accessed through alternate means, such as the search function, the favorites menu, the user's homepage, etc.
[0072] An example of a product details web page 260 is shown in FIG. 6. Here an image of the product 265 is shown along with details 270 that can be important to a buyer when determining whether to purchase the product. Included in these product details 270 are: the name of the seller, with a hyperlink 275 to a seller details page (not shown); the name 5 of the manufacturer, if different from the seller, with a hyperlink 280 to a manufacturer details page (not shown); unit description 285 (e.g., pieces, feet, inches); and a description of the product 290, which can include details not readily apparent by the image shown. The seller details page and the manufacturer details page can include information such as: the name, address, and contact information of the seller and/or manufacturer; other products available by the seller and/or manufacturer; feedback from other buyers and/or sellers; and any open offers currently available from the seller and/or manufacturer. Also included on the product details page is a `View Open Offers` hyperlink 295 to view offer details of any open offers for the product and a `View History` hyperlink 300 to product history web page (not shown). The product history page can show details and/or summaries of the product history, such as, when the product was introduced to the system, how many times the product has been ordered in the past, on what dates, and in what quantities, the average cost of the past orders, how many buyers participated in the offers, and when the next open offer is anticipated. A `Create RFQ/RFO` hyperlink 305 is provided to direct buyers to a page, which will allow them to 20 request a quote or offer for the product in the event that there are no open offers for a product or the current open offers do not meet the buyer's needs (e.g., shipping date, quantity, options).
[0073] Turning now to FIG. 7, in accordance with one aspect of the present invention, deal rooms are set up in which buyers are able to view the details of an open offer and order products in connection with the open offer. The deal room includes the product name 315 and a hyperlink 320 to the product details web page. Also included in the deal room is an offer details section 325, which contains information such as: the offer number; the seller, with a hyperlink to the seller details page; the ship date or ship date range; the ship terms; quantity available; quantity sold; quantity on hold; minimum order quantity; ship increments; offer open date; offer close date; and any other additional information given by the seller. The minimum order quantity can be fixed or it can change with the current ordered volume against an offer. The pricing for this offer is displayed in both a graphical format 330 and a table format 335. The current price 340 for the product, based upon the quantity of parts currently on order, is shown in real time. The current price is based on a base product without any custom options. If options are available for the product, they will be shown in an options section 345. In this example, options for product size and product color are offered. Any price increase or decrease is shown with respect to each option. For example, if the product has a standard blue coating, the option to have a yellow coating increases the cost to the buyer by $2 per 1000 pieces. However, if the buyer opts to order the product without any coating, the 10 cost decreases by $8 per 1000 pieces. Thus, a seller could configure the deal room to show different price curves for each of the different product options. Furthermore, different deal rooms for the same product can be configured to provide different available options for the different buying groups.
[0074] Based on the above information, if a buyer desires to place an order, the buyer selects an `order` icon 350, displayed within the deal room, to continue the purchasing process. Alternatively, if the buyer is interested in the offer, but does not yet wish to place an order, the buyers can select a `watch this offer` hyperlink 355 displayed within the deal room. The offer can then appear on a web page, such as the buyer's homepage, in which all of the buyer's watched offers will be displayed. Moreover, the system can be prompted to notify the buyer of any activity that can occur with respect to that particular offer. Furthermore, if the buyer has any questions about the offer, the buyer can choose the `contact seller` hyperlink 360. This hyperlink 360 will direct the buyer to the seller's email, or messaging, screen.
[0075] If the order icon is selected, the buyer is then directed to an order web page 380, as shown in FIG. 8. This page references the offer in which the buyer is interested. Here the buyer enters information required by the seller to fulfill the order. Such information includes: the buyers purchase order number 385, the quantity required 390, product options 345, if available, and billing and shipping information 395 (FIG. 9). Upon entering an order quantity, the system can prompt the buyer with a message alerting the buyer of an additional discount if the order quantity is increased. Such a prompt can also appear when the buyer is ready to confirm his/her order. The prompt can include `yes` and `no` icons so that if the buyer chooses `yes`, the system will automatically increase the buyer's order quantity and calculate the new unit price and overall price. If the buyer chooses `no`, the prompt will disappear and the buyer can continue with the order process. Furthermore, system prompts, such as this one, can be turned on or off according to the buyer's preferences.
[0076] The order page also contains an entry field 400 for a coupon or discount code. These codes are uniquely recorded by the system, thus providing that the buyer will not use the coupon or discount more than intended. Coupons or discounts can expire based on the number of times used, the date, and/or the order quantity. The system also supports an accruing discount function. This allows sellers to offer automatic discounts to buyers who achieve purchasing milestones. The number of units purchased, total dollar volume, total orders placed, and/or total time spent buying online can specify these milestones. Similarly, an entry field 405 for a gift certificate or merchandise credit code is provided on the order page (FIG. 9). If the buyer does not wish to use the entire gift certificate or merchandise credit amount for the order, the buyer can specify the dollar amount that he/she wishes to use for the order. Based upon the current product price, the quantity ordered, what options are selected, and whether any discounts or coupons have been used, the total price field 410 will automatically populate with the buyer's total order price. The buyer can also add any additional instructions, including shipping instructions, for the seller.
[0077] Once the buyer has completed the order entry, the buyer selects a `continue` icon 415. At this point, if the system determines that the buyer is not logged in, the system will require the buyer enter a login name and password, or alternatively, complete a registration process, such as that shown in FIG. 10. In the present example, the registration form 420 requests that the buyer enter the following information: buyer name; address; primary contact person; phone; fax; e-mail; short description of company; preferred login user name; and preferred password. With respect to the user name and password, the processing unit 64 is configured to determine whether the selected user name and password combination are available and, if not, to prompt the buyer to enter a new user name and password until an available combination is selected.
[0078] If the buyer is registered and logged into the system, he/she will be directed to an order confirmation page (not shown). Here the details of the order are shown and the buyer has the option of confirming, modifying, or canceling the order. If the buyer confirms, the order is placed with the seller or the order is sent to a shopping cart. Shopping carts can be seller specific. Thus, the buyer can have more than one shopping cart active simultaneously. It is to be appreciated that shopping carts can also be organized by product category. Moreover, the buyer can only have one shopping cart active that contains all orders made by the buyer. Shopping carts will typically be emptied once a buyer logs out of the system. However, a buyer has the option of saving the shopping cart for later verification. While orders are active within a shopping cart, the deal room can show the order quantity as on hold. Line items within the shopping cart based upon offers that have already closed will be considered invalid and ignored by the system. A shopping cart can also be created to save quotes received from a seller.
[0079] However, the system can determine that the order cannot be confirmed. An alert system can be employed to notify the buyer that the order, as placed, exceeds the buyer's authority. This can occur if the buyer is configured within the system to have limited purchasing authority. For instance, the buyer may only be permitted to order specified products, to remain within an account spending limit, and/or to not exceed a certain dollar amount per order. The buyer's supervisor, the seller, or any other user with appropriate authority can place such limits. The system can automatically cancel the order, alert the buyer to edit the order, or to forward the order to the seller or a supervisor for authorization if the buyer exceeds his authority. If the order is awaiting authorization, the system will hold the order for a predetermined time period. Thus, the quantity available will be reduced for other buyers. The other buyers may be aware of the quantity being held, but they will not have access to the identity of the buyer for whom the product is being held. If the order is cancelled, the hold quantity is released and made available again to the other buyers.
[0080] Regarding FIG. 12, although the present invention has been largely described within the context of a seller sponsored deal room (FIG. 11), it is to be appreciated that a buyer or buyers can sponsor a deal room to aggregate purchasing goods/services from a plurality of sellers. For example, a large corporate buyer can employ the present invention to create a deal room where a plurality of sellers can assemble to aggregate selling of specific goods and/or services that the buyer desires. Such a transaction facilitates the buyer satisfying purchase requirements in one forum and to coordinate deliver of goods/services. Furthermore, such a system facilitates sellers making sales to the buyer, which but for the sellers being able to aggregate the buyer may not have dealt with the individual seller because of insufficient capacity to meet the buyers needs. The subject specification describes exemplary systems and interfaces for implementing the subject invention, and therefore further discussion thereto is omitted for sake of brevity. However, it is to be appreciated that one skilled in the art based on the above discussion regarding seller sponsored deal rooms/transactions could apply such teachings to implement the aforementioned buyer sponsored deal room/transaction.
[0081] Regarding FIG. 13, although many aspect of the present invention have been largely described within the context of a seller sponsored deal room/transaction; it is to be appreciated that buyers and sellers can concurrently sponsor a deal room/transaction to aggregate selling of and purchasing of goods/services by a plurality of sellers and buyers respectively. For example, a multiple sellers and buyers can employ the present invention to create a deal room/transaction forum where a plurality of sellers and buyers can assemble to aggregate selling and buying of specific goods and/or services that the sellers wish to sell and the buyers desire to purchase. Such a transaction forum creates great efficiencies with respect to purchase price and/or selling quantity of particular goods/services. For example, in such a forum dedicated to the selling and purchasing of a specific product/service, sellers can assemble to compete for the sale of their respective product/service, which leads to pricing efficiencies. Buyers can assemble in such a forum to aggregate buying power in order to negotiate good prices and close deals. Sellers on the other hand can also aggregate to meet the needs of a large buying block. The subject specification describes exemplary systems and interfaces for implementing the subject invention, and therefore further discussion thereto is omitted for sake of brevity. However, it is to be appreciated that one skilled in the art based on the above discussion regarding seller sponsored deal rooms/transactions could apply such teachings to implement the aforementioned buyer sponsored deal room/transaction.
[0082] The users and groups module is capable of storing users, groups, and their details, such as demographic and marketing information. For example, a buyer is presented with a catalog item to determine whether the buyer would be interested in purchasing that item, and if so, when they would next need the item and at what quantity. This information could then be used to suggest or automatically create aggregate or single offers. Users are virtual representations of the physical users of the system and/or remote systems, such as corporate purchasing servers or sales-processing servers. Groups are collections of users with specific system roles and/or rights. For example, a seller group can be granted the right to manage a particular access group and a buyer group can be granted access to a particular set of offers and the right to place orders on particular products. Furthermore, groups can be offered different pricing structures and/or product quantities than individual users for a particular product. Groups can be contained within other groups, thus creating parent-child relationships. In these relationships, child groups inherit access permissions from their respective parent groups. The system host or administrator, the seller, or the individuals within the group can determine the makeup of the groups. Although the descriptions and examples herein commonly refer to transactions between an individual buyer and an individual seller, it is to be appreciated that such transactions can also occur between one buyer and a group of sellers, a group of buyers and a group of sellers, or a group of buyers and a group of sellers.
[0083] Both users and groups are identified by a login name and password, which are chosen by the users and groups upon registration. Passwords can be stored using MD5 encryption. MD5 uses one-way functions rendering it impossible to generate the password from knowing only the MD5 hash of the password. Therefore, users and groups will be prompted to choose a question and answer pair that will be used to identify a user or group in the event that the password is forgotten. Users and groups can choose to associate identifying characteristics to their login identity, such as a company name, shipping address, billing address, company logo, and/or biography. Some or all of this information can be required if the user and/or group chooses to buy and/or sell a product.
[0084] The access control module allows item creators to specify a set of rules, or permissions, as to who can access, modify and/or use the items, wherein the term item is used to denote categories, products, offers, etc. Read permissions allow users or groups to see, but not edit, item information. Edit permissions allows users the ability to make changes to the item, as well as, to the access control information relating to that item. Relate permissions are used to give a user the ability to create parent/child relationships among items; for example, the ability to create a derived product, an offer, or to place a product in a category. Place order permissions enable one to place an order on an offer or to use a line of credit/account to place an order. System administrators, or other similarly privileged users, have override permissions, which enable them to make modifications without being subject to edit rules. Override permissions can be global or specific. Global override permissions enable one to override all edit rules anywhere on the system, while specific override permissions enable one to modify data pertaining to specified, limited areas of the system.
[0085] The messaging module includes the ability for the system to communicate with users and other integrated systems. Users are notified of any change that occurs in an offer that they are involved in, such as a price change, an opportunity for further discount, change in shipping terms, and/or when the offer has been closed. Users can also request to be notified of similar changes in offers that they are interested in but have not yet participated. Likewise, users can request to be notified if any activity occurs on a particular product or product category, such as an additional options available for a product, new products offered within the category, new open offers, RFQs, RFOs, RFPs, and/or a price changes. Messages can also be sent regarding important changes to the system in general. Furthermore, this module contains the ability to turn messages off for the entire system, individual users, groups, access points, and/or remote systems. The notification and messaging system is also integrated within other modules.
[0086] Messages can be sent through email, fax, mobile devices, instant messages, bulletin boards, and/or through a user's homepage. An example of a user's homepage 450 is shown in FIG. 14. The page 450 includes a seller section 455 where the user selects what information he would like to see about a seller, for example, total product offerings, product offerings within a specific category, and any open offers. A product categories section 460 can also be included on the web page. Here, a user can see whether any products or product categories that have been added, modified, or deleted in the system. The user's homepage 450 also includes a news section 465 in which the user can view news headlines and/or market conditions in any specified industries. This section can also inform the user about what has changed on the system since the user was last logged on. For example, the user can see any new buyers and/or sellers that have joined the system, any new offers that have been opened in his area of interest, and any changes that have occurred in the user's own open offers. The homepage 450 can be configured to allow the user to monitor all open offers in which he/she is participating 470 and/or all open offers in which he/she has selected to watch 475. The web page also contains a search field 480, which enables the user to search the system for information, such as a particular seller, buyer, product, or offer. For example, a buyer can search for 10 all open offers which meet the buyer's criteria. The results can be arranged in order of cost, shipping date, offer close date, etc. A hyperlink 485 is provided to the user's account information page (not shown). The account information page allows the user to view and/or modify passwords, shipping and billing addresses, methods of payment, etc. Another hyperlink 490 is provided to the user's history page (not shown). Here the user can view all past orders, RFQs, RFOs, RFPs, etc. It is to be appreciated that this is just one example of a homepage and that many variations can exist since each homepage is customized to provide information relevant to the particular user.
[0087] The terms and conditions module handles the entry, storage, and acceptance of system-wide, access point sponsor, and seller terms and conditions. Terms and conditions can be created by using a system template or through free text entry; and relate to the terms governing the sale of the product according to which both the buyer and seller are willing to conduct business. System-wide terms and conditions are those that apply to, and must be accepted by, all users and groups participating in the system. It is possible to have one set, more than one set, or no sets of active system-wide terms and conditions. Access point sponsors can require users of their access points to agree to one or more set of terms and conditions. Sellers can require buyers, which wish to purchase from them, to accept certain terms and conditions. Sellers can have different sets of terms and conditions for different buyers. For example, a seller can have stricter set of terms and conditions for first time buyers than for those which the seller has maintained a long relationship. Likewise, any other user requiring another user to accept certain terms and conditions can tailor the terms and conditions to apply to that particular user. Moreover, buyers can also require seller to accept the buyer's terms and conditions prior to purchasing. The terms and conditions agreed to between parties are stored in the system and can be modified as necessary.
[0088] The blanket pricing module allows a seller to provide discount pricing to individual buyers and/or groups of buyers for one or more items. The system always defaults to the lowest price available to a buyer when determining the final order cost. Thus, although buyers can have multiple blanket prices for a particular product, the lowest price will always take precedence. For example, a 15% discount can yield a lower overall cost than a $5 off discount in a particular order. Blanket pricing can be indefinite, dynamic, or fixed. Indefinite blanket pricing is in effect immediately after it is entered or beginning at a specified start date and will affect all future orders until the blanket price is manually revoked. A pricing sheet or equation is employed for dynamic blanket pricing. Here, the price can increase or decrease depending upon the buyers purchasing activities. Dynamic blanket pricing can apply to one product or an entire family of products. Fixed blanket pricing gives sellers the option of setting a start date and end date for which the blanket price is effective. Alternatively, the blanket price can only be effective for a specified quantity of products.
[0089] Blanket prices can be specified as a percentage or as a specified dollar amount to be discounted from the final price. Sellers can also use stepped blanket pricing. This allows the sellers to provide the buyers with a pricing sheet that details changes in the blanket prices with order quantity and/or time. The system has the ability to recommended pricing strategies for sellers to construct better blanket pricing. These strategies include calculation routines that use a maximum discount percentage, or fixed cost, to create a step structure such that when the buyer has purchased the required amount, the average price per unit is at the desired level. For example, a seller could offer a blanket price of $15/unit with a commitment of 5000 units. Rather than assuming that the purchasing commitment will be met, the seller could structure the pricing as $20 for the first 2000 units, $18 for the next 1000 units, and finally, $8.50 for the remaining 2000 units. Thus, if the buyer purchases the entire lot, the average price of $15/unit is attained; otherwise the buyer simply receives a tiered discount.
[0090] The system recognizes relationships between products. A manufacturer can identify a bill of materials for a product and configure the system so that an order for a product will, in turn, trigger orders for all of the product's component parts. Alternatively, the system can present order recommendations or place RFOs or RFQs instead of actually placing the order. Byproduct relationships are also recognized by the system. Here, the system automatically creates or suggests a byproducts offer when the primary product is ordered. For example, if an order for brass fittings is placed, the system will put out an offer for brass scrap metal produced by the machining process. As more orders are placed, the offer quantity increases. Furthermore, the system can recognize when two different products produce the same byproduct. For example, if an order for brass valves is placed, instead of creating a new offer for brass scrap metal, the system will increase the quantity of the brass scrap metal offer that has already been placed as a result of the order for brass fittings.
[0091] The system also recognizes products that share certain features and/or characteristics. Thus, when opening an offer for a particular product, a seller can be alerted of the manufacturing efficiencies available if he also opens an offer for other family members of that product. These manufacturing efficiencies can be based upon decreases in machine change over time when switching from one product to another, decreases in tooling and/or raw material cost, and/or increases in operator efficiencies. Also, products and/or product families can be shared between one or more sellers. The sellers could be two distributors of the same product, a manufacturer and a distributor of the same product, two manufacturers of the same product and/or one of the aforementioned combinations of related products that can be readily substituted. Thus, if one seller does not have the capacity for a buyer's requirements, the system can suggest or automatically split the buyer's order quantity among the different sellers.
[0092] Aggregation of shipping costs can be achieved with the logistics module. Thus, on an open offer, buyers can receive the benefits of product aggregation, as well as the benefits of shipping aggregation. Buyers and sellers can choose to share shipping costs with those who share single departure and arrival points and/or with those who share a common truck route. Truck filling based aggregation uses the truck dimensions to fill the truck to a specified percentage capacity. A pricing sheet, or pricing equation, will be used to determine the savings as different capacity levels are achieved. Moreover, the system can determine whether any buyers or sellers within a specified area are having product shipped on the same day. Such area-based truck sharing supports both multiple load and delivery points. The system can further divide the shipping area into zip codes. Rules are then used to determine how to best fit the items on the trucks. Furthermore, custom truck routes can be created by the system in order to achieve the most efficient shipping schedule, which, in turn, leads to significant cost benefits. For example, a preliminary route is provided with list of intervening zip codes. The system then searches for orders that can be picked up or delivered using that route. The system can also modify the route based on other orders as long as the modified route will not detrimentally affect the overall shipping schedule. This module can be integrated with shipping companies and can, alternatively, be available as a separate service.
[0093] The RFQ and RFO functions are designed to drive orders towards aggregation whenever possible. A buyer user, agent, or process initiates a RFQ and/or a RFO to predetermined sellers or all sellers of a particular product, specifying an existing product or a description of what is desired. If a specific product is requested by the buyer through a RFQ and/or RFO to a seller, other than the seller of the specified product, that seller will only receive a general description of the product. The RFQ and/or RFO can also include other buyer requirements, such as, quantity, cost range, delivery date or date range, and/or one or more delivery points. Upon receiving the RFQ and/or RFO the seller can accept the request and reply with a corresponding quote and/or offer, or the seller can reject the request. If the request is rejected, the seller has the option of notifying the buyer which requirements the seller was not able to meet, and further, make reasonable counter-offers to the buyer. Thus, the buyer and seller have the opportunity of negotiating for a successful transaction. As an alternative to a RFQ, the buyer can employ a quote generator to view various offer and option choices. The quote generator can return the same information as a formal RFQ but may not be binding upon a seller unless that seller confirms the quote.
[0094] An RFP allows a buyer user, agent, or process to request product from one or more sellers. The request can be for a one-time offering of the particular product or can be for a regular listing of the product. The RFP can detail which characteristics of the product the buyer is interested in, which can lead to a seller suggesting a similar product that the seller currently offers through the system. The RFP can also detail information such as, how often the buyer needs the product, in what quantities, what price range, whether any options are desired, and the next need date.
[0095] The invoicing module is utilized to store and update account information, create transaction summaries and invoices, and to process account status-dependant queries, such as those necessary for account spending limits. System-to-party invoices, such as transactions fees and recurring fees (e.g., the monthly hosting cost), can be automatically created through this module. The transaction fees are structured as per-transaction fees, fixed percentage fees, or variable fees. The per-transaction fee is set so that a user is charged a predetermined fee for each transaction, regardless of the total order cost. The fixed percentage fee is based on the total order cost for each transaction. The variable fee employs a pricing sheet to specify different transaction fees at different order volumes. These fees can be applied against a seller, a buyer, or both. Recurring fees are initialized to charge a user a predetermined amount and a regular frequency. The ability to set fee start dates, end dates, and waivers are also provided by the system.
[0096] The invoicing module also manages system-to-system invoicing and party-to-party invoicing. System-to-system invoicing allows the system to notify integration partners of the amounts that they or those who access the system through them owe. Party-to-party invoicing allows sellers and buyers to manage their account online, including account spending limits. If a buyer places an order, or any other fee-required transaction, and does not maintain an account with the system or the transaction exceeds the buyers spending limit, the buyer will be prompted to pay for the transaction through a credit card, electronic check, or other immediate-approved method. If such payment cannot be secured, the transaction will be cancelled. An account can be charged over-limit fees, late fees, interest, etc. at the discretion of the account lender. The invoicing module also provides interfaces for the system users to make payments and the account lenders to post payment receipts.
[0097] The agents module employs historical data and user input data to create and/or suggest various functions to buyers and sellers. Buyers and sellers can create customized agents based on their particular needs or use system default agents. Furthermore, agents can be turned on and off individually or as a group. A seller agent assists a seller maximize production efficiencies. The seller agent system uses information from the seller's previous offers and orders, such as the total capacity of product that went unpurchased for each open offer, to determine a price curve that is most likely to maximize profits for the seller. This agent also recommends the amount of time the seller should leave his offer open, the quantities the seller should offer, what options the seller should offer, the option costs, the shipping increments, and any other information necessary to allow for the greatest efficiencies and profits. Moreover, the seller can receive recommendations on which products should be offered as an aggregate offer and which products should be offered as a single offer. Offers can be automatically created for a seller on a regularly scheduled basis or alternatively, the seller agent can use the seller's inventory levels, forecast information, and open orders to determine when the next offer should be created. The seller can require that the offer be marked for review and manual activation; or the seller can allow the agent to create and activate the order without intervention.
[0098] The agent can also look at and make suggestions based on buying trends for a particular product. For example, the agent recognizes that one particular buyer always buys a product when it falls below a certain price. The agent can then recommend to the seller that the seller enter into a NTE contract price with that buyer, thus increasing the likelihood of more orders from that buyer. Furthermore, the system can track each time a buyer reviews a particular product and recommend a pricing strategy for the buyer with respect to that product. For example, a buyer reviews the price of a product at price m, price n, and price o, and places an order at price o. This information is stored whenever the buyer returns and looks at the product. Over time, the system will calculate every price the buyer ignored and accepted, and determine a customized curve for that buyer. The seller can instruct the system to reflect price increase a certain amount above the usually ordered price, or lock in a price at that point as well, creating a contract price variation in real time. As an additional example, the system recognizes that a buyer reviews a particular product three times without placing an order. The system, then, offers a coupon and/or discount to the buyer based upon such traffic patterns and products viewed in order to entice the buyer to purchase.
[0099] The seller agent can also be employed to analyze any open deal room activities. The seller can see the number of buyers that have entered the deal room and of those buyers, how many have actually placed an order. Thus, the seller agent can suggest how the seller can modify aspects of an open deal room in response to buyer activity. The seller can choose to close the deal room early, modify the available capacity, open a new deal room for the same product at a different pricing structure, or any other modification which allows the seller to best allocate his fixed resources. Seller agents can also display the seller's relative market share versus their competition with respect to a particular category, subcategory, or product in real time. Thus, the seller can choose to modify one or more open offers in order to increase his market share percentage.
[0100] Moreover, the seller agent can be used to suggest and/or create the seller's production and/or manufacturing schedule. The agent will take into consideration historical set-up times between different products (for example, how long it takes to change over a machine when switching from product A to product B as opposed to switching from product A to product C), run efficiencies associated with each machine, percent scrap associated with each machine, percent downtime for a machine, scheduled maintenance times, operator efficiencies, and any other applicable data, to determine which machines the products should run on and in what order. The agent can also recommend the best machine operator for the job and on which shifts the job should run. Moreover, the agent can use the seller's historical data and MRP information to forecast the seller's manufacturing plan by balancing anticipated demand with available capacity.
[0101] The seller agent is also capable of interacting with a buyer. Upon request from a buyer, the agent can create blanket prices, new aggregate offers, new single offers, add an order to existing offers, and/or reply to RFQs, RFOs, and RFPs. The goal of the agent is still to achieve the highest profit margin and manufacturing efficiencies for the seller. If the buyer terms and the seller terms are conflicting, the details will be forwarded to the seller for manual review and/or inform the buyer that the terms cannot be accepted. Shipping costs, carrying costs, transaction fees, and any other fees related to an offer and/or order are considered by the seller agent. Rewards and/or penalties are created based on time, the number of buyers on an offer to date, the quantity of product sold, the current price, and the number of cancellations, if any. The rewards can be in the form of a percent discount, flat discount, or bonus items. Penalties can be in the form of a percent markup, flat markup, or one time charge, and can be automatically given to any buyer that cancels an order or reduces the order quantity.
[0102] A buyer agent considers the needs of a buyer and assists in finding the best buy for a particular product. This agent looks at previous offer and order history for all sellers or specified sellers of a product and considers past offer percent aggregation, final price achieved, carrying cost vs. aggregation savings, transaction fees, any discounts that can be applied to a particular seller, and any other applicable factor to make a suggestion as to how and where the buyer should place an order. Current market information is also taken into consideration. Thus, the agent provides a comparison between the fair market value for a product and a reasonably anticipated price that can be achieved through the aggregation system.
[0103] Similar to the seller agent, the buyer agent interacts with sellers to create an aggregate order, a single order, a RFQ, a RFO, and/or a RFP. The agent can automatically place an order or provide a suggested order to the buyer and wait for manual interaction. The buyer can set up an automated process to place recurring orders, specifying maximum costs, quantity, required receipt dates, etc. The agent can also be configured to automatically place an order when the inventory level of a buyer falls below a predetermined level. Furthermore, the agent has the ability to analyze the buyer's production schedule and determine which products are needed and when in order to achieve the best buying opportunities. Shipping costs, carrying costs, lot sizes, seller quality, potential benefits of ordering early as opposed to waiting, and any other factor important in the buyer's decision making process are also considered by the buyer agent. The seller and buyer agents described above can perform the same functions with respect to a group of sellers or a group of buyers.
[0104] Agents are also used to assist the system host or administrator. An association agent is employed to analyze buyer behavior, including searches performed, orders placed, RFOs, RFQs, RFPs, and other similar actions to improve the product category structure. The association agent also generates aggregate sales information for deal rooms, categories, subcategories, products, etc. A content processing agent provides methods that intelligently associates content with products, categories, offers, and/or access points. This agent analyzes data on buyer and seller demographics, previous purchases, and other user behavior, as described above. A publisher/portal agent interfaces with the content processing agent and either suggests or automatically processes the addition and/or removal of content on the system.
[0105] All system users can make use of an exchange agent as it is concerned with activities such as, automation of billing, payment posting, and registration. This agent is also capable of overseeing the entire exchange process to identify any problem areas or system errors. For example, the exchange agent monitors deal room activities and if any manual intervention is necessary to troubleshoot the deal room, the exchange agent alerts the system administrator, host or deal room creator.
[0106] Although many aspect of the present invention have been largely described within the context of buying and selling goods; it is to be appreciated that buyers and sellers can sponsor deal rooms/transactions to aggregate selling of and purchasing of services, such as broadband, data storage, cell phones, electricity, gas, training programs, etc. For example, a service provider can contract with a group of buyers over a period of time to realize cost efficiencies tied to their usage and/or consumption. A pricing structure can be based upon time (seconds, days, months, years, etc.) and/or the quantity of usage and/or consumption over the specified time period and will be displayed in a deal room, similar to the examples above. A buyer can then visit the deal room at any point in time to track usage and/or consumption and also, view the current price, or billing schedule in real time. The buyer can view his/her individual usage and/or consumption, as well as, the usage and/or consumption of the entire buying group for that particular service. Furthermore, as above, the curves can vary for different buyers, based upon items such as rebate schedules, discounts, amount of usage and/or consumption, and length of contract between the buyer and the seller.
[0107] The system, as described above, is functional internationally. Thus, conversions are provided by the system for language, currency, units of measure, time and date, etc. in order to comply with a particular region's standard. Users can have the option of choosing which standards they prefer when registering with the system.
[0108] With reference to FIG. 15, an exemplary system 500 for implementing the invention includes a conventional personal or server computer 510, including a processing unit 520, a system memory 530, and a system bus 540 that couples various system components including the system memory 530 to the processing unit 520. The processing unit 520 can be any of various commercially available processors. Dual microprocessors and other multi-processor architectures also can be used as the processing unit 520.
[0109] The system bus 540 can be any of several types of bus structure including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of commercially available bus architectures. The system memory includes read only memory (ROM) 550 and random access memory (RAM) 560. A basic input/output system (BIOS), containing the basic routines that help to transfer information between elements within the computer 510, such as during start-up, is stored in ROM 550. The computer 510 further includes a hard disk drive 570, a magnetic disk drive 580, e.g., to read from or write to a removable disk 590, and an optical disk drive 600, e.g., for reading a CD-ROM disk 610 or to read from or write to other optical media. The hard disk drive 570, magnetic disk drive 580, and optical disk drive 600 are connected to the system bus 540 by a hard disk drive interface 620, a magnetic disk drive interface 630, and an optical drive interface 640, respectively. The drives and their associated computer-readable media provide nonvolatile storage of data, data structures, computer-executable instructions, etc. for the server computer 510. Although the description of computer-readable media above refers to a hard disk, a removable magnetic disk and a CD, it should be appreciated by those skilled in the art that other types of media which are readable by a computer, such as magnetic cassettes, flash memory cards, digital video disks, Bernoulli cartridges, and the like, can also be used in the exemplary operating environment. A number of program modules can be stored in the drives and RAM 560, including an operating system 650, one or more application programs 660, other program modules 670, and program data 680.
[0110] A user interface provides an interface through which the central server 25 can be directly programmed or accessed. The user interface can, for example, be an alphanumeric keyboard 690 and mouse 700. Other input devices (not shown) can include a microphone, joystick, game pad, satellite dish, scanner, or the like. These and other input devices are often connected to the processing unit 520 through a serial port interface 710 that is coupled to the system bus 540, but can be connected by other interfaces (not shown), such as a parallel port, game port or a universal serial bus (USB). A monitor 720 or other type of display device is also connected to the system bus 540 via an interface, such as a video adapter 730. In addition to the monitor 720, computers typically include other peripheral output devices (not shown), such as speakers and printers.
[0111] The computer 510 can operate in a networked environment using logical connections to one or more remote computers, such as a remote server or client computer 740. The remote computer 740 can be a workstation, a server computer, a router, a peer device or other common network node, and typically includes many or all of the elements described relative to the computer 510, although only a memory storage device 750 has been illustrated in FIG. 15. The logical connections depicted in FIG. 15 include a local area network (LAN) 760 and a wide area network (WAN) 770. Such networking environments are commonplace in offices, enterprise-wide computer networks, intranets and the Internet.
[0112] When used in a LAN networking environment, the computer 510 is connected to the local network 760 through a network interface or adapter 780. When used in a WAN networking environment, the server computer 520 typically includes a modem 790, or is connected to a communications server on the LAN 760, or has other means for establishing communications over the wide area network 770, such as the Internet. The modem 790, which can be internal or external, is connected to the system bus 540 via the serial port interface 710. In a networked environment, program modules 670 depicted relative to the computer 510, or portions thereof, can be stored in the remote memory storage device 750. It will be appreciated that the network connections shown are exemplary and other means of establishing a communications link between the computers can be used.
[0113] The present invention may be implemented via object oriented programming techniques. In this case each component of the system, could be an object in a software routine or a component within an object. Object oriented programming shifts the emphasis of software development away from function decomposition and towards the recognition of units of software called "objects" which encapsulate both data and functions. Object Oriented Programming (OOP) objects are software entities comprising data structures and operations on data. Together, these elements enable objects to model virtually any real-world entity in terms of its characteristics, represented by its data elements, and its behavior represented by its data manipulation functions. In this way, objects can model concrete things like people and computers, and they can model abstract concepts like numbers or geometrical concepts.
[0114] The benefit of object technology arises out of three basic principles: encapsulation, polymorphism and inheritance. Objects hide or encapsulate the internal structure of their data and the algorithms by which their functions work. Instead of exposing these implementation details, objects present interfaces that represent their abstractions cleanly with no extraneous information. Polymorphism takes encapsulation one step further--the idea being many shapes, one interface. A software component can make a request of another component without knowing exactly what that component is.
[0115] In particular, an object includes, and is characterized by, a set of data (e.g., attributes) and a set of operations (e.g., methods), that can operate on the data. Generally, an object's data is ideally changed only through the operation of the object's methods. Methods in an object are invoked by passing a message to the object (e.g., message passing). The message specifies a method name and an argument list. When the object receives the message, code associated with the named method is executed with the formal parameters of the method bound to the corresponding values in the argument list. Methods and message passing in OOP are analogous to procedures and procedure calls in procedure-oriented software environments.
[0116] However, while procedures operate to modify and return passed parameters, methods operate to modify the internal state of the associated objects (by modifying the data contained therein). The combination of data and methods in objects is called encapsulation. Encapsulation provides for the state of an object to only be changed by well-defined methods associated with the object. When the behavior of an object is confined to such well-defined locations and interfaces, changes (e.g., code modifications) in the object will have minimal impact on the other objects and elements in the system.
[0117] Each object is an instance of some class. A class includes a set of data attributes plus a set of allowable operations (e.g., methods) on the data attributes. As mentioned above, OOP supports inheritance--a class (called a subclass) may be derived from another class (called a base class, parent class, etc.), where the subclass inherits the data attributes and methods of the base class. The subclass may specialize the base class by adding code which overrides the data and/or methods of the base class, or which adds new data attributes and methods. Thus, inheritance represents a mechanism by which abstractions are made increasingly concrete as subclasses are created for greater levels of specialization.
[0118] The present invention can employ abstract classes, which are designs of sets of objects that collaborate to carry out a set of responsibilities. Frameworks are essentially groups of interconnected objects and classes that provide a prefabricated structure for a working application. It should also be appreciated that the PCM and the shared memory components could be implemented utilizing hardware and/or software, and all such variations are intended to fall within the appended claims included herein.
[0119] According to an exemplary aspect of the present invention, Java and CORBA (Common Object Request Broker Architecture) are employed to carry out the present invention. Java is an object-oriented, distributed, secure, architecture neutral language. Java provides for object-oriented design, which facilitates the clean definition of interfaces and makes it possible to provide reusable "software ICs." Java has an extensive library of routines for copying easily with TCP/IP protocols like HTTP and FTP. Java applications can open and access objects across a network via URLs with the same ease to which programmers are accustomed to accessing a local file system.
[0120] Furthermore, Java utilizes "references" in place of a pointer model and so eliminates the possibility of overwriting memory and corrupting data. Instead of pointer arithmetic that is employed in many conventional systems, the Java "virtual machine" mediates access to Java objects (attributes and methods) in a type-safe way. In addition, it is not possible to turn an arbitrary integer into a reference by casting (as would be the case in C and C++ programs). In so doing, Java enables the construction of virus-free, tamper-free systems. The changes to the semantics of references make it virtually impossible for applications to forge access to data structures or to access private data in objects that they do not have access to. As a result, most activities of viruses are precluded from corrupting a Java system.
[0121] Java affords for the support of applications on networks. Networks are composed of a variety of systems with a variety of CPU and operating system architectures. To enable a Java application to execute anywhere on the network, a compiler generates an architecture neutral object file format--the compiled code is executable on many processors, given the presence of the Java runtime system. Thus, Java is useful not only for networks but also for single system software distribution. In the present personal computer market, application writers have to produce versions of their applications that are compatible with the IBM PC and with the Apple Macintosh. However, with Java, the same version of the application runs on all platforms. The Java compiler accomplishes this by generating byte code instructions that have nothing to do with particular computer architecture. Rather, they are designed to be both easy to interpret on any machine and easily translated into native machine code on the fly.
[0122] Being architecture neutral, the "implementation dependent" aspects of the system are reduced or eliminated. The Java virtual machine (VM) can execute Java byte codes directly on any machine to which the VM has been ported. Since linking is a more incremental and lightweight process, the development process can be much more rapid and exploratory. As part of the byte code stream, more compile-time information is carried over and available at runtime.
[0123] Thus, the use of Java in the present invention provides a server to send programs over the network as easily as traditional servers send data. These programs can display and manipulate data on a client computer. The present invention through the use of Java supports execution on multiple platforms. That is the same programs can be run on substantially all computers--the same Java program can work on a Macintosh, a Windows machine, a Sun workstation, etc. To effect such multi-platform support, a network interface and a network browser (not shown) such as Netscape Navigator or Microsoft Internet Explorer may be used in at least one aspect of the present invention. It should be appreciated, however, that a Java stand-alone application might be constructed to achieve a substantially equivalent result. Although the present invention is described with respect to employing Java, it will be appreciated that any suitable programming language may be employed to carry out the present invention.
[0124] An Internet browser (e.g., Netscape, Microsoft Internet Explorer) is held within the memory of the client computer. The Internet Explorer enables a user to explore the Internet and view documents from the Internet. The Internet Explorer may include client programs for protocol handlers for different Internet protocols (e.g., HTTP, FTP and Gopher) to facilitate browsing using different protocols.
[0125] It is to be appreciated that any programming methodology and/or computer architecture suitable for carrying out the present invention may be employed and are intended to fall within the scope of the hereto appended claims.
[0126] Although the invention has been shown and described with respect to a certain preferred aspect or aspects, equivalent alterations and modifications will occur to others skilled in the art upon reading and understanding this specification and the annexed drawings. In particular regard to the various functions performed by the above described components (systems, assemblies, systems, etc.), the terms used to describe such components are intended to correspond, unless otherwise indicated, to any component which performs the specified function of the described component (i.e., that is functionally equivalent), even though not structurally equivalent to the disclosed structure which performs the function in the herein illustrated exemplary aspect or aspects of the invention. In addition, while a particular feature of the invention may have been described above with respect to only one of several aspects, such feature may be combined with one or more other features of the other aspects, as may be desired and advantageous for any given or particular application. Furthermore, to the extent that the term "includes" is used in either the detailed description or the claims, such term is intended to be inclusive in a manner similar to the term "comprising".
2009-12-10 System and method for discounted printing
2009-06-25 System and method for dynamic product pricing
2009-08-06 Non-credit account credit rating
2010-04-08 Method and apparatus for dynamic interchange pricing