The present invention relates to business to business market price control and management systems. More particularly, the present invention relates to systems and methods for price protection and price capping which reduces pricing risk in volatile markets.
There are major challenges in business to business (hereinafter “B2B”) markets which hinder the effectiveness of classical approaches to analyzing pricing impacts and thus optimization or guidance of pricing strategies. Classical approaches to price optimization typically rely upon databases of extensive transaction data which may then be modeled for demand. The effectiveness of classical price optimization approaches depends upon a rich transaction history where prices have changed, and consumer reactions to these price changes are recorded. Thus, classical price optimization approaches work best where there is a wide customer base and many products, such as in Business to Consumer (hereinafter “B2C”) settings.
Unlike B2C environments, in B2B markets a small number of customers represent the lion's share of the business. Managing the prices of these key customers is where most of the pricing opportunity lies.
One approach to analyzing B2B markets for the generation of pricing opportunity insights is the utilization of pricing protection and pricing cap terms. These contractual terms are well established mechanisms for hedging risk in pricing negotiations for long term contracts and/or for volatile markets. For sellers, pricing protection and cap terms are a source of significant price and margin leakage. For all parties involved, tracking and complying with price protection and price cap terms is a significant administrative burden.
Price protection keeps customer price unchanged for a protected duration of time. Price changes may be passed to the customer after the protected time period. In contrast, price caps are limits on the amplitude of a price change during a given time period. Price caps smooth our price volatility for the buyers.
Unfortunately, since the application of price cap terms and price protection terms is typically manually driven, these terms typically requires substantial administrative overhead and costs. Further, when prices are not altered as quickly as allowed under these terms, profitability may suffer. Lastly, all current methods of employing these terms do not allow for previewing the impact upon profits that pricing caps or protections may result in.
As such an urgent need exists for a system and method for price protection and price caps. Such systems and methods enable an improvement in profitability, reduction in pricing risk, and the ability to preview these terms prior to implementation.
The present invention discloses business to business market price control and management systems. More particularly, the present invention teaches systems and methods for analyzing the impact of price protection and price cap terms in an integrated price management system.
In some embodiments, the method includes negotiation of price protection and price cap terms. The price protection term limits when a price change can go into effect. A price cap term limits the degree of price change allowed in a given period. The negotiation of the price protection and the price cap term includes any of adding of a new term, editing of the term, ending of the term, renewal of the term, and workflow approval of the term. The price protection term includes a validity range, type (delayed, firm-trough, or rolling), and period. It may also include a base price, a periodic increase cap, a periodic decrease cap, an overall increase cap, an overall decrease cap, a periodic length, and an overall length.
Next the method enforces the price protection and price cap terms. This enforcement may include applying and/or overriding the term on a manual price change or upon a mass price change. These terms are then analyzed for price leakage by product, by deal, by customer and by sales representative. This analysis may include the generation of a waterfall diagram for the deal. Adjustments for all price protection and price cap terms are generated (a price protection adjustment and a price cap adjustment) and these adjustments are then applied to the waterfall.
Note that the various features of the present invention described above can be practiced alone or in combination. These and other features of the present invention will be described in more detail below in the detailed description of the invention and in conjunction with the following figures.
The present invention is illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings and in which like reference numerals refer to similar elements and in which:
The present invention will now be described in detail with reference to selected preferred embodiments thereof as illustrated in the accompanying drawings. In the following description, numerous specific details are set forth in order to provide a thorough understanding of the present invention. It will be apparent, however, to one skilled in the art, that the present invention may be practiced without some or all of these specific details. In other instances, well known process steps and/or structures have not been described in detail in order to not unnecessarily obscure the present invention. The features and advantages of the present invention may be better understood with reference to the drawings and discussions that follow.
As previously discussed, traditional techniques used to implement price protection or price cap terms are plagued by enormous administrative overhead, lost opportunity, and an inability to predict the impact of the terms over a set of deals.
In order to address these deficiencies, a system for price protection and price caps is presented. This system enables the reduction in pricing volatility, increased profitability via leakage reduction, and previewing impacts of pricing protection and cap terms.
The following description of some embodiments will be provided in relation to numerous subsections. The use of subsections, with headings, is intended to provide greater clarity and structure to the present invention. In no way are the subsections intended to limit or constrain the disclosure contained therein. Thus, disclosures in any one section are intended to apply to all other sections, as is applicable.
Price protection and pricing caps have particular benefit in the B2B environment in that B2B markets often rely upon thin margins, large volumes and are often subject to swings in prices for raw materials. Thus, a brief overview of such enterprise architecture will be provided in order to properly orient the reader.
To facilitate discussion,
The wealth of information contained in the various databases (104-120) however, is not “readable” by executive management teams due in part to accessibility and in part to volume. That is, even though the data in the various repositories may be related through a Relational Database Management System (RDMS), the task of gathering data from disparate sources can be complex or impossible depending on the organization and integration of legacy systems upon which these systems may be created. In one instance, all of the various sources may be linked to a Data Warehouse 132 by various connections 144. Typically, the data from the various sources is aggregated to reduce it to a manageable or human comprehensible size. Thus, price lists may contain average prices over some selected temporal interval. In this manner, the data may be reduced. However, with data reduction, individual transactions may be lost. Thus, CRM 124 and ERP 128 connections to an aggregated data source may not be viable
Analysts 136, on the other hand, may benefit from the aggregated data from a data warehouse. Thus, an analyst 136 may compare average pricing across several regions within a desired temporal interval and then condense that analysis into a report to an executive committee 140. An executive committee 140 may then, in turn, develop policies directed toward price structuring based on the analysis returned from an analyst 136. Those policies may then be returned to CRM 124 and ERP 128 entities to guide pricing activities via some communication channel 152 as determined by a particular enterprise.
An output is generated next at a step 210 based on the analysis of step 208. An output may be any operation that is intended to affect a condition of the desired system. In the above thermocouple example, a temperature may be read (e.g., input); compared against a set temperature (analysis); and affected by turning on or off a heating element depending on the comparison (output). Finally, the system loops back to the input and continues until the system, or a user terminates the process.
As pertains to the present disclosure,
The analysis of the data may then automatically generate a transaction and policy database 308. For example, analysis of a selected group of transactions residing in a historical database may generate a policy that requires or suggests a rebate for any sale in a given region. In this example, some kind of logical conclusion or best guess forecast may have determined that a rebate in a given region tends to stimulate more and better sales. This policy is thus guided by historical sales transactions over a desired metric—in this case, sales by region. The policy may then be used to generate logic that will then generate a transaction item.
In this manner, a price list of one or many items reflecting a calculated rebate may be automatically conformed to a given policy and stored for use by a sales force, for example. In some embodiments, policies are derived strictly from historical data. In other embodiments, policies may be generated ad hoc in order to test effects on pricing based hypothetical scenarios. In still other examples, executive committee(s) 320, who implements policies, may manually enter any number of policies relevant to a going concern. In this manner, policies may be both automatically and manually generated and introduced into the system.
After transactions are generated based on policies, the transactional portion of the database may be used to generate sales quotes by a sales force 316 in SAP 312, for example. SAP may then generate a sales invoice which may then, in turn, be used to further populate a historical database 304, which closes the loop. In some embodiments, sales invoices may be constrained to sales quotes generated by a transaction and policy database. That is, as an example, a sales quote formulated by a sales force 316 may require one or several levels of approval based on variance (or some other criteria) from policies stored in a transaction and policy database 308. In other embodiments, sales invoices are not constrained to sales quotes generated by a transaction and policy database.
By applying closed-loop logic to a price modeling environment, pricing advantages may be achieved. In one example, workflow efficiencies may be realized where “successful” sales are tracked and policies supporting activities corresponding to the “successful” sales are implemented. The determination of “successful” in terms of a sale may be defined in any of a number of ways including, for example, increased profitability or volume. In this manner, an enterprise allows real market results to drive sales' policy rather than basing policy solely on theoretical abstractions. In other examples, hypothetical changes to policies may be tested. Thus, for example, a suggested policy requiring a rebate for any sale over $1000.00 may be implemented to test the effect on overall margins without actually modifying existing policies. In that case, a suggested policy change may reveal insight into future sales transactions that result in no net effect on margins, or may reveal insight into areas that require further adjustment to preserve or increase margins.
Another advantage to the system is that policy may flow directly from input data in an efficient manner. Individual spreadsheets and analysis typically used in price modeling may no longer be necessary. Instead, executive committees have access to real-time data that is continually updated to reflect current sales and sales practices. Response to a given policy may be seen or inferred directly from a historical database and implemented directly on a transaction and policy database. Thus, temporal efficiencies are achieved.
In still other examples, a closed-loop system may be used to evaluate individual or grouped transactions as, for example, in a deal making context. That is, a salesperson may generate a quote for a given customer and submit that quote for comparison against a policy formulated transaction in a transaction and policy database. A comparison may reveal some basis upon which a quote may represent a profitable deal. In some embodiments, a deal indicator may be generated. A deal indicator may be a ratio of the quote against a composite index that generates a value between 0 and 1 corresponding to profitability. In this example, a ratio returning unity (i.e., 1) indicates a deal is in conformance with established policy. It may be appreciated that a ratio may be defined in any of a number of manners without departing from the present invention.
In other embodiments, a deal suggestion may be generated. A deal suggestion may provide a range of acceptable (i.e., profitable) pricing based on quote parameters. Thus, a quote having deal specific set parameters like, for example, a fixed shipping price may return a range of allowable rebates or a range of allowable sales discretion that account for a fixed shipping input. In still other embodiments, deal guidance may be provided. Deal guidance provides non-numeric suggestion for a given quote. Thus, deal guidance might, for example, return “acceptable deal,” or “unacceptable deal” in response to a given quote. Policy considerations underlie deal indicators, deal suggestions, and deal guidance. Availability of these comparisons allows a user to select a comparison best fitted to their sales techniques and preferences which may result in sales efficiencies.
An example embodiment of the present invention using a closed-loop system is next presented.
After the applicable policy is read at a step 412, a deal quote may then be compared against applicable policy at a step 416. As noted above, a comparison may reveal some basis upon which a quote may represent a profitable deal. Comparisons are then returned for review by a user at a step 420. As noted above, comparisons may include deal indicators, deal suggestions, and deal guidance. An advantage of returning a comparison is that a complex analysis may be reduced to a readily ascertainable form. In this case, a deal indicator may return a ratio; a deal suggestion may return an acceptable range of values; and deal guidance may return a non-numeric suggestion for a given deal. Thus, a deal maker may determine, at a glance, the acceptability based on policy of a given quote.
Once comparisons are returned at a step 420, a quote may be negotiated at a step 422 that may or may not incorporate any or all of those corresponding comparisons. In this manner, a salesperson negotiating a deal may flexibly structure a deal with confidence that the deal may be constrained to comparison parameters resulting in a profitable deal for an enterprise. In one embodiment, entering a negotiated transaction initiates a recalculation of comparisons. Thus, a deal maker may view real-time changes to a deal structure as a deal is being formed. This feature is particularly useful in that final negotiating point parameters may be expanded or contracted as a deal progresses providing a deal maker with an increasingly better defined negotiating position.
After a quote negotiation is complete at a step 422, the method determines whether approval is needed at a step 424. Approval, in this context, may be coupled with a portfolio manager. A portfolio manager may be utilized in an embodiment of the present invention to efficiently expedite approval of pending deals. Approval may include one or more levels depending on variance from an explicit or implicit policy. That is, for a particular deal that greatly varies from a policy, higher authority must approve of that particular deal. For example, a deal offering a rebate that is within policy limits may not require approval while a similar deal offering a rebate that falls outside of policy limits by, for example, 25% may need a sales manager or higher approval. Approval may be linked upward requiring executive officer approval in some cases. Portfolio management will be discussed in further detail below for
If approval is needed, then a deal must be approved at a step 428. The method then continues at a step 432 to generate a quote. If approval at a step 428 is not needed, the method continues at a step 432 to generate a quote. As can be appreciated, a quote may then be used to generate an invoice. However, an invoice may or may not match the quote upon which it is based. Rather, an invoice represents an actual sale. It is the data from an actual sale that continues to populate a historical database. The method then ends.
As noted above, a portfolio manager may efficiently expedite approval of pending deals. Enterprises, as a practical reality, have a mix of “good” and “bad” deals—good deals being defined as profitable. Evaluating deals in isolation may not maximize profits at an enterprise level. For example, industries having large fixed costs may accept a number of high volume “bad” deals in order to capture a number of low volume “good” deals resulting in an overall profit. Industries evaluating deals in isolation may not realize this benefit and thus may not be able to survive. Portfolio organization, therefore, assists, for example, sales managers maximize profitability for an enterprise by allowing those managers to view enterprise level effects of a deal or groups of deals.
As seen in
Customer price list portfolios comprise customer price list items grouped according to a desired criteria or criterion. For example, price lists may be organized by cost, by type, by distributor, by region, by function, and by any other selected parameter. In this manner, approval, as an example, for a group of items—items under $1.00 for example—may be required or ignored. By grouping items, approval processes may be retained only for selected key products. In one embodiment, one or more criteria may be utilized to organize customer price list portfolio. It can further be appreciated that many other combinations of groupings for portfolios are possible. Thus, for example, a sales manager portfolio may comprise: customer price list items 504; customer price list portfolios 512; or account manager portfolios 520 as indicated by multiple arrows in FIG. 5. Further, in this example, a customer price list portfolio 512 is a static portfolio. That is, a static portfolio does not change according to a formula or algorithm. Rather, a static portfolio is entered and modified manually. It may be appreciated that most, if not all, portfolios may either be static portfolios or dynamic portfolios.
Customer price list portfolios 512 may then be organized to generate an account manager portfolio 520. Account manager portfolios 520, in this example, comprise customer price list portfolios 512 grouped according to a desired criteria or criterion. Typically, accounts may be organized by named companies or individuals. In addition to organizing accounts by name, accounts may be organized by approval. That is, all approval accounts may be managed singly or in group thus facilitating policy implementation. For example, an account portfolio may be organized such that any account having a 12-month history of on-time transactions no longer needs approval so that approval is ignored. In this way, an on-time account may accrue a benefit of an expedited approval thus making transactions more efficient for both the sales person and the account. Further, in this example, an account manager portfolio is of the type—static portfolio. As noted above, a static portfolio does not automatically change according to a formula or algorithm.
Account portfolios 520 may be further organized to generate sales manager portfolios 528. Sales manager portfolios 528, in this example, comprise account manager portfolios 520 grouped according to a desired criteria or criterion. Typically, sales manager portfolios may be organized by named individuals or groups of individuals. In addition to organizing sales manager portfolios by name, sales manager portfolios may be organized by approval. As noted above, approval based portfolios may be managed singly or in group thus facilitating policy implementation. For example, a sales manager portfolio may be organized such that sales people with seniority no longer need approval for deals under a capped amount. In this way, sales people with more experience benefit from an expedited approval process since presumably more experienced sales people have a deeper understanding of company policies and priorities. In addition, as new policy is generated, approvals may be reinstated as a training measure so that policies may more effectively be incorporated into a workflow. In this example, a sales manager portfolio 528 is of the type—dynamic portfolio. Dynamic portfolios may be generated according to formula or algorithm. For example, a sales manager portfolio may be generated for all sales associates whose total billing exceeds a desired dollar amount. In this way, managers may creatively and efficiently differentiate productive and unproductive sales associates and may further apply varying levels of approval.
Now that the general structure of an example enterprise environment has been discussed, attention will now be focused upon the systems for pricing that incorporate price protection and price caps. To facilitate this discussion, attention is directed toward
The enterprise price system 610 receives information from an input data source 602. This input data typically includes prior transaction data, price listings, policy guidance and the like. The enterprise price system 610 can leverage this input data 602 to generate pricing data 620. Periodically, pricing data 620 may be updated in response to external cost changes and according to contractual terms. Likewise, the input database 602 may be updated by the enterprise price system 610 when new policy information is generated, new transaction data is available, etc.
The enterprise price system 610 is comprised of a deal negotiation module 712, a deal tracker 714, a price protection engine 716, and a price cap engine 718. The negotiation module 712 utilizes list price data and policy considerations found in the data 602, to assist a sales representative negotiate a deal scenario, as discussed previously. Once the deal has been negotiated and agreed upon, the deal tracker 714 is able to monitor the deal. Factors that may impact the deal are reviewed by the deal tracker 714, and may be applied to the deal invoices if they are in compliance with the deal's terms. Some of these factors, which involve changes in prices, may be first fed through the price protection engine 716 and price cap engine 718 in order to ensure that any price changes are implemented in a compliant manner.
In contrast,
Lastly,
Returning to
Continuing,
Like with price protection, the price cap engine 718 outputs a price cap waterfall adjustment 920 in order to ensure deals stay in compliance with their terms, and also can be utilized to preview the impact of a price cap term before it is implemented. By way of example,
As can be seen, the utilization of one or more price protection and price cap terms my hedge buyers from sudden price increases, and may hedge price fluctuation risk. These are important, and highly competitive, terms that often determine a buyer's willingness to accept a deal. Likewise, their impact on the deal is often not well understood, and improper compliance is a major source of leakage. By utilizing these enterprise pricing systems with price protection and price cap engines, leakage due to protection and cap compliance are minimized. Further, as previously mentioned, the impact of these terms may be previewed in order to assist in the formation of a deal.
The waterfall shown in
A general set of rules can be utilized to generate the price protection adjustment within the waterfall. These include the price protection cost is equal to post-protection price minus the pre-protection price. The pre-protection price is the price that the seller will charge the buyer if there were not price protection terms, and the post-protection price is the price that the buyer will pay, after enforcing the price protection terms. Pre-protection price and post-protection price correspond to the waterfall price point that is protected by price protection terms. A price point that is protected may differ from project to project. For example, some projects can protect ‘Customer Price’ on the deal while other projects may decide to protect ‘Market Price’. Protecting ‘Customer Price’ on the deal is the most common usage.
Accordingly, a waterfall representation will list the pre-protection price, followed by the price protection and cap adjustments, followed by the post-protection price. The pre-protection price can be edited directly on the deal (as an independent price) or it can sometimes be the calculated price point that is dependent on other price points and adjustments. For example, in the following scenario, Customer Price may be a user-edited field on the deal or it can be a calculated field on the deal that is dependent on Market Price and other adjustments between Market Price and Customer Price.
If the pre-protection price is editable, the price can change through one of the following actions: a user manually changes price for a given line item within a deal; a user uses ‘Mass Edit’ to change prices across multiple line items within a deal; or a user uses ‘Mass Price Change’ to change price across multiple deals. If the pre-protection price point is a calculated price (that is dependent on other factors), then price can also change as a result of re-pricing the deal/line item. Subsequently, if the product has price protection terms in a deal, the terms will be enforced when there is a price change on a deal for a given time period. Terms are enforced on the deal when the line item is in “Revising” status or when the line item is “Renewed” to carry forward terms, in some embodiments. Price protection terms will delay the price change to the buyer for the duration of price protection, as previously discussed.
In some specific embodiments, price change is identified by comparing the pre-protection price in a revision for the selected period against the last approved pre-protection price for the same period. Different time periods can have different prices for the same product within a deal. Price protection cost is calculated for each time period for a given product/line item of the deal.
For a given price change, the price change may need to be delayed across multiple periods to fully enforce price protection terms. This can happen when the duration of a given time period is shorter than the price protection delay period. E.g. there is a price change effective March 15 and product has 30 day price protection. If there is an existing time period with effective period between March 15 and March 31, then the time period is not sufficient to enforce the price protection terms fully and price change delay needs to be carried forward to the next period. If the price change is for a very short duration (shorter than the price protection duration), then the buyer with price protection may not get impacted by the price change at all. E.g. if the price change applies only for a 15 day period (e.g., Thanksgiving discount), but the buyer has 30 day price protection, buyer will not be impacted by the price change at all. Likewise, if there are consecutive price changes that are applicable for short durations (shorter than price protection delay), these price changes may not get passed to the buyer. Only price changes that will impact the buyer are the price changes that will remain effective for duration greater than the price protection duration.
In some cases the price change passes directly to the consumer immediately. These occur if the user overrides the price protection terms, if the price change is applied effective from the first day of the price protection period in case of “Firm Through” price protection type, and if the price protection needs to be enforced for only “Price Increase” and price change results in price reduction.
Similar to price protection, a general set of rules can be utilized to generate the price cap adjustment within the waterfall. These rules require that a price cap validity date range is defined, cap periods, periodic price increase/decrease caps, overall price cap period, and overall price increase/decrease caps. This allows for tiered price capping (say a change of $10 per month, but limited to a change of $20 per quarter, for example).
For overall price caps, irrespective of the number of times price changes during the year and irrespective of the amount of price change, maximum and minimum price for each period will be limited by maximum and minimum calculated limits. For the recurring overall cap such as annual cap, the calculation of “maximum and minimum price” for the consecutive periods is based on the ending “maximum and minimum price” for the previous period. For example, if baseline is $40 effective Jan. 1, 2012 to Dec. 31, 2013. Buyer negotiates Price Cap terms of +/−$2 Quarterly Cap and +/−$6 Annual Cap the maximum price for two years is calculated as: Q1−12=$42, Q2−12=$44, Q3−12=$46, Q4−12=$46, Q1−13=$48, Q2−13=$50, Q3−13=$52, Q4−13=$52. Likewise, the minimum price over two years is calculated as: Q1−12=$38, Q2−12=$36, Q3−12=$34, Q4−12=$34, Q1−13=$32, Q2−13=$30, Q3−13=$28, Q4−13=$28. If there are no periodic caps but only overall cap terms, then maximum and minimum price limits are calculated only based on overall cap limits
If the baseline period for 2012 and 2013 was different to begin with (due to agreed-upon terms, for example) then the maximum and minimum price limits for the 2013 will be based on baseline price at the beginning of 2013. For example, if baseline is $40 effective Jan. 1, 2012 to Dec. 31, 2012 and $45 effective Jan. 1, 2012 to Dec. 31, 2012. Buyer negotiates Price Cap terms of +/−$2 Quarterly Cap and +/−$6 Annual Cap the maximum price for two years is calculated as Q1−12=$42, Q2−12=$44, Q3−12=$46, Q4−12=$46, Q1−13=$47, Q2−13=$49, Q3−13=$51, Q4−13=$51. Likewise, the minimum price over the two years is calculated as Q1−12=$38, Q2−12=$36, Q3−12=$34, Q4−12=$34, Q1−13=$43, Q2−13=$41, Q3−13=$39, Q4−13=$39.
Baseline price to calculate maximum and minimum price for each period can change if the seller does a price change by overriding the price cap terms, price cap terms are re-negotiated (edited), and/or when agreement is renewed. In some embodiments, an overridden price will be used as baseline only in the next revision once the current revision in which price is overridden is approved. For example, if the seller makes a price change to $50 effective Q2 by overriding the price cap terms, then $40 will be the baseline price for Q1 and $50 will be the new baseline price from Q2−Q4.
In some embodiments, when the terms are re-negotiated/edited (in a given revision of the agreement), terms are enforced effective the next revision of the agreement (once the new terms are approved). There is no change in the base-line price used to calculate the maximum/minimum cap limits in this case.
In some embodiments, when the agreement is renewed, baseline price from the original agreement (at the time when agreement is renewed) is used as the new baseline price to calculate the maximum and minimum price change limits. Maximum and minimum price limits for the new renewed agreements Price cap periods will be calculated assuming the new periods are continuation of the original agreement time periods. Accordingly, all the rules that apply for baseline, maximum and minimum price limits for original agreement applies to the renewed agreements also.
Moreover, in some embodiments, if the entire price change cannot be passed to the customer during the validity of a given agreement, then price change is passed to the customer in the new agreement when the original agreement is renewed.
To further facilitate the discussion of some embodiments, attention will be turned to
Returning to
Returning to
Leakage analysis may be used to generate or refine polices that may be stored for future deal negotiations. After leakage is analyzed, the process ends. In addition to leakage analysis, the process may continue to actively review the deal invoices and ensure compliance with the price protection and price cap terms.
Now that the system architecture and processes have been disclosed in considerable detail, example screenshots shall be provided to help illustrate the process using relevant data for clarification purposes.
Processor 3422 is also coupled to a variety of input/output devices, such as Display 3404, Keyboard 3410, Mouse 3412 and Speakers 3430. In general, an input/output device may be any of: video displays, track balls, mice, keyboards, microphones, touch-sensitive displays, transducer card readers, magnetic or paper tape readers, tablets, styluses, voice or handwriting recognizers, biometrics readers, motion sensors, brain wave readers, or other computers. Processor 3422 optionally may be coupled to another computer or telecommunications network using Network Interface 3440. With such a Network Interface 3440, it is contemplated that the Processor 3422 might receive information from the network, or might output information to the network in the course of performing the above-described multi-merchant tokenization. Furthermore, method embodiments of the present invention may execute solely upon Processor 3422 or may execute over a network such as the Internet in conjunction with a remote CPU that shares a portion of the processing.
In addition, embodiments of the present invention further relate to computer storage products with a computer-readable medium that have computer code thereon for performing various computer-implemented operations. The media and computer code may be those specially designed and constructed for the purposes of the present invention, or they may be of the kind well known and available to those having skill in the computer software arts. Examples of computer-readable media include, but are not limited to: magnetic media such as hard disks, floppy disks, and magnetic tape; optical media such as CD-ROMs and holographic devices; magneto-optical media such as floptical disks; and hardware devices that are specially configured to store and execute program code, such as application-specific integrated circuits (ASICs), programmable logic devices (PLDs) and ROM and RAM devices. Examples of computer code include machine code, such as produced by a compiler, and files containing higher level code that are executed by a computer using an interpreter.
In sum, systems and methods for price protection and price caps are provided. While a number of specific examples have been provided to aid in the explanation of the present invention, it is intended that the given examples expand, rather than limit the scope of the invention. Although sub-section titles have been provided to aid in the description of the invention, these titles are merely illustrative and are not intended to limit the scope of the present invention.
While the system and methods has been described in functional terms, embodiments of the present invention may include entirely hardware, entirely software or some combination of the two. Additionally, manual performance of any of the methods disclosed is considered as disclosed by the present invention.
While this invention has been described in terms of several preferred embodiments, there are alterations, permutations, modifications and various substitute equivalents, which fall within the scope of this invention. It should also be noted that there are many alternative ways of implementing the methods and systems of the present invention. It is therefore intended that the following appended claims be interpreted as including all such alterations, permutations, modifications, and various substitute equivalents as fall within the true spirit and scope of the present invention.
This application is a continuation-in-part of U.S. patent application Ser. No. 13/907,860, filed on Jun. 1, 2013, by Niel Esary et al., entitled “System and Method for Organizing Price Modeling Data using Hierarchically Organized Portfolios”, currently pending, which is a continuation of U.S. patent application Ser. No. 10/857,262, filed on May 28, 2004, by Niel Esary et al., entitled “System and Method for Organizing Price Modeling Data using Hierarchically Organized Portfolios”, now U.S. Pat. No. 8,458,060, which applications are incorporated herein in their entirety by this reference. This application is related to co-pending application Ser. No. ______, filed Jul. 18, 2013, by Rajeev Bansal et al., entitled “System and Methods for Measuring Effectiveness for Strategic Mass Price Change” which application is incorporated herein in its entirety by this reference.
Number | Date | Country | |
---|---|---|---|
Parent | 10857262 | May 2004 | US |
Child | 13907860 | US |
Number | Date | Country | |
---|---|---|---|
Parent | 13907860 | Jun 2013 | US |
Child | 13945894 | US |