WO2008020307A2 - Système destiné à l'optimisation simultanée de l'économie d'une entreprise et de la valeur d'un client - Google Patents

Système destiné à l'optimisation simultanée de l'économie d'une entreprise et de la valeur d'un client Download PDF

Info

Publication number
WO2008020307A2
WO2008020307A2 PCT/IB2007/002547 IB2007002547W WO2008020307A2 WO 2008020307 A2 WO2008020307 A2 WO 2008020307A2 IB 2007002547 W IB2007002547 W IB 2007002547W WO 2008020307 A2 WO2008020307 A2 WO 2008020307A2
Authority
WO
WIPO (PCT)
Prior art keywords
customer
company
upgrade
option
product
Prior art date
Application number
PCT/IB2007/002547
Other languages
English (en)
Other versions
WO2008020307A3 (fr
Inventor
Sachin Goel
Original Assignee
Sachin Goel
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US11/474,115 external-priority patent/US7472080B2/en
Priority claimed from US11/506,451 external-priority patent/US7424449B2/en
Application filed by Sachin Goel filed Critical Sachin Goel
Priority to AU2007285460A priority Critical patent/AU2007285460A1/en
Publication of WO2008020307A2 publication Critical patent/WO2008020307A2/fr
Priority to ZA2010/00530A priority patent/ZA201000530B/en
Publication of WO2008020307A3 publication Critical patent/WO2008020307A3/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce

Definitions

  • This invention relates to a system and method for matching customer preferences with vendor products and services, and then dynamically managing the on-demand and optimally customized delivery of such business services or products. More particularly, it relates to methods and systems for customizing and optimizing a company's products and services to individual customers in a way that concurrently enhances customer value and overall business performance.
  • the customer is treated as an individual and sales terms are customized only when the cost of negotiation is justified — for very large transactions.
  • a customer might care more about cost one day and more about availability or delivery time or warranty if queried a few days or weeks later, to use some basic trade-offs as examples.
  • a company's product consists of many value elements, (explained later) all of which are bundled together to be sold as a single product. But, not every customer values all the aspects of a product equally or needs all. Every customer places a different value (which may be a function of time and situation) on each aspect of a product. With features bundled together in a product, companies end up either incurring costs to sell something to a customer that he does want or lose a customer because the extra undesired value elements forced the product price too high for the customer.
  • Advertisements and marketing campaigns can help to stimulate demand but not in the short term. In these situations, when it is difficult or not feasible to generate more demand, or even otherwise, a good solution is to upgrade the mix, or in other words, to upgrade the current customers to products rated higher than those bought currently. In the above example, there might be several customers who have bought B but would be willing to buy (or, rather switch to) A if A were offered to them at price and on terms that suit them.
  • An airline flight typically offers several levels of service through different cabins like coach (or economy), business and first. Most domestic flights in the United States have only two cabins, coach and first. There are some domestic flights that have either one cabin (by definition, all coach) or three cabins (coach, business and first). Airlines may use different names to refer to these cabins.
  • the idea behind creating different cabins in an airplane is to provide different levels of service to its passengers, ranging from regular (economic) service in the coach cabin to most luxurious (and most expensive) level of service in the first cabin.
  • the services differ in areas including, but not limited to, seating space and comfort, in-flight amenities and food service, priority- check-ins and luggage handling, reservation services and frequent flyer benefits.
  • the first class cabin is usually the most expensive and luxurious, followed by the business class cabin and the coach class cabin. For these reasons, most airline passengers value the first or business class travel experience more than the coach class travel experience. Some first cabin fares may be as high as 5-10 times a discounted coach fare for the same Itinerary.
  • Varying passenger value The relative value for travel in first class over coach varies from passenger to passenger. Even for the same passenger, the relative value changes from one trip to another (and even from one flight to another on the same trip) depending on trip duration, travel needs, budget, logistical factors and other personal or business constraints or needs.
  • Uncertain seat availability It is very uncertain and difficult to predict at the outset exactly how much demand exists for first cabin seats at the given travel prices. Consequently, it is difficult for an airline to know accurately the capacity sold and unsold until the last few minutes prior to departure. The problem becomes worse as several booked first cabin passengers do not finally turn up for the flight (so-called "no shows") or cancel their trips at the last minute.
  • Last-minute upgrade logistics The exact availability of first cabin seats can be known only minutes before departure, once the airline stops taking any additional passengers for the first cabin. At that point, however, an airline doesn't have much time to find potential passengers and process upgrades to fill the unused first cabin seats. A short delay in the departure of one flight can reverberate throughout the system and delay several other flights, leading to huge costs and customer ill-will (probably much more than the additional revenue earned from additional passengers).
  • a framework of systems and methods are shown that allows businesses to determine their customers' preferences (implicitly or explicitly, in advance or in quasi- real-time) for flexibility in purchasing products and to dynamically integrate these preferences with internal company operations to concurrently maximize value for both customers (individually or as a group, their purchase utilities) and the company (i.e., its profitability).
  • a business determines a customer's preferences (flexibilities and associated relative utilities) in great detail and in real-time or quasi-real-time from direct inquiries (explicitly) and/or past interaction (implicitly), before or while engaging in a sales transaction.
  • those preferences are then integrated with internal company operations and economics (costs, capacities, constraints, inventories, etc.). Values are then determined for product or service options to be offered to the customer based on integrated (i.e., aggregated) customer preferences and company economics. On one hand, these value options allow companies to reward or charge customers for their flexibilities with respect to preferences.
  • these value options enable companies to maximize their revenues and/or profitability by unbundling their products and services, and best matching the offerings with a customer's expressed preference/cost tradeoffs. Since the customer gets something matching more closely his or her preferences than a "one size fits all" or small, fixed choice approach, customer purchase utility is increased and the customer is pleased to receive a product or service tailored to the customer's preferences. A company may charge for the purchase of some product options. So, customers pay for options made available to them and the company does not have to invest in offering everyone features that only a minority of customers want.
  • a system for collecting such customer preference information and pricing corresponding options and presenting options to the customer, receiving customer choices, and completing a sale may be implemented over the global Internet and its World Wide Web.
  • other communication media may be used, as well, for all or part of the system or steps.
  • customer information may be taken over the phone or in person or via any other means.
  • a sale can similarly be completed by telephone or in person.
  • the system may also provide after-sale follow-up and implement execution of option terms purchased by the customer.
  • An engine may be provided for this purpose.
  • the engine may be a processor(s) that is programmed to execute a suitable event response algorithm.
  • Each procedure for event response (related to a purchased option) may be custom programmed to implement the desired operations of the company or there may be provided a library of procedures generally applicable to an industry.
  • the library procedures may be used by the company with or without customization.
  • the detection of the contingency triggering the procedure may in some instances be made automatic, as by interconnection with the company's information management systems, or it may be externally or manually supplied.
  • the UPO VOF can concurrently create benefits for at least two of the company, the customers and any other entity involved or any combination thereof.
  • One aspect of the invention consists of a computer-implemented system and method for a company to provide options on products where in a computer-implemented service is operated that allows a customer to receive a conditional option for an upgrade and recording the information pertaining to said option in a data store.
  • a computer-implemented system may upgrade the customer if at least one condition on said option is satisfied and the company receives the payment. The customer's acceptance of said option may confer upon the company a right to enforce a payment obligation on the customer if said customer receives upgrade and recording the information pertaining to said upgrade in a data store.
  • Another aspect of the invention consists of a computer-implemented system and method for a company to sell products
  • a computer-implemented service is operated to allow a company to sell at least one product that allows a customer to receive a conditional upgrade and to record the information pertaining to said conditional upgrade in a data store wherein not separately identifying a price for the inclusion of said conditional upgrade within the total product price and operating a system, whereby a processor processes the information in the data store, and allows the company to upgrade the customer if at least one condition on said conditional upgrade is satisfied, and the company receives the payment for said upgrade.
  • the system confers upon the company the right to enforce said payment on the customer.
  • the information pertaining to said upgrade is recorded in a data store.
  • the Product Price may also include a price for an upgrade, which may be not separately identified within the total Product Price.
  • Another aspect of the invention consists of a computer-implemented system and method for a company
  • a computer implemented system allows a customer to receive a conditional option for an upgrade wherein the customer is required to relinquish at least one right.
  • the information pertaining to said option and relinquishment is recorded in a data store.
  • a processor may process the information in the data store, and may allow the company to upgrade the customer if at least one condition on the opportunity is satisfied.
  • the computer implemented system may confer upon the company the right to enforce said relinquishment on the customer and record the information pertaining to said upgrade in a data store.
  • Said relinquishment may include relinquishment of one or more rights.
  • the customer may relinquish right for one or more products.
  • the products may or may not be related to the products of the company.
  • the rights may or may not related to the rights conferred by the product. There may be a payment condition apart from relinquishment of said right.
  • the company may present various rights and require the customers to pick a specified number of rights, thereby relinquishing other rights and in lieu of the relinquished rights, the customer may receive a conditional option for an upgrade.
  • Another aspect of the invention consists of a computer-implemented system and method for a company, where in data is stored in a data structure for a customer who may be awarded one or more upgrades. Data may include a value assigned to each potential upgrade the company may realize if the customer receives said upgrade.
  • a processor is operated to receive and process said data to determine from among all or substantially all possible combinations of potential upgrade awards to said set of customers and upgrades are awarded to a said set of customers along with storing the information pertaining to said upgrade in a data store.
  • the company may detect the occurrence of an event associated with potential generation of upgrade availability, executing one or more event response algorithms, which may determine at least a number or type of upgrade or upgrades available for a product, or both number and type; may determine a subset of customers possessing conditional options making them eligible to receive an available upgrade; and may allocate upgrade offers among the customers in said subset.
  • Another aspect of the invention consists of a computer-implemented system and method for a company to provide a data store including relevant information regarding products, to operate a computer-implemented system that defines customer preferences regarding at least one upgrade ranking and recording the information pertaining to said preferences in a data store.
  • a computer-implemented system is operated that enables use of said preferences to upgrade at least one customer and to optimize value for at least one of customers, company and an entity other than said company.
  • the preferences may be utilized in delivering at least one option to a customer to get upgrade on n of m selected products, where n is less than m and operating a system to define each of said n Chosen Products, whereby after each of said n Chosen Products is defined by the company, the customer can utilize said Chosen Product and recording the information pertaining to at least one of said option or said defined products in a data store.
  • the preferences may be defined implicitly.
  • the preferences may be also be defined explicitly by either of the customer or the company or both.
  • the preferences may be taken at any time during the purchase of the product, prior to and/or after the product has been purchased.
  • the optimization of value may be for at least one customer other than the customers whose preferences are received.
  • the optimization may also include concurrent optimization of value for at least two of the customers, said company and at least one entity other than said company.
  • the preferences may be used for assigning ranking between different products.
  • the ranking may be explicit and/or implicit.
  • the ranking may also be based on already established or well known ranking or as per industry norms.
  • the company and/or the customer may explicitly and/or implicitly assign ranking.
  • the company may establish, in advance of making the upgrade award, a ranking of attributes applicable to the product and defining upgrade possibilities.
  • the company may also establish, in advance of delivering the option, a list of attributes applicable to the product and may associate therewith rankings, expressed expressly or implicitly by the customer.
  • Another aspect of the invention consists of a computer-implemented system and method for a company to operate a computer-implemented system that delivers a first option to at least a first customer to utilize up to n of m selected products for said first customer, where n is less than or equal to m and delivers a second option to at least a second customer to utilize up to k of p selected products, where k is less than or equal to p.
  • the system records the information pertaining to said options in a data store and a system is operated to define each of the k chosen products, whereby after each of the k chosen products is defined, said second customer can utilize said chosen product and also operates a system wherein a company defines t chosen product(s) for said first customer after each of said k chosen product is defined, comprising after each of said t products is defined, said first customer can be upgraded to said defined product, where t is less than or equal to n.
  • the information pertaining to said defined as well as upgraded products is recorded in a data store. It is another aspect of the invention that the company may not be the seller of any of said products. In another implementation, the company may not be the seller of any of said options.
  • the company may offer at least one of said options.
  • the company may operate at least one of said systems.
  • at least one entity other than said company operates at least one of said systems.
  • the systems for first and second options may operate independently.
  • the systems for first and second options may also operate in conjunction with each other.
  • the above mentioned acts may be performed for a multiplicity of at least one of said first or second customers and further includes combining together at least one of each of said first and second customers to formulate at least one group with at least one complementary set of options.
  • at least one of said m or p products may be available for use by the company.
  • At least one of said m or p products may also be available for use by an entity other than said company.
  • the company or an entity other than said company may define, at one or more times, at least one of said k Chosen Products.
  • the second customer may also define, at one or more times, at least one of said k Chosen Products.
  • the company or an entity other than said company may select, at one or more times, at least one of said m or p products.
  • the first customer may select, one or more times, at least one of said m products and/or the second customer may select, one or more times, at least one of said p products.
  • At least one of the company or an entity other than said company delivers to at least one of said first or second customers, at one or more times, one or more terms and conditions associated with the first or second options, respectively.
  • the company may receive from at least one of the first or second customers, at one or more times, an indication of one or more terms and conditions associated with said first or second options, respectively.
  • said first or second customers may be same.
  • none of the options may include a notification deadline condition.
  • at least one of said options may include at least one notification deadline condition.
  • the notification deadline condition may be different for said first and second options.
  • the company may allocate at least one product to at least one entity other than said company, and said entity delivers at least one of said first or second options on at least one of said allocated products. It is another aspect of the invention that at least one of said n or k Chosen Products may include at least one product other than said m or p products, respectively.
  • No payment transaction may be executed between the company and any of said first or second customer in connection with the option and the selected products.
  • at least one payment transaction may be executed between the company and at least one of said first or second customer and said payment transaction may include a soft value.
  • at least one of said m or k products may be released for reuse by the company.
  • Another aspect of the invention consists of a computer-implemented system and method for a company to provide a data store containing data representing, with respect to at least one product, at least one option offered by a company, and to operate a computer-implemented system that delivers to a customer an option to upgrade on up to n of m selected products, where n is less than m.
  • a computer-implemented system is operated to define each of the n chosen products, whereby after each of the n chosen products is defined, the customer can be upgraded to said chosen product.
  • the information pertaining to said defined products is recorded in a data store.
  • Yet another aspect of the invention consists of a computer-implemented system and method for a company to provide options on products, where in a computer- implemented service allows a customer to receive an option to utilize each of the m (which is greater than 2) selected products including at least one practically constrained product, wherein said m products are selected in the course of related transaction(s) and it will not be possible for the customer to utilize all said m products due to said practical constraints.
  • the information pertaining to said option is recorded in a data store.
  • the practical constraints may include the timing constraints and/or the location constraints.
  • the related transaction may be at least one transaction.
  • the customer may not be able to utilize only one product due to practical constraints.
  • the customer may not be able to utilize more than one product due to practical constraints.
  • Another aspect of the invention consists of a computer-implemented system and method for a company to provide options on products where in a computer-implemented service allows a customer to receive an option to upgrade on up to n of m selected products, where m is greater than or equal to 2 and n is less than m and recording the information pertaining to said option in a data store.
  • a computer-implemented system is operated, whereby the company may allow the customer to utilize all the m products provided specified conditions are satisfied which may include that the products are received in the course of related transaction(s), and there is at least one payment transaction between the company and the customer related to said products wherein such payment is made after said option has been granted.
  • the information pertaining to said option is recorded in a data store.
  • the customer may select said m products together.
  • the customer may also select the products prior to utilizing the penultimate product.
  • the company may reserve the right to limit the customer to n products on a stated notification date.
  • the payment transaction may consists of one or more transactions apart from the initial interaction if said customer utilizes all the awarded products.
  • delivering said option may occur in relation to a customer purchasing at least one product.
  • the product purchase may be for a product other than a product for which an option is delivered.
  • Said delivery of option may be an electronic delivery of option.
  • at least one of said m products may be available for use by the company.
  • At least one of said m products may be available for use by an entity other than said company.
  • Said m products may be selected in at least one transaction.
  • the company mentioned above may include more than one entity.
  • the company may select at least one of said m products for the customer.
  • at least one of said m products may be from more than one company.
  • the n products may be defined in at least one transaction and it may be possible that said n products may be defined after the option is delivered to the customer.
  • the n Chosen Products may include at least one product other than said m products.
  • at least one of said m products is released for reuse by the company.
  • the Released Product may be utilized to generate revenue or other value without reusing said Released Product.
  • the customer may purchase a set of conditional options which may be utilized for future needs. Said set may be a time based set and/or a value based set.
  • At least one of the company or an entity other than said company may deliver to the customer, at one or more times, one or more terms and conditions associated with the option.
  • Another aspect of the invention may include that the company may receive from the customer, at one or more times, an indication of one or more terms and conditions associated with the option.
  • the company may define, at one or more times, one or more of the n Chosen Products.
  • the customer may also define, at one or more times, one or more of the n Chosen Products.
  • the company may identify to the customer at least one eligible product for the option and allows the customer to select at least one of said m products from the eligible products.
  • the option may confer on the customer the right to enforce the upgrade, provided at least one condition on the option has been satisfied.
  • the option may also confer on an entity other than said company the right to enforce the upgrade, provided at least one condition on the option has been satisfied.
  • the customer may be given a choice of conditional options to choose, prior to the company delivering at least one conditional option to the customer.
  • the company may present to a customer said option requiring the customer to indicate the price the customer will pay for the upgrade if offered.
  • the option may require the customer to accept the upgrade offer.
  • at least one condition on option may be the availability of an upgrade.
  • the upgrade may be an upgrade of at least one product.
  • the upgrade may upgrade the customer to only one Up Product.
  • the upgrade may upgrade the customer, upon availability, to any of more than one Up Products.
  • the customer may be upgraded at any time before the utilization of the product.
  • One available Up Product may lead to more than one upgrade.
  • At least one upgrade may re-assign a customer a different product from the original product assignment.
  • a standby customer may be assigned to a standby product as a Base-Product from which an upgrade is possible to a product having availability.
  • a non-paying customer may be assigned to a non-revenue product as a Base-Product from which an upgrade is possible to another product having availability.
  • the company may perform optimization for at least one category of freebie. However, in other implementations of the invention, the company may not perform optimization for any category of freebie.
  • the payment transaction may be executed between the company and the customer in connection with the option and the selected products.
  • at least one payment transaction may be executed between the company and the customer and said payment transaction may include a soft value.
  • the payment may also include cost savings or other benefits to the company.
  • the customer may also commit to pay the company for upgrade when the company awards an upgrade to the customer and such commitment may include pre- authorizing the company for said payment.
  • the payment may include a payment at the time company delivers said option.
  • the company may or may not exercise its right of enforcing the payment obligation upon the customer.
  • the customer may become entitled to the option to get an upgrade by making a payment, at least in part, when purchasing said product.
  • the option may not include a notification deadline condition. However, in different implementations of the UPO VOF, the option may include at least one notification deadline condition. If the customer fails to satisfy a stated notification deadline condition, at least one of said m products may be defined as the Chosen Product.
  • the company may upgrade the customer without any subsequent interaction after delivering the option. However, in different implementations, the company may upgrade the customer after at least one subsequent interaction.
  • said entity may sell back at least one allocated product to said company or to at least one entity other than the company or both.
  • the entity other than said company may deliver the option on at least one of said allocated products.
  • the allocation of products may include at least one condition requiring return of one or more products.
  • the above said systems may be same and at least one company operates at least one of said systems.
  • the customer may interact with the service via at least one web site and/or the customer may interact with the system assisted by at least one operator.
  • the customer may also interact with another entity operating the system other than the company.
  • a UPO VOF may be implemented in any industry, for example, let's consider an airline industry.
  • the UPO VOF in the airline industry consists of a computer-implemented system and method for an airline to provide options on flights where in a computer-implemented service is operated that provides a data store containing data representing, with respect to at least one flight, at least one option offered by an airline and operating a computer-implemented system that delivers to a customer an option to get upgrade on up to n of m selected flights, where n is less than m. Information is recorded in a data store, pertaining to said option.
  • a system is operated to define each of the n Chosen Flights, whereby after each of the n Chosen Flights is defined, the customer can utilize to said Chosen Flight.
  • the information pertaining to said defined flights is recorded in a data store.
  • UPO VOF UPO VOF in the airline industry consists of a computer- implemented system and method for an airline to provide options on flights
  • a computer-implemented service allows a customer to receive a conditional option for an upgrade that may impose a payment obligation on the customer if the airline upgrades said customer and recording the information pertaining to said option in a data store.
  • a computer-implemented service is operated that allows the airline to upgrade the customer if at least one condition on said option is satisfied and the airline receives payment for said upgrade.
  • the customer's acceptance of said option confers upon the airline a right to enforce said payment obligation on the customer if said customer receives upgrade and the information pertaining to said upgrade is recorded in a data store.
  • the total number of customers may be ugraded in one or more cabins and/or in one or more flights and both.
  • the upgrade may include an upgrade to a non-stop flight.
  • the upgrade may also be for a portion of the duration of a flight.
  • Yet another example of the UPO VOF in the airline industry consists of a computer-implemented system and method for an airline to sell tickets
  • a computer-implemented service allows the airline to sell at least one designated fare class that allows a customer to receive a conditional upgrade and the information pertaining to said conditional upgrade is recorded in a data store wherein not separately identifying a price for the inclusion of said conditional upgrade within the total ticket price.
  • a computer-implemented system is operated whereby a processor may process the information in the data store, and allows the airline to upgrade the customer if at least one condition on said conditional upgrade is satisfied and the airline receives the payment for said upgrade.
  • the customer accepting the ticket of said fare class confers upon the airline the right to enforce said payment on the customer.
  • the information pertaining to said upgrade is recorded in a data store.
  • the designated fare class may be an existing fare class and/or may be a fare class newly created for this or other purposes.
  • a computer-implemented system is operated that delivers a first option to at least a "first customer” to utilize up to n of m selected flights for said first customer, where n is less than or equal to m; operating a system that delivers a second option to at least a "second customer” to utilize up to k of p selected flights, where k is less than or equal to p; recording the information pertaining to said options in a data store; operating a system to define each of the k Chosen Flights, whereby after each of the k Chosen Flights is defined, said "second customer” can utilize said Chosen Flight; operating a system wherein an airline defines t Chosen Flight(s) for said "first customer” after each of said k Chosen Flights is defined, wherein after each of said t flights
  • One aspect of the invention consists of a computer-implemented system to provide options on products, that comprises of a data store containing data representing, with respect to at least one product, at least one option offered by a company, a server with which a customer may interact for at least said option, a server that is being adapted to receive inputs for at least said option and to search the data store for eligibility of products for at least said option, at least one output device to output from the server the search results, a server that is being adapted to receive at least one decision of the customer about the acceptance of at least one of said search results and an event optimizer system receiving data at least pertaining to said acceptance, and in response to the occurrence of at least one disruption event selected from a set of at least one potential events, executing a corresponding event response algorithm, wherein at least one of the servers or the event optimizer system concurrently optimizes a value for at least two entities.
  • Another aspect of the invention consists of a computer-implemented method to provide options on products that comprises of providing a data store containing data representing, with respect to at least one product, at least one option offered by a company, operating a server with which a customer may interact for at least said option, operating a server to receive inputs for at least said option and to search the data store for eligibility of products for at least said option, displaying the search results, receiving at least one decision of the customer about the acceptance of at least one of said search results and operating an event optimizer system to receive data at least pertaining to said acceptance, and in response to the occurrence of at least one disruption event selected from a set of at least one potential events, execute a corresponding event response algorithm, wherein at least one of the servers or the event optimizer system concurrently optimizes a value for at least two entities.
  • the company mentioned above may include more than one entity.
  • the company may be a seller of at least said product.
  • the company may not be a seller of said product.
  • the company may operate at least one of said servers or the system.
  • an entity other than company may also operate at least one of said servers or the system.
  • said optimization may be performed for at least said company and customer.
  • said optimization may be performed for at least one of said company and customer involved in said transaction and another entity.
  • the said interaction may include a transaction with respect to at least one product.
  • the said data pertaining to at least one of demand, preferences and associated relative utilities of the customer may be defined, implicitly or explicitly, at least during said interaction.
  • said data pertaining to at least said company and customer may be integrated by at least one of the servers or the system to concurrently optimize value for at least two entities.
  • said search may include searching for at least one product or option based on said inputs.
  • said search identifies results at least after taking into account business economics of at least the company offering said product or option.
  • said search results may include at least one option or product.
  • said search results may include a product which includes an option and for which a price for the inclusion of said option is not separately identifiable within the total product price.
  • no payment transaction is executed.
  • at least one payment transaction may be executed during said transaction.
  • said payment transaction may include a soft value.
  • said option may be related to a product other than the product obtained by the customer. It is an aspect of the invention that said transaction may include more than one transaction.
  • at least one value option framework may be created by collecting data on customer preferences and then assigning prices based on airline business factors.
  • the price of an option may be assigned when the option is offered to the customer.
  • offering the value options may include selectively offering value options after taking into account airline business conditions. Another aspect may include wherein said option may offer a customer multiple options from which to select for personalized in the event of a disruption.
  • one may only select those options that satisfy preferences expressed by the customer and further includes, selecting only those options that satisfy utilities expressed by the customer.
  • the company may be, for example, an airline, a hotel, a car rental company, travel company and the product may, for example, correspond to a flight (and/or cabin), a room, a Car and a Travel Package, respectively.
  • the UPO VOF may be implemented in any industry including, but not limited to, the airline, hotel, car rental, travel, media entertainment, cruise, real estate, financial services, automobile sales, computer and other retail sales.
  • Another aspect of the invention is that one or more aspects or elements or examples mentioned herein of the invention may be combined in one or more ways to utilize the invention.
  • Fig. 1 is a diagrammatic illustration, in a high-level flow chart, of a method of achieving the optionally customized sale of goods or services as taught herein;
  • Fig. 2 is a block diagram of a system as taught herein for practicing the discussed method
  • Fig. 3 is a flow chart of a method to create a value option framework showing collection of industry and customer dynamics
  • Fig. 4 and 5 are diagrammatic illustrations of the relationship between overall product utility and contributions as perceived by a customer
  • Fig. 6 is a diagrammatic illustration of the perceived utilities of a product by four customers
  • Fig. 7 is a flow chart illustrating optimization of a value option framework
  • Fig. 8 is a partially-diagrammatic, partially-flow diagram representing the steps of a process for creating a value option framework
  • Fig. 9 is a diagrammatic representation of the generic structure of a value option framework
  • Fig. 10 is a diagrammatic illustration showing creation of a value option framework indicating how cost, revenue, utility and service functions
  • Fig. 11 is a flow chart of a process to implement value option framework
  • Fig. 12 is a diagrammatic illustration showing generally how an event is processed by the system and method shown, to fulfill a company's obligations to its customers as shown herein, delivering optimized results to the company and the customers;
  • Fig. 13 is a flow chart expanding Act 1280 of Fig. 12;
  • Fig. 13A is a diagrammatic illustration of various business models
  • Fig. 13B is a diagrammatic illustration of one of ways of interaction between the customer and the OA and/or the company;
  • Fig. 13C is a diagrammatic illustration of one of the network system to implement the system
  • Fig. 13D is a diagrammatic illustration of implementation of one of the stages of a value option framework as a system
  • Fig. 13E is a diagrammatic illustration of implementation of event optimizer stage of a value option framework as a system
  • Fig. 14 is a diagrammatic illustration of an exemplary set of value segments and their value elements related to the UPO VOF;
  • Fig. 15 is a diagrammatic illustration of company economic factors and mapping between customer dynamics and company economic factors in relation to UPO VOF;
  • Fig. 16 is a partially-diagrammatic, partially-flow diagram representing the structure for creating a UPO Value Option Framework
  • Fig. 17 is a flowchart of an algorithm to create UPO options for a given number of entities
  • Fig. 18 is a diagrammatic illustration, in a high level flowchart, of a process for UPO VOF implementation
  • Fig. 19 is a flowchart that expands Act 100 of Fig. 18, illustrating a high level algorithm for the "Sequential Get UPO" process at the Set level;
  • Fig. 20 is a flowchart that expands Act 120 of Fig. 19, illustrating an algorithm to search for UPO Products (algorithm at the Product level);
  • Fig. 21 is a flowchart that expands Act 120 of Fig. 19, illustrating an algorithm to search for UPO Product Sets (algorithm at the Set level);
  • Fig. 22 is a flowchart of an algorithm for the "Concurrent Get UPO" process, an alternative process to Fig. 19;
  • Fig. 23 is a diagrammatic illustration, in a high level flowchart, of an algorithm for the UPO Exercise process in UPO VOF implementation
  • Fig. 24 is a flowchart that expands Act 120 of Fig. 23, illustrating an algorithm to create "Upgrade List” for a given set of entities and a list of upgrade-enabled customers;
  • Fig. 25 is a flowchart that expands Act 110 of Fig. 23, illustrating an algorithm to create types of upgrade combinations for a given set of products;
  • Fig. 26 is a flowchart that expands Act 130 of Fig. 23, illustrating an algorithm for the "Upgrade Award” process in UPO VOF implementation;
  • Fig. 27 is a flowchart illustrating the Buy_N process for a Product Set of a company that has implemented the UPO VOF;
  • Fig. 28 is a flowchart that expands Act 1 10 of Fig. 27, illustrating an algorithm for the Buy N search process
  • Fig. 29 is a flowchart that expands Act 150 of Fig. 28, illustrating an algorithm to create capacity using the Upgrade U algorithm;
  • Fig. 30 is a flowchart that expands Act 150 of Fig. 29, provides an algorithmic illustration for the Upgrade_U algorithm;
  • Fig. 31 is a flow chart illustrating an example of an algorithm of Customer Notification process
  • Fig. 32 is a flowchart illustrating an example of an algorithm to implement grouping of A and U type of customers
  • Fig. 33 is a flowchart illustrating an example of an algorithm to implement grouping of U and Y type of customers;
  • Fig. 34 is a diagrammatic illustration of an exemplary set of value segments and their value elements related to the UFO VOF in context of an airline industry;
  • Fig. 35 is a diagrammatic illustration of airline economic factors and mapping between customer dynamics and airline economic factors in relation to UFO VOF;
  • Fig. 36 is a partially-diagrammatic, partially- flow diagram representing the structure for creating a UFO Value Option Framework in context of an airline industry;
  • Fig. 37 is a diagrammatic representation of different UFO instances that may be created in case of three flights;
  • Fig. 38 is a flowchart of an algorithm to create UPO options for a given number of entities
  • Fig. 39 is a diagrammatic illustration, in a high level flowchart, of a process for UFO VOF implementation in an airline industry
  • Fig. 40, 41, 42 and 43 are simulated screen shots of web screens illustrating how the Initial Transaction for UFO may take place between an airline and a customer;
  • Fig. 44 is a flowchart that expands Act 100 of Fig. 39, illustrating a high level algorithm for the "Sequential Get UFO" process;
  • Fig. 45 is a flowchart that expands Act 120 of Fig. 44, illustrating an algorithm to search for UFO Flight Segments;
  • Fig. 46 is a flowchart of an algorithm for the "Concurrent Get UFO” process, an alternative process to Fig. 45;
  • Fig. 47 is a flowchart illustrating the Buy_N process for a Flight Segment of an airline that has implemented the UFO VOF;
  • Fig. 48 is a flowchart that expands Act 110 of Fig. 47, illustrating an algorithm for the Buy_N search process
  • Fig. 49 is a flowchart that expands Act 150 of Fig. 48, illustrating an algorithm to create capacity using the Upgrade_U algorithm;
  • Fig. 50 is a flowchart that expands Act 150 of Fig. 49, provides an algorithmic illustration for the Upgrade U algorithm;
  • Fig. 51 is a flow chart illustrating an example of an algorithm of Customer Notification process in an airline industry
  • Fig. 52 is a flowchart illustrating an example of an algorithm to implement grouping of A and U type of customers in an airline industry
  • Fig. 53 is a flowchart illustrating an example of an algorithm to implement grouping of U and Y type of customers in an airline industry
  • Fig. 54 is a diagrammatic illustration of an exemplary set of value segments and their value elements related to the UTO VOF in context of an airline industry;
  • Fig. 55 is a diagrammatic illustration of airline economic factors and mapping between customer dynamics and airline economic factors in relation to UTO VOF;
  • Fig. 56 is a partially-diagrammatic, partial Iy- flow diagram representing the structure for creating a UTO Value Option Framework in context of an airline industry;
  • Fig. 57 is a diagrammatic representation of different UTO instances that may be created for a flight with three cabins;
  • Fig. 58 is a flowchart of an algorithm to create UTO options for a given number of entities
  • Fig. 59 is a diagrammatic illustration, in a high level flowchart, of a process for UTO VOF implementation in an airline industry;
  • Fig. 60, 61 and 62 are simulated screen shots of web screens illustrating how the Initial Transaction for UTO may take place between an airline and a customer;
  • Fig. 63 is a flowchart that expands Act 100 of Fig. 59, illustrating a high level algorithm for the "Sequential Get UTO" process;
  • Fig. 64 is a flowchart that expands Act 120 of Fig. 63, illustrating an algorithm to search for UTO value options at Leg level;
  • Fig. 65 is a flowchart of an algorithm for the "Concurrent Get UTO" process, an alternative process to Fig. 63 ;
  • Fig. 66 is a diagrammatic illustration, in a high level flowchart, of an algorithm for the UTO Exercise process in UTO VOF implementation
  • Fig. 67 is a flowchart that expands Act 120 of Fig. 66, illustrating an algorithm to create "Upgrade List" for a given set of entities and a list of upgrade-enabled customers;
  • Fig. 68 is a flowchart that expands Act 110 of Fig. 66, illustrating an algorithm to create types of upgrade combinations for a given set of flight cabins
  • Fig. 69 is a flowchart that expands Act 130 of Fig. 66, illustrating an algorithm for the "Upgrade Award" process in UTO VOF implementation
  • Fig. 70, 71 and 72 are diagrammatic illustrations of a practical example of the UTO Exercise process in UTO VOF implementation, displaying the inputs to the process and types of upgrade combinations in Fig. 70, the generated Upgrade List in Fig. 71 and list of Upgrade awards in Fig. 72;
  • Fig. 73 is a flow chart illustrating an example of an algorithm of Customer Notification process in an airline industry
  • Fig. 74 is a diagrammatic illustration of an exemplary set of value segments and their value elements related to the URO VOF in context of the hotel industry;
  • Fig. 75 is a diagrammatic illustration of hotel economic factors and mapping between customer dynamics and hotel economic factors in relation to URO VOF;
  • Fig. 76 is a partially-diagrammatic, partially-flow diagram representing the structure for creating a URO Value Option Framework in context of the hotel industry;
  • Fig. 77 is a diagrammatic representation of different URO instances that may be created for with three different rooms;
  • Fig. 78 is a flowchart of an algorithm to create URO options for a given number of entities
  • Fig. 79 is a diagrammatic illustration, in a high level flowchart, of a process for URO VOF implementation in the hotel industry;
  • Fig. 80, 81 and 82 are simulated screen shots of web screens illustrating how the Initial Transaction for URO may take place between a hotel and a customer;
  • Fig. 83 is a flowchart that expands Act 100 of Fig. 79, illustrating a high level algorithm for the "Sequential Get URO" process;
  • Fig. 84 is a flowchart that expands Act 120 of Fig. 83, illustrating an algorithm to search for URO Room Sets;
  • Fig. 85 is a flowchart of an algorithm for the "Concurrent Get URO" process, an alternative process to Fig. 83;
  • Fig. 86 is a diagrammatic illustration, in a high level flowchart, of an algorithm for the URO Exercise process in URO VOF implementation;
  • Fig. 87 is a flowchart that expands Act 120 of Fig. 86, illustrating an algorithm to create "Upgrade List" for a given set of entities and a list of upgrade-enabled customers;
  • Fig. 88 is a flowchart that expands Act 110 of Fig. 86, illustrating an algorithm to create types of upgrade combinations for a given set of rooms;
  • Fig. 89 is a flowchart that expands Act 130 of Fig. 86, illustrating an algorithm for the "Upgrade Award" process in URO VOF implementation;
  • Fig. 90, 91 and 92 are diagrammatic illustrations of a practical example of the URO Exercise process in URO VOF implementation, displaying the inputs to the process and types of upgrade combinations in Fig. 90, the generated Upgrade List in Fig. 91 and list of Upgrade awards in Fig. 92;
  • Fig. 93 is a flowchart illustrating the Buy_N process for a Room Set of a hotel that has implemented the URO VOF;
  • Fig. 94 is a flowchart that expands Act 110 of Fig. 93, illustrating an algorithm for the Buy_N search process
  • Fig. 95 is a flowchart that expands Act 150 of Fig. 94, illustrating an algorithm to create capacity using the Upgrade U algorithm;
  • Fig. 96 is a flowchart that expands Act 150 of Fig. 95, provides an algorithmic illustration for the Upgrade U algorithm;
  • Fig. 97 is a flow chart illustrating an example of an algorithm of Customer Notification process in the hotel industry
  • Fig. 98 is a flowchart illustrating an example of an algorithm to implement grouping of A and U type of customers in the hotel industry
  • Fig. 99 is a flowchart illustrating an example of an algorithm to implement grouping of U and Y type of customers in the hotel industry
  • Fig. 100 is a diagrammatic illustration of an exemplary set of value segments and their value elements related to the STS VOF;
  • Fig. 101 is a diagrammatic illustration of company economic factors and mapping between customer dynamics and company economic factors in relation to STS VOF;
  • Fig. 102 is a partially-diagrammatic, partially-flow diagram representing the structure for creating a STS Value Option Framework
  • Fig. 103 is a diagrammatic illustration showing creation of a value option framework indicating cost, revenue, utility and service functions relating to the STS VOF;
  • Fig. 104 is a simulated screen shot of web screen illustrating how the Initial Transaction for STS VOF may take place between an airline and a customer;
  • Fig. 105 is a counter part to Fig. 12 dealing specifically with the STS VOF implementation in the airline industry for flight cancellation and rebooking;
  • the method and system taught herein connect customers directly to a manufacturer or service provider and the rest of the supply chain, herein referred to as "channel partners.”
  • the term “manufacturer” is intended to include vendors of services as well as vendor of goods.
  • the manufacturer and channel partners will be collectively referred to as a "company” or “companies” and all of those terms will be appreciated to include sole proprietorships, partnerships, corporations, option aggregators or any other legal entity or combination thereof.
  • entity includes the singular and plural and will include individual(s), group of individuals, company, companies, sole proprietorships, partnerships, corporations or any other legal entity or combination or consortium thereof.
  • Option Aggregator or “Option Aggregators” or “OA” may include, but is not limited to, a company, a group and/or consortium of companies, more than one entity, any entity formed by company(s) (whether or not solely for this purpose), any other entity or any combination thereof that offers options on its own products and/or other company products.
  • airline or “airlines” includes, but is not limited to, an airline, an airline's business partner, an entity which deals with an airline or an airline's business partner, a travel agent, an Option Aggregator and any entity forming a part of the chain of commerce related to airline and/or travel industry, or any combination of any two or more of the above.
  • hotel or “hotels” includes, but is not limited to, hotel, apartment hotel, bed and breakfast, capsule hotel, caravanserai, casa particular, flophouse, choultry, garden hotels, condo-hotel, holiday cottage, hostel, ice hotel, trailer home, roadhouse, ryokan, turbaza, boarding house, bungalow, condominium, dharamshalas, dormitory, inn, resorts, a group or chain of hotels, a hotel's business partner, an entity which deals with a hotel or a hotel's business partner, a travel agent, an Option Aggregator, any entity forming a part of the chain of commerce related to hotel and/or travel industry, or any combination of any two or more of the above.
  • a hotel may be referred to as an entity that provides space for hire.
  • car rental company or “car rental companies” includes, but is not limited to, a car rental company, a group of car rental companies, a car rental company's business partner, an entity which deals with a car rental company or a car rental company's business partner, a travel agent, an Option Aggregator, any entity forming a part of the chain of commerce related to car rental industry and/or travel industry, or any combination of any two or more of the above.
  • travelling company or “travel companies” includes, but is not limited to, any entity forming a part of the chain of commerce related to the travel industry, a company, a group of companies, a travel company's business partner, an entity which deals with a travel company or a travel company's business partner, a travel agent, an Option Aggregator, or any combination of any two or more of the above.
  • Process refers to a product or service provided by a manufacturer or an entity.
  • the term “Products” or “Product” may also refer to "Product Set” or “Product Sets” or “Product Order” or “Product Orders” or any combination thereof, as and when the context requires and are used interchangeably.
  • customer here implies an entity buying or entering into a contract to buy a company's product or service.
  • optimize is not intended to require achievement of a mathematical minimum or maximum, but to refer to enhancement.
  • flight refers to a single flight, a group of flights, flights with zero or more stops or any combination of the above.
  • the term “Flights” or “Flight” may also sometime refer to one or more seats on said flight(s), when the context requires.
  • the terms “flight” and “seat” are interchangeable as the context requires.
  • the term “Flight” or “Flights” may also refer to a Flight Leg, a Flight Segment, an Itinerary, any combination of two or more flights or any combination of the above, when the context requires.
  • cabin refers to a compartment or a section in an airplane (or similar travel medium, such as a train) with its specific seating arrangement and/or in-flight amenities that are offered to customers while traveling in that cabin.
  • Room in context of the hotel industry refers to a single room, a room with zero or more facilities and/or services, only facilities or services offered by the hotel.
  • a room may be referred to as a given space for a given duration of time and for a given set of one or more associated services or characteristics or any combination thereof.
  • the term “Room” and “seat” are interchangeable, as and when the context requires. For example, one may refer to a reserved seat for a show in a hotel as a reserved room.
  • Car or “Cars” refers to any means of transportation including, but not limited to, cars, vans, mini-vans, buses, trucks, trailers, pick-up trucks, scooters, motor cycles, bikes, trains, trams, boats, ships, steamers, jets, helicopters and so on, any variation or model of said means of transportation and/or services, equipments associated with it or any combination(s) thereof, for a given time unit.
  • Travel Package or “Travel Packages” or “Package” or “Packages” refers to combination of one or more services related to travel including, but not limited to, transportation, accommodation, various facilities and so forth.
  • Transportation may include, but is not limited to, travel by flight, train, bus, car, cruise, boat, steamer and so forth.
  • Accommodation may include, but is not limited to, stay in hotel or any location and services associated with it.
  • Said “various facilities” may include, but are not limited to, sight seeing, city tours, river-rafting, mountaineering, para-gliding, food and so forth.
  • An Itinerary refers to a list of flights included in a single travel trip of a customer.
  • An Itinerary may consist of one or more "Segments" (defined below).
  • An Itinerary can be a one-way trip (one Segment), a round-trip (two Segments) or a multi- city trip (two or more Segments).
  • a round-trip Itinerary has two Segments back and forth between two places (e.g., a trip from A to B and then back from B to A).
  • a One- Way Itinerary has only one Segment (such as travel from A to B).
  • a Multi-City Itinerary refers to an Itinerary with two or more Segments across two or more places (e.g., a trip from A to B and then from B to C).
  • Flight Segment refers to a part of an Itinerary between a customer's intended origin and destination.
  • a Segment may consist of one or more "Flight Legs".
  • the term “Flight Leg” (or “Leg”, in short) is the most fundamental unit of an Itinerary and is defined by a single takeoff and landing of a flight. In a round- trip Itinerary (A to B and B to A), there may be 2 Flight Legs from A to B (customer flies from A to C and then C to B, two connecting flights), and similarly two Flight Legs from B to A (customer flies from B to D and then D to A, two connecting flights).
  • the term "Product Price” of a Product refers to the price a company would charge for a Product in the absence of implementation of said VOFs on said product.
  • Ticket Price in reference to one or more VOFs
  • Room Price refers to the price that an airline would charge in the absence of implementation of said VOFs on said flight.
  • Room Price in reference to one or more VOFs refers to the price that a hotel would charge for a room in the absence of implementation of said VOFs on said room.
  • Car Rental Price of a car (in reference to one or more VOFs) refers to the price that a car rental company would charge for a car in the absence of implementation of said VOFs on said car.
  • Traffic Package Price of a travel package (in reference to one or more VOFs) refers to the price that a travel company would charge for a travel package in the absence of implementation of said VOFs on said travel package.
  • transaction here implies to do, to carry or to conduct an agreement or exchange.
  • the exchange may or may not involve a price in terms of monetary or non- monetary value from customer side.
  • the parties participating in the transaction may have obligation(s) from various terms and conditions.
  • transaction may also imply an action or activity involving two or more parties that reciprocally affect or influence each other.
  • queule refers to the characteristics of a flight including, but not limited to, airline related parameters, departure/arrival parameters, service and other miscellaneous parameters.
  • the airline related parameters may include, but are not limited to, operating carrier entity (i.e, the airline that operates the flight), marketing carrier (an airline that sells the flight), any other carrier or intra/inter-carrier flight groups associated with the flight or any combination of the above.
  • the departure/arrival parameters may include, but are not limited to, an airport and its location (city, state, country), date and time, seasonality, weather and other operational conditions, number of stops/connections, and so forth.
  • the service and other miscellaneous parameters may include, but are not limited to, type of aircraft, flight duration, in-flight or other services such as number of cabins, types of seats, meal selection, check-in and luggage options, airport lounges and other facilities, and so forth.
  • the car rental company related parameters may include, but are not limited to, operating car rental company entity (i.e. the car rental company that operates the car), owner of the car, marketing car rental company (a car rental company that rents out the car), any other car rental company or intra/inter-car rental company groups associated with the car rental or any combination of the above.
  • the pick-up/drop-off parameters may include, but are not limited to, a pick-up/drop-off location (area or street, landmark, city, state, country), date and time, seasonality and other operational conditions, and so forth.
  • the service and other miscellaneous parameters may include, but are not limited to, type of car, car rental duration, or other services, car rental company services such as insurance, additional driver, child seats, and other equipments, and so forth.
  • the term "schedule”, in context of a travel package refers to the characteristics of a travel package including, but not limited to, travel company related parameters, start/end date time, service and other miscellaneous parameters including travel company related parameters.
  • the travel company related parameters may include, but are not limited to, operating travel company (i.e. the travel company that operates the package), marketing travel company (a travel company that sells the travel package), any other travel company or intra/inter-travel company groups associated with the package or any combination of the above.
  • the start/end parameters may include, but are not limited to, a destination location (area or street, landmark, city, state, country), date and time, seasonality, weather and other operational conditions, and so forth.
  • the service and other miscellaneous parameters may include, but are not limited to, type of flight, car, room, cruise, travel duration, or other services, travel company services such as insurance, flight services, car special equipments, hotel services, cruise services, other facilities, and so forth.
  • related transactions refers to one or more transactions that are related to each other.
  • the successful interaction between the participants may happen through a number of transactions in sequence, where each of the transactions in the sequence may (or may not) depend upon the outcome of the previous transaction, and this may create a chain of "related transactions".
  • at least one transaction in a set of related transactions must be related to all the other transactions.
  • the connection or reference between the transactions may be direct or indirect and/or implicit or explicit.
  • the related transactions may be contingent to each other or rely or require the aid of the other to support.
  • the transactions may be fully and/or partly related to each other to be construed as related transactions.
  • the price of a transaction may be modified if the customer has already bought a product in a previous transaction, which makes the two transaction related to each other.
  • the customer is given availability in a flight since he or she has already purchased a ticket in another flight; which makes both the transactions related to each other.
  • the transactions may become related transaction in one or more transactions.
  • the term "default” here implies a situation or condition that turns up in the absence of active intervention from the users in a contract. In such situation, a particular setting or value (termed “Default Settings” or "Default Value”) for one/more exchange variables is/are assigned automatically. These Default Settings/Default Values remain in effect unless intervened.
  • Payment here implies the act of paying or the state of being paid.
  • Payment may also refer to a transfer of something of value to compensate for products or services that have been, or will be, received. Payment may be made in cash, on credit or any other consideration. The payment may have monetary or non-monetary (soft) value. The payment can be from company and/or any other entity to customer or from customer to company and/or any other entity or both.
  • significant period of time here implies a time period that is large enough with respect to the total utility time for the customer that it may affect the behavior of a transaction.
  • anytime or “any other time” refers to any point of time that lies between a time period starting from the initial interaction of a customer with an airline (for any ticket purchase or any other event) for a particular journey and ending when said customer completes said journey and/or any other journey related to said journey.
  • selected refers to, without limitation, selecting, selecting and purchasing, purchasing, defining, choosing, expressing a preference or any combination thereof.
  • receiving refers to, without limitation, purchasing, utilizing, receiving for free, receiving without requirement of a physical delivery or any combination thereof.
  • said terms (related to "select) may also refer to, without limitation, receiving, purchasing or any combination thereof (including any grammatical forms of these terms such as noun, adjective, verb etc.). Said terms (related to "select”) are used interchangeably as and when the context requires.
  • the phrase "selecting a Product” for option purposes includes selecting one or more products within the same or a different product level (or a section or compartment) within the same product category.
  • the phrase “selecting a Room” for option purposes includes, but not limited to, selecting one or more rooms within the same or a different hotel or any combination thereof.
  • the phrase “selecting a Car” or “renting a Car” or “purchasing a Car” for option purposes includes, but not limited to, selecting one or more cars or car types or equipments associated with the car from the same or a different car rental company or any combination thereof.
  • the phrase “selecting a Travel Package” for option purposes includes, but not limited to, selecting one or more travel packages within the same or a different travel company or any combination thereof.
  • a Set refers to a collection of Products and are used interchangeably.
  • a Set may have one or more Products.
  • a Flight Segment is equivalent to a Set and each Leg within a Segment is equivalent to a Product.
  • a Segment may consist of one or more Flight Legs (Products).
  • a Room Set is equivalent to a Set and each Room Product within a Room Set is equivalent to a Product.
  • a Room Set may consist of one or more Room Products.
  • a Car Set is equivalent to a Set and each Car Product within a Car Set is equivalent to a Car Product.
  • a Car Set may consist of one or more Car Products.
  • a Travel Package Set is equivalent to a Set and each Travel Package Product within a Travel Package Set is equivalent to a Product.
  • a Travel Package Set may consist of one or more Travel Package Products.
  • a company may (or may not) impose a restriction that all the Products of a Set must be used together unless a change is made to the Order (described later).
  • the term "Order" may consist of one or more Sets, where each Set may consist of one or more Products.
  • an Itinerary is equivalent to an Order.
  • a Room Order is equivalent to an Order.
  • a Car Order is equivalent to an Order.
  • a Travel Package Order is equivalent to an Order.
  • IFS Initial Flight Segment
  • IFS flight Segment purchased by a customer. For example, consider an itinerary with two Segments, A to B and B to A. Each of the two segments is referred to as IFS.
  • IFS In context of hotel industry, "Initial Room Set” is equivalent to IPS.
  • IFS In context of hotel industry, “Initial Room Set” is equivalent to IPS.
  • Itial Room Set In context of hotel industry, “Initial Room Set” (or IRS, in short) refers to a Room Set purchased by a customer. In context of car rental industry, “Initial Car Set” is equivalent to IPS.
  • Initial Car Set (or ICS, in short) refers to a Car Set purchased by a customer. In context of travel industry, “Initial Travel Package Set” is equivalent to IPS.
  • Initial Travel Package Set (or ITS, in short) refers to a Travel Package Set purchased by a customer.
  • Option Product Set refers to a Set received by the customer as part of a UPO.
  • OFS is equivalent to OPS.
  • Option Flight Segment refers to a flight Segment selected as part of a UFO (and/or UTO) option on a given IFS in the context of the airline industry. There can be one or more OFS for a specific IFS.
  • Option Room Set refers to a Room Set selected as part of a URO option on a given IRS in the context of the hotel industry. There can be one or more ORS for a specific IRS.
  • Option Car Set refers to a Car Set selected as part of a UCO option on a given ICS in the context of the car rental industry. There can be one or more OCS for a specific ICS.
  • Option Travel Package Set refers to a Travel Package Set selected as part of a UTPO option on a given ITS in the context of the travel industry. There can be one or more OTS for a specific ITS.
  • U refers to a type of customer who has received a UPO. In the context of UPO VOF, the term “N” refers to the type of customer who has not received a UPO.
  • U Status refers to the status of a U customer in a given IPS or OPSs. U status are of two types: Accounted (Ua) and Awaiting (Uw).
  • Awaiting_Set When a U customer is not counted as holding (or using or blocking) a unit of capacity of the Products in a Set (IPS or OPS), his/her status is called Awaiting with respect to that Set and each of the Products in the set.
  • the corresponding Set is termed Awaiting_Set for the U customer and the customer is Uw with respect to that Awaiting_Set and Products included in this Set.
  • a customer may (or may not) be accounted to only one Set and is awaiting in the rest of the related Sets.
  • Upgrade_U refers to a recursive algorithm for which the necessary parameters are defined as follows: input parameters: Collection of ParentU (or COPU, in short), Collection of Parent Product (or COPP, in short), Caller U, Initiator Product, InitiatorJU, Benefit; and output parameters: a U_Series collection. Definition of all the parameters are given below.
  • Collection of ParentU or COPU, in short
  • COPP Collection of Parent Product
  • Caller U Initiator Product
  • InitiatorJU Benefit
  • output parameters a U_Series collection. Definition of all the parameters are given below.
  • Collection of ParentU (or COPU, in short) refers to a collection of Ua customers for which the Upgrade_U algorithm has already been called within a cascade of Upgrade_U calls. The corresponding customer is referred to as ParentU.
  • Collection of Parent Product refers to a collection of Products for which the Upgrade U algorithm has already been called within a cascade of Upgrade U calls to generate Capacity.
  • the corresponding Product is called Parent Product.
  • Caller U refers to the Ua customer, which is to be upgraded from its Accounted Set to Awaiting_Set by calling the Upgrade U algorithm.
  • Inciator Product refers to the Product from which Caller_U is to be upgraded by using the Upgrade U algorithm to generate capacity.
  • Initiator U refers to a customer whose wants to capture a unit of capacity of the Initiator Product, and thus, derives the need to create its capacity by using the Upgrade_U algorithm to upgrade the Caller U from the Initiator Product.
  • ChildU refers to a U customer who was upgraded in the cascading route of Upgrade_U calls.
  • a ChildU element consists of the following entities: Collection of Initiator, Initial_Accounted_Set, Final_Accounted_Set and Cost of ChildU.
  • Collection of Initiator refers to a collection of one or more members, where each member in the collection consists of the following: Initiator_Product and Initiator_U, where said Initiator U derives a need to create capacity in said Initiator Product.
  • Initiator_Product and Initiator_U, where said Initiator U derives a need to create capacity in said Initiator Product.
  • Initial_Accounted_Set refers to the Set where the ChildU is accounted before he or she is upgraded in the Upgrade_U process.
  • Final_Accounted_Set refers to the Set where the ChildU is accounted after being upgraded by the Upgrade_U algorithm from the Initial_Accounted_Set.
  • Cost of ChildU refers to the cost to upgrade the current ChildU from its Initial Accounted Set to the Final_Accounted_Set.
  • Series_Element refers to a feasible route generated when UpgradeJU is called to upgrade a Caller U from its Accounted Set to its Awaiting_Set.
  • a Series_Element consists of the following entities: Collection of ChildU (COCU), Collection of End Product (COEP); and Cost of the Series_Element (CSE).
  • Collection of ChildU refers to a collection of all the ChildU, which have been upgraded by the Upgrade_U algorithm within a Series_Element.
  • End Product refers to a Product with enough units of EAC to accommodate a Caller U.
  • the cascading route of Upgrade_U reaches one end when it approaches an End_Product.
  • An End_Product consists of AC and Collection of Ua (or COUA, in short).
  • COUA includes all the Ua that are accounted in the End_Product (includes existing Ua and ChildU that are upgraded to End_Product).
  • Collection of End_Product refers to a collection of all the End_Products involved within a Series_Element
  • CSE Cost of the Series_Element
  • Series refers to the total of CCU of all the ChildU associated with a Series Element.
  • Series refers to a collection of the Series Elements.
  • U Series refers to a collection of the Series Elements, which is returned as output by the Upgrade U algorithm.
  • P Series Tefers to a collection of the Series Elements at the Product level. A P Series collection is obtained from the U_Series collections of all Ua in the Product.
  • S Series refers to a collection of the Series_Elements at the Set level.
  • processor includes, without limitation, any one or more devices for processing information.
  • a processor may include a distributed processing mechanism.
  • a processor may include hardware, software, or combinations thereof; general purpose digital computing elements and special purpose digital computing elements and likewise included.
  • a single processor may perform numerous functions and may be considered a separate processor when implementing each function.
  • database and “data store” may have been used interchangeably as and when the context requires and both may refer to any form of storing the data, including but not limited to, storing the data in a structured form, storing the data in an unstructured form and so forth.
  • Fig. 1 there is shown a high-level flow-chart style diagram of a method to achieve the optimally customized sale of products or services to "close the gap.” It involves the following steps or acts:
  • Act 1.110 certain inputs are captured, including customer dynamics and important value segments, their demand, preferences, flexibilities and associated relative utilities.
  • Company economics and important economic factors such as, for example, costs, capacities and constraints are captured in Act 1.120.
  • the customer information from Act 1.1 10 and the company economics from Act 1.120 are then in Act 1.130, "integrated” in a way that will permit optimization of value for both the company (e.g., its profitability) and customers (e.g., their individual and collective purchase utilities).
  • Act 1.140 value options are formulated that permit the capturing of individual customer preferences in way that can be used in the optimal customization of the sale process illustrated. These same steps can be used in one or more permutations or combinations or iteratively.
  • the system is operated and the method of Fig. 1 is executed to (1) to dynamically interact with the customers to determine detailed customer demand for the product and options, (2) receive a real-time assessment of company economics, i.e., capacities, constraints, and costs, (3) optimize across demands and preferences of all customers, and company economics, and (4) formulate value options for customers.
  • company economics i.e., capacities, constraints, and costs
  • a company has to obtain information about customer demand and preferences before (and/or during) a purchase, in a structured manner that can be easily understood and translated into satisfaction for customers and also can be used to optimize internal operations for companies. This data can then be integrated with the company's internal resources and capacities to enhance and improve its operations.
  • a company can "optimally customize" its products and processes to enhance the value for customers, while simultaneously maximizing its business profitability. Customers also benefit from the fact that they spend less time researching products, can be assured that their priorities are known in case of change or contingency events occurring, can enhance their purchased products/services and get more perceived value for their purchase price.
  • a block diagram of a typical system for implementing this methodology is shown in Fig. 2.
  • the data for driving the system, from both the customer side and the company side, is stored in a database shown in Box 2.210 (or multiple databases), which may be of any suitable database design and may be a commercially available database product configured for this application.
  • the "heart" of the system is a platform, typically one or more servers, shown in Box 2.220, which provides the processing capability to implement three modules, shown in Boxes 2.230, 2.240 and 2.250.
  • the Customer Engine module (shown in Box 2.230) controls the interfacing with the customer via whatever media are selected by the company.
  • the company may use one or more of a web site (shown in Box 2.232), a call center (shown in Box 2.234) and/or live customer service "counter" personnel (shown in Box 2.236) (e.g., at a point-of-sale location).
  • the Value Option Creator module (shown in Box 2.240) is a software program(s) that performs the functions of allowing a company to design, create and configure different value option frameworks and corresponding value options that can be offered to customer to capture their needs and preferences in detail and in a way that can be used to optimize across company operations.
  • the Event Optimizer module (shown in Box 2.250) comprises a program or programs that (a) monitor company business performance and provide information about business data (such as available capacities, costs, sales, inventory and so forth) as well as other relevant factors that may vary from installation to installation; and (b) monitor for the occurrence of events related to the value options which customers have bought, and which then execute pre-designed protocols when a related event occurs (e.g., a re-booking algorithm is activated when a flight cancellation event occurs).
  • business data such as available capacities, costs, sales, inventory and so forth
  • a set of value option frameworks (to be associated with a company's offerings) is created. It is immaterial, for the current discussion, how one obtains the information used to construct a value option framework. Implicitly or explicitly, a value option framework reflects some sort of analysis of customer dynamics and company economics. Thus, to construct a value option framework for a particular type of transaction, one needs to arrive (however one chooses) at a list of components the customer may select when buying a product, and their prices. For example, in a simple case there may be delivery options and warranty options and maybe training options. Each option is assigned a price, whether statically, quasi- statically, or dynamically. Static pricing is assigned at very infrequent intervals.
  • Dynamic pricing (determined by an algorithm invoked by the Event Optimizer is assigned either on an on-demand basis for a particular transaction or at frequent intervals so as to yield pricing based on near (i.e., quasi) real time company performance data. Quasi-static pricing would be somewhere between the former two situations, such as pricing done quarterly or monthly based on then-current information about the company. Pricing may involve running financial analysis based on known data to optimally set the conditions and pricing in the value option framework associated with the company offerings.
  • the second stage involves a detailed interaction with the customer who has approached the company (Act 11.1110).
  • Approaching the company may involve accessing a web site or calling a call center or any other way of commencing a transaction.
  • the interaction occurs in a structured format to capture the customer's expressed needs, preferences, flexibilities and relative utilities.
  • the customer may previously have registered a profile containing default selections of needs, preferences, etc. So, the database 2.210 is interrogated to determine whether a profile exists and, if so, to retrieve it (Act 11.1120A).
  • the customer is presented with questions and/or value options (Act 11.1120B) and in response he/she supplies answers and select options that suit him/her (Act 11.1120C).
  • the second Act in the second stage is executed by the Event Optimizer module 2.250.
  • the Event Optimizer is alerted to, or detects, the occurrence of an event (shown in Box 11.1 132 and 11.1134) for which an event-response procedure (program) has been pre-stored.
  • Each event-response procedure is designed by the company to effect selected action(s) in response to detection of its corresponding event.
  • an event-response procedure may invoke an optimization algorithm (shown in Box 11.1140), assess the company operations (possibly in real time) and analyze, across company operations (shown in Box 11.1138) and customer information (shown in Box 11.1136), potential results to determine results that concurrently maximize the benefits for the company and the customer.
  • the optimization may or may not modify the company product offerings to better suit the customer while simultaneously maximizing the company operations (shown in Box 11.1 150). Both of the stages and the steps involved will now be discussed in detail.
  • Fig. 3 it will be assumed that the inventive method and system are to be adapted to a particular industry or company.
  • to formulate a value option framework one begins by selecting the industry. Act 3.310. Next, the customer and company dynamics are captured. Act 3.320. To capture customer dynamics, one needs to understand the value segments and value elements that are important for the customer. To assess company dynamics, one needs to assess the economic factors that are crucial to the company's profitability and performance.
  • a customer derives certain utility by purchasing a particular product.
  • the purchase utility value typically, can be separated into many value segments.
  • Customers value these segments (which include core qualities of the offering as well as options and contingent options i.e., options dependent on options) from the perspective of what is important to the customer through the whole buying and usage experience, starting from, searching for a product, placing a particular order and using the product throughout its lifecycle.
  • value segment and value element.
  • a "value element” is a distinct aspect/characteristic of a product's buying and usage experience that may affect the utility of the product to the customer.
  • a "value segment” is a particular category of such value elements.
  • value segments may vary from industry to industry and will have to be selected by the individual or team that implements a particular instance of this system and method, for many industries, the four most important value segments are (a) product design value, (b) product delivery value, (c) product price value, and (d) service value. There may be one or more other value segments. See boxes 3.320B to 3.320F. These value elements are shown in Figs. 4 and 5, which are simply alternative views of the same information and will be discussed below. It should be noted, however, that these value segments are just provided for illustration purposes. Industries that can benefit from the system and method of the invention may have more or fewer than the listed value segments and/or a different list of value segments. Each value segment may have one or more value elements. Further, the actual number of value elements in each value segment may vary with the industry, the level of detail in the business model, and even the customers. The system implementer can choose the number of value elements in each value segment.
  • a customer derives unique value from each value segment; the total utility value of the product to a customer (shown in Figs. 4 and 5) is the combination of values derived from each of the value segments. A customer would benefit the most if the total expected value of his/her utility were maximized. Another important aspect to note is that every customer also has an acceptable range (e.g., equals, exceeds, or ashameds, minimum or maximum) for each individual parameter value. Even if a particular product has high overall value, a customer may not desire the product if it scores below the minimum level (i.e., low enough to reject the product) for any one or more of the value segments or value element. A company may use any method for calculating utility.
  • a human resource manager who has scheduled interviews with candidates, would value the timely ticket to his destination much more than a vacationer, who may be flexible. Consequently, the company needs, in some way, to define and learn about these value parameters for individual customers, along with relative preferences and utilities associated with each parameter. This will be illustrated below using the previously listed value segments.
  • a web-based questionnaire is one excellent way to collect this information. The collected information is then stored in a customer profile or Itinerary in a database, such as database 2.210.
  • the "product design” segment refers to the value elements relating to the design features and characteristics of a product that the customer actually buys. Each customer places his or her own values on these different design value elements.
  • the "product delivery” segment refers to the value elements relating delivery or time-frame related aspects like, for example, lead-time and delivery schedule from the time the customer places an order. Again, each customer may place his or her own values on each of these value elements. The company collects detailed information on the product delivery needs of the customers.
  • the "product price” segment refers to the groups of value elements related to the price a customer pays to buy/use a product.
  • Value elements in this segment may include total product price, delivery costs, warranty or after-sales service costs, and any other relevant costs incurred by the customer in buying and using the product. Some times, addition of all these price elements is also termed total cost of ownership (TCO).
  • TCO total cost of ownership
  • a customer derives maximum price value by paying the most desired price for a product. Any price paid either lower or higher than the desired price may change the value the customer gets from the price of the product.
  • the company collects information on the product price needs of the customers.
  • the "service value” segment refers to a group of value elements related to the service a customer receives from pre-sales and post-sales services offered by the company to facilitate the use of the products sold.
  • Pre-sales services include services provided by a company to help its customers decide and choose products based on their requirements.
  • Post-sales or after-sales service refers to the warranty, product support, maintenance support and other relevant activities that may help a customer to use the product effectively.
  • a customer will derive maximum service value from a product if the services provided by the company completely match or exceed those desired by the customer.
  • the company utilizing the invention collects information not only on the service needs of its customers, but also on customer preferences on different possible events that might occur during or after the purchase.
  • the first Act for a company is to establish the value segments and value elements it will present to the customer for the customer's decision. It may establish these value segments and value elements in any way it chooses.
  • a company may want to use market research or other mechanisms to analyze the value segments and value elements that are important to customers. An industry expert may choose to avoid such research and, instead to rely on experience.
  • the next Act in the first stage, as shown in Fig. 3, is to assess the crucial economic factors that affect the bottom-line and top-line of the company, Act 3.330A.
  • these factors may include but are not limited to revenues, fixed costs, inventory, available and scheduled capacity, constraints on product availability and total and marginal values for current direct and indirect product (and/or services) costs.
  • Fig. 3 shows the grouping of such factors into five major categories 3.33 OB-F, including costs, revenue, service, competition and other.
  • a third Act shown in Box 340 of Fig. 3, is to take the information collected from the previous two steps, analyze this data and find important value segments and elements that directly affect the crucial economic factors for the company. This operation involves creating a mapping between company factors and customer value segments, to establish direct and indirect relationships between the two.
  • a value option framework involves certain steps illustrated in Fig. 8.
  • the value option framework is formed around important mapped value elements, allowing capture of detailed individual, customer-level data expressing needs, preferences, flexibilities and relative utilities so as to positively impact the company operations, while simultaneously enhancing the overall product utility for the customer.
  • a value option framework (VOF) must allow the company to capture a customer's demand, preferences, flexibilities and relative utilities at an individual level in a format that can allow that information to be used to produce a cost savings or revenue enhancement for company operations while concurrently enhancing customer utility.
  • VEF value option framework
  • Fig. 8. The process to create a value option framework is shown in greater detail in Fig. 8.
  • Act 8.810 the process starts from that list. From this list, the company may select a list of mapped value elements which fulfill the criteria listed above, Act 8.820, and a value option framework is built around those value elements.
  • a value option framework is built around those value elements.
  • Fig. 8 there are three VOFs shown at 8.830, namely A, B and C.
  • the number of value option frameworks shown is for illustration purposes only and could be fewer or more, depending on factors such as the industry selected and user discretion.
  • each value option framework is related to a corresponding value element and one or more related event(s).
  • value option framework A is related to a value element V A and two related events, E AI and E A2 -
  • E AI and E A2 In most situations, after the initial interaction between the customer and company related to a particular value element, one or more related events (or a series of events) would take place.
  • the structure of a value option framework is defined below in detail.
  • Fig. 9 defines the structure of a Value Option Framework.
  • the Box 9.910 shows a value option framework A. Every value option framework may be related to one or more value elements. As shown in the Box 9.910, value option framework A is related to value element V A - One can create one or more instances of a value option framework as shown by the two value options (A
  • the Box 9.920 shows the initial interaction between the customer and company where the company offers the value option Ai to the customer. Every value option has an initial costs/savings and other benefits and conditions to the customer; and revenue/costs and other benefits and conditions to the company. The Initial Transaction is successful if the customer selects the given value option.
  • Every successful transaction may be succeeded by one or more related events (or a series of events as shown by the Boxes 9.930 (Level 1 events) and 9.940 (Level 2 events).
  • each event may also have costs/savings and benefits and conditions to the customer, and revenue/costs and benefits and conditions to the company, as shown by the linked arrows from Event E A3 to both the customer and company.
  • the Initial Transaction may consist of one or more acts. One or more products may be selected, at one or more times, before, after, during the Initial Transaction, or any combination thereof.
  • the Initial Transaction or any of the following events may have terms and conditions applicable to the customer, the company, another entity or any combination thereof. These terms and conditions may be set, preferably, to concurrently benefit both parties.
  • the company-user also preferably categorizes its population of customers into one or more segments based on one or more criteria. Customer segmentation is based on customer behavior and needs. Individual customers are not necessarily segmented or grouped; a particular customer may fall within different customer segments at different times. It is the customer behaviors and needs that are segmented. To provide an example, in the Box 860 in Fig. 8, all of the company customers are categorized into three customer segments, namely, C' A , C 2 A) C 3 A for the value option framework A. The number of customer segments could vary depending on the industry and value option framework, and this method does not put a limit on the number of customer segments.
  • the number of customer segments shown is for illustration purposes only and could be fewer than or more depending on industry selected, value option framework and user discretion. Further, a company may segment its customers differently for different value option frameworks or they may use the same customer segmentation for a few or all value option frameworks. The customer segmentation is done because the customer behavior can be subdivided into different groups and customer showing similar behavior could be dealt in a similar fashion.
  • the user After formulating one or more sets of value option framework(s) around the selected value elements, the user creates one or more value options for each set of value option frameworks.
  • the value options Ai, A 2 and A 3 are created in box 8.850 for the value option framework A.
  • the number of value options shown is for illustration purposes only and could be fewer or more depending on industry selected, value option framework and user discretion.
  • the user For each value option created, the user defines parameters for option pricing, benefits and conditions to the customer, as well as revenue, costs and option conditions to the company, under which the option would be used. If necessary, a user may also need to create a separate questionnaire to be completed by customers, pertaining to each value option.
  • a price may include, but is not limited to, a set of one or more Product Prices, a set of one or more option prices, any other price or any combination of the above.
  • the price may consist of a monetary value or a soft value (e.g., benefits, coupons or exchange of another service) or other consideration.
  • the price may be fixed or variable, with or without bounds.
  • the company may set permissible range(s) or boundary limit(s) within which the price can vary, or it may offer the customer a set of prices to choose from. Since price conditions may depend upon various factors, which may or may not be variable, the same may be decided at anytime.
  • the price conditions may be determined by the customer, the company, a third entity, or any combination thereof, at one or more times.
  • the user creates value options for each particular customer segment (Act 8.870).
  • the structure for value option conditions for Value Option A 2 tailored to customer segment C 3 A is shown in the Box 8.880.
  • the user creates conditions and parameter values for each value option for each customer segment.
  • one or more parameters for different customer segments may be the same. Across multiple value options (within the same value option framework), one or more parameter values may be the same for one or more different customer segments. It is possible that one or more value options may not be valid for a particular customer segment or a sub-segment within a customer segment.
  • Fig. 10 for each value option created for a specific customer segment, the user creates the following functions as shown in the Box 10.1030. (The number and type of functions shown is for illustration purposes only and could be fewer than or more depending on the industry selected, the value option framework and user discretion.)
  • Cf(X) This function expresses the cost elements to the company related to usage of a specific value option.
  • Fig. 10 displays the cost function [C f (A 2 -C A )] to the company when a customer (within customer segment C 3 A ) selects the value option A 2 .
  • This function expresses the costs to the company initially when the user selects the value option A2, and also for each of the related events if and when those related events take place.
  • Ri(X) This function expresses the revenue elements to the company related to usage of a specific value option.
  • Fig. 10 displays the revenue function [R f (A 2 -C 3 A )] to the company when a customer (within customer segment C 3 A ) uses the value option A 2 .
  • This function expresses the revenue to the company initially when the user selects the value option A2, and also for each of the related events if and when those related events take place.
  • Customer Service Function to the company.
  • This function expresses the customer service function to the company related to usage of a specific value option.
  • Fig. 10 displays the customer service function [Sf (A 2 -C 3 A )] to the company when a customer (within customer segment C 3 A ) uses the value option A 2 .
  • This function expresses the customer service level a company provides initially when the user selects the value option A 2 , and also for each of the related events, if and when those related event take place.
  • Utility function to the customer. This function expresses the utility to the customer from use of a specific value option. For illustration purposes, Fig.
  • a financial analysis may be performed on the value option framework using the existing company and customer data to determine optimum pricing values and conditions of the value options.
  • a company using the system and method can build utility functions based on cost and benefit equations of various options, and then can optimize across any one or combination of such functions.
  • Any standard non-linear constrained optimization software tool can be used to run iterations to determine optimized pricing and benefit values for different value options.
  • a user can run what-if scenarios to determine the robustness of the value option framework. It is not necessary to perform this optimization to generate benefit from the new method and system taught above. However, performing optimization at this level may tend to increase the benefit derived.
  • Second Stage Using Value Option Framework
  • the user After completing the first stage of the method, the user has been able to create important value option frameworks and specific value options within those frameworks. The user has also segmented customers to be associated with each specific value option that may be applicable to each customer segment.
  • the company is fully prepared now to use a structured format consisting of value options and questionnaire to interact with its customers in real time to generate benefits for both customer and company.
  • the second stage of the new system and method involves using the value option framework to interact with the customer to capture his or her requirements in detail.
  • the system moves to the Event Optimizer stage, 11.1 130, where the system reacts based on the event that may take place.
  • the Event Optimizer depending on the event, invokes an optimization algorithm, assesses the company operations in real time and optimizes across company operations and customer information to produce results that concurrently maximize the benefits for the company and the customer.
  • the optimization may or may not modify the company product offerings to better suit the customer while simultaneously maximizing the company operations. Both of these steps will now be discussed in detail.
  • a series of questions are presented to the customer and the customer supplies answers. These questions may also present value options and ask the customer to answer and select the options that suit them the best, enabling the company to determine detailed preferences and flexibilities in customer needs.
  • the questions/value options are supplied from the database 2.210 based on the value option framework created in the first stage to deal with different customer segments.
  • Event Optimizer phase where different steps are executed depending on the event that may occur.
  • the event(s) is(are) related to the value option selected in the first Act.
  • FIG. 12 the typical Event Optimizer architecture is shown.
  • An Event Analyzer 12.1220 is a module that receives notifications of events and notes when a monitored event occurs.
  • Event Optimizer analyzes 12.1210 the event and invokes an optimization algorithm specific to the event that is detected. Using that algorithm, the Event Optimizer collects the information on related customers and assesses the company operations in real time.
  • a third Act takes the information collected from the previous two steps and uses predetermined criteria to optimize company operations along with customer demand.
  • the various scenarios are generated which optimize the total product value for the customer and profits and gains for the company. More details on the Event Optimizer are provided in the System Architecture section.
  • a user may create a value option framework, which includes a series of events.
  • the Event Optimizer after optimizing the result for the first event, may offer the results to the customer. The customer may or may not accept the results. If the customer does not accept the result, the Event Optimizer may move on to handle other subsequent related events, and may again come back to the customer with more results. This process could be repeated several times depending on industry selected, the configuration and type of value option framework, and customer behavior.
  • the company interacts with the customer in a structured format to capture customer needs, preferences, flexibilities and relative utilities in detail.
  • the next stage involves an Event Optimizer as explained above.
  • the customers associated with the event are enlisted and sorted by pre-defined criteria.
  • the Event Optimizer collects customer information from the database and also assesses company operations in real time before integrating this information to produce one or more optimized results that concurrently maximize the benefits for the customer and company.
  • the system architecture as shown in Fig. 2 may be used to implement the new system and method taught above.
  • the Value Option Creator (Box 2.240) allows the user to create and configure different value options that can be offered to the customers to capture their needs and preferences in detail and in a way that can be used to optimize across company operations.
  • the Event Optimizer (Box 2.250) allows the company to optimize across company operations and customer needs when an event is triggered to provide a product offering that maximizes both customer utility and company profitability.
  • a company would use the Customer Engine (Box 2.230) to interact with its customers via different channels. Each of these three sections is defined below in detail. Customer Engine
  • the Customer Engine provides different interfaces that a company maintains at different channels, which are utilized to interact with the customers. These channels may include, but are not limited to, the company's website via the Internet, the company's call center via phone, and the company's retail outlet via in-person.
  • the Customer Engine enables the company to ask questions and/or offer value options to customers in a pre- conf ⁇ gured structured format.
  • the Customer Engine generates its interfaces based on the data stored in the database and populated by the Value Option Creator.
  • the customers provide their responses and select value options that suit them.
  • the Customer Engine then communicates back and stores customer responses and selections in the database.
  • the Customer Engine also may communicate the optimized results to the customer as and when generated by the Event Optimizer.
  • the Value Option Creator allows a company to design, create and configure different value option frameworks and corresponding value options that can be offered to a customer to capture his or her needs and preferences in detail and in a way that can be used to achieve optimization across company operations.
  • a company would use the Value Option Creator module to perform some or all of the following:
  • a customer segment may include one or more customers.
  • the Value Option Creator intakes the cost functions (marginal and total), revenue functions, utility functions, customer segments, capacity (scheduled and available) functions and other economic factor functions of the company.
  • the VOC can be configured to store various customer value segments on which a user may want to build value option framework and associated value options.
  • a user can also enter the constraints and ranges to perform pricing optimization to determine optimum pricing and the benefits of various options.
  • a user may be able to create a Value Option Creator that is industry and company- independent and can be used in several industries. Due to time and resource constraints, however, it is perfectly satisfactory for a user to build a less scalable and flexible industry-specific Value Option Creator.
  • the Event Optimizer allows the company to optimize its "bottom line” across company operations and customer needs, when an event is triggered. This is achieved by providing a product offering that maximizes both customer utility and company profitability.
  • a suitable system architecture i.e., overall flow for the Event Optimizer in shown in Fig. 12. The following describes each Act in detail:
  • the Event Optimizer may start its functioning when a particular event is triggered (i.e., occurs and is detected at the time of purchase or later), Act 12.1210.
  • the Event Analyzer (12.1220) analyzes the type and category of the triggered event by matching it with the list of events listed in database 12.210. Once the event type is determined, the Event Analyzer searches the database for an optimization algorithm that is associated with the triggered event, and executes that algorithm. (Such algorithms, naturally, have been developed and stored in the database at an earlier time.) The algorithm collects from the database a list of the customers that are associated with the triggered event, Act 12.1240, and sorts them based on pre-defined criteria listed in the value option framework associated with the event, Act 12.1250.
  • the first customer is taken from the sorted list and his or her preferences and value option selection are retrieved from the database. Act 12.1260.
  • the algorithm then makes a real-time assessment of the company operations to get up-to-date costs, capacities and constraints. Act 12.1270.
  • the information collected in the above two steps is then integrated (Act 12.1280) and, based on a pre-defined criteria, the algorithm optimizes across the company information and customer preferences to produce one or more results that concurrently maximize the benefit for both the company and the customer.
  • the results are preferably communicated to the Customer Engine and to database 12.210, Act 12.1290. These steps are repeated until all the customers have been taken care of Steps 12.1252, 12.1254 and 12.1295.
  • Fig. 13 expands the Act 12.1280 to show the detailed sub-steps.
  • the first Act (Act 13.1310) is to search the company data, based on pre-defined criteria, to determine and store all EventResults that meet or exceed the customer conditions (based on the value option selected and other preferences).
  • An EventResult is a potential resultant output of an event to the customer and the company.
  • the next Act 13.1320 is to determine from the stored list, those EventResults that are most beneficial to the company. If needed, another Act (13.1330) is performed to determine from the selected EventResults from the Act 13.1320, those results that best suit the customer.
  • the event- specific algorithm may communicate optimized results to the customer one or more times, depending on the algorithm and customer behavior.
  • Different business models may be used to implement a value option framework as described in the current invention.
  • the business models mentioned below, without limitation, may be used to implement any value option framework in any industry.
  • a company may choose to implement a UPO VOF (explained later) individually or in conjunction with one or more partners and/or other companies.
  • the OA and the company may engage in a business agreement to implement one or more value option frameworks.
  • the business agreement may divide the total benefit generated by said value option framework between the two parties using any mechanism or criteria as desired.
  • the total benefit may be shared between the two parties.
  • the company may allocate one or more products to the OA.
  • One or more companies may allocate only a part of or their entire product inventory to the OA to offer those products to the customers by way of regular and/or as options.
  • the OA may offer some revenue or fee to the company for all or a portion of the products allocated. This fee may be given only for the products that the OA is able to utilize or for all the allocated products.
  • the lending fee may be a lump sum amount, may depend upon the number of products allocated or may depend on one or more factors as desired.
  • the agreement may include a provision where the OA may return the allocated products back to the company at a certain time and date. There may be one or more conditions associated with the return of unused options and/or regular products, including, but not limited to, returning the same product, returning a higher value product and so on.
  • the company may allot OA at least one product and said OA may deliver option on at least one of said allocated products.
  • the OA may or may not enter into an agreement with the company to provide such option on its products.
  • the OA may sell back at least one allocated product to said company or to at least one entity other than the company or both.
  • An OA may formulate an agreement with one or more companies on one or more VOFs to offer a combination of VOFs to customers.
  • Said VOF may include different terms and conditions. For example, a customer may receive option price only from the company even if he/she is receiving products and/or options from the OA. Similarly, the customer may receive option price only from the OA even if he or she selected the products and/or received the options from the companies.
  • the condition may also be set for a customer to make one or more payments to the company for the products and receive one or more payments from the company for the options received from that company, and to make one or more payments to the OA for the products and receive one or more payments from the OA for the options received from that OA.
  • the condition may allow the customer to receive partial payments from the company and the rest from the OA or vice versa, the basis of which distribution may depend upon various factors, including, but are not limited to, the factors of company's choosing, the arrangement between the OA and the company and so on.
  • the customer may receive the option price from the third party or may receive the option price from any of the combination of the entities mentioned above.
  • a company may allocate some inventory of one or more products to another entity such as an OA or Option Aggregator.
  • the term "allocation of product inventory” "allocation of product(s)” implies, without limitation, assigning one or more units of one or more products to an entity for any purpose or use by the entity either exclusively or non-exclusively.
  • the allocation of product may be conditional. For example, one of the conditions may require a return of at least one allocated product within a specified time period and/or other consideration(s).
  • the customer may receive products and/or options from one or more of the company or OA or any combination thereof.
  • the Fig. 13A displays one example where three different companies choose to allocate one or more products to another entity (i.e., OA in this example).
  • the OA may use the allocated products to operate a service to satisfy different needs of the customers.
  • the companies and their products are designated as Company I/Product cl, Company 2/Product c2 and Company 3/Product c3 as shown by the Boxes 13A.130, 13A.170, 13A.140, respectively.
  • Company 1 and Company 2 may act together to implement the value option framework and may allocate one or more products to the OA which may on its own or together with either one or both the companies and may operate the service to offer said value option framework to the customers.
  • Box 13 A.I 10 represents Customer 1 receiving product cl and c2 from Company 1 and an option ol from the OA.
  • the Box 13A.120 represents Customer 3 receiving product c3 from Company 3 and products cl and c2 from the OA and options o2 and o3 from Company 3.
  • Customer 2 receives product cl from the OA and options ol, o2 and o3 from OA, Company 2 and Company 3 respectively.
  • Customer 4 receives products c2 and c3 and also option ol from the OA.
  • customer receives both product c2 and option ol from Company 2.
  • the companies and the OA may, without limitation, work together as partners, joint ventures, all together separate entities, partnerships etc., to offer and implement the value option frameworks related to the novel invention.
  • the business model may be used with all the value option frameworks of the current invention which may involve some customization for the specific value option framework.
  • the customers may approach OA in many different ways and the same may depend on one or more factors including, but not limited to, way of implementation, type of implementation, one or more factors of choice of the company, OA, third entity and/or any combination thereof.
  • the ways customer may approach OA through phone as shown in Box 13B.140 and Box 13B.130 of Fig. 13B to avail services from the OA.
  • the customer may approach OA through Internet.
  • the customer may use other ways of approaching the OA, which may include, but not limited to, fax, telex, mail and personal contact.
  • the OA may validate the Order with which a customer wishes to avail an option and it may be validated in coordination with the company from whom the customer has received said Order as shown in Boxes 13B.150 and 13B.160.
  • Order validation process runs to validate the Order from the company server and the database may be updated accordingly as shown in the Boxes 13B.150, 13B.160 and 13B.170.
  • the validation process may involve back and forth interaction between the database and/or servers of the OA and/or the company and/or any third party. There may be updates in the database even if the Order is not validated.
  • the company server may also provide OA with the information of its inventory.
  • the process may request the customer to enter the search criteria. Search is made corresponding to the search criteria entered by the customer (Box 13B.180).
  • the server application may be used to provide a given set of Options corresponding to the search criteria (Box 13B.190). To provide the set of options, the server application may interact back and forth with OA server and/or OA option database.
  • the servers and/or the databases may belong only to the company, OA, third entity and/or any combination thereof.
  • a client-server architecture may be used to implement the value option framework.
  • a company may use a computer hardware and software infrastructure of its choosing to implement a particular value option framework for achieving concurrent optimization.
  • One or more servers may be used for the system and one or more medium of communications may be used between the customer and the company and/or the OA and vice versa including, but not limited to, a highly secured VPN and Internet.
  • One or more of such servers may be located at the premises of the company, OA, third entity and/or any combination thereof. Such premises may also be an offshore location which may or may not be accessible remotely.
  • One or more databases may be involved and may be updated on a real time basis.
  • the Fig. 13C shows one of the ways by which the different entities involved and participating in the value option framework, interact and may participate in the value option framework. There may be other ways for implementing the value option framework which may depend upon including, but not limited to, the scale of the implementation, business requirements and number of entities involved.
  • the entities may interact through a series of hardware products and services with the OA/company server(s).
  • the OA may or may not be different than the company and the OA server may be the same as that of the company server.
  • One of the entities shown in Fig. 13C is customer (Box 13C.1 10), who uses input device (Box 13C.120) to enter the requirements.
  • the customer inputs are processed through the CPU (Box 13C.150) and one or more Hard Disk Drives (Box 13C.160).
  • RAM (configuration of which may depend upon different factors) is used as memory device (Box 13C.140) while processing the customer input.
  • the customer may approach the OA and/or the company through one or more series of Routers, Internet, Firewall and other hardware (Boxes 13C.330, 13C.335, 13C.340 respectively).
  • the interactions between the company and/or the OA and the customer may pass through one or more load balancers (Box 13C.360) that distributes load across one or more servers as shown in Boxes 13C.300, 13C.310 and 13C.320.
  • OA servers may update one or more primary database as shown in Boxes 13C.270, 13C.280, 13C.290.
  • the company may have one or more separate temporary database structure wherein the entries are updated and stored until the final update is made in one or more main databases. One the final update is done, the entries in these temporary databases may be removed.
  • OA may interact with the application through Internet (Box 13C.350).
  • OA application servers may also distribute load between one or more servers of OA and/or the company through one or more load balancers.
  • Agent (Box 13C.260) may interact through input device as shown in the Box 13C.250.
  • Input information may be processed by the CPU as shown in the Box 13C.180 with the use of one or more RAM, Hard Disk Drives (HDD) as shown in the Box 13C.200 and 13C.170 respectively.
  • It may interact with the company through the Intranet (Boxes 13C.210 and 13C.220).
  • the company and the OA may interact through a series of routers, firewalls and Internet (Boxes 13C.330, 13C.335 and 13C.340).
  • OA There may be another agent on behalf of the OA (Box 13C.410) which may input through one or more input devices (Box 13C.420).
  • the information may be processed through the monitor, one or more hard disk drives, RAM and CPU as shown in Boxes 13C.430, 13C.440, 13C.460 and 13C.450 respectively).
  • One of the ways in which said agent may interact with OA is through highly secured Intranet as shown in Box 13C.370.
  • the entire process may run at the premises of OA, company and/or any third entity or any combination thereof. It may also be possible to run a part of the system at one place and rest at one or more other places.
  • the system may also be implemented even if one or more servers may be kept off-shore locations and may be accessed remotely.
  • the geographical locations of one or more hardware product and/or services may be different depending upon including, but not limited to, the factors of company's choice, ease of accessibility, infrastructure facilities.
  • the structure or the interaction architecture of the system may vary depending on factors including, but not limited to, the set up of the company, changes in the technology and with the introduction of new and better technology enhancing the interaction process.
  • the value option framework as a system may require integration with various hardware and/or network services. This is illustrated in Fig. 13D where a detailed implementation of one of the stages of value option framework is described duly integrated with the hardware products and services.
  • the customer inputs search criteria as shown in the Box 13D.100.
  • the web page and/or the application may be hosted on the company's server, OA's server, any third entity's server and/or any combination thereof.
  • Such a server may be located at the premises of the company, OA, any third entity location and/or any combination thereof and such a location may include an offshore location.
  • the customer may approach the web (server) application of the company through Internet and one or more Firewall etc. as shown in the Boxes 13D.110 and 13D.120.
  • the medium by which a customer reaches (approaches) the company web (server) application may vary depending on different conditions which may include, but not limited to, the best available communication medium at a particular time, scale and type of implementation of the value option framework and factors of company's choice.
  • Server application runs the search algorithms (Box 13D: 130) corresponding to the customer requirements in association with one or more servers of the company as shown in the Boxes 13D.150, 13D.160, 13D.170 respectively.
  • the servers may include, but are not limited to, web servers, application servers, database servers and networking servers. Said application may be hosted internally on one or more servers and databases either by the company and/or the OA or may be hosted on any third party's server.
  • the servers may also be the servers of the OA or the servers may be run jointly by the company, OA and/or a third entity.
  • Load balancer (Box 13D.140) may be utilized to distribute load across one or more company servers.
  • the search algorithm may interact back and forth with one or more database including, but not limited to, email database, option database, inventory database, customer database, company database as shown in Boxes 13D.230, 13D.240, 13D.250 and 13D.260.
  • a test is performed to determine whether the outcome of the search algorithm is positive as shown in the Box 13D.180. If the outcome is negative, customer may be asked to re-enter/modify the search criteria (Box 13D.210). If the outcome of the search algorithm is positive, the customer is provided with a list of options as shown in the Box 13D.190. Once the customer is provided with a list of options to choose from, another test is performed to determine whether the customer has opted for one or more options (Box 13D.200). If customer has not opted for an option, then customer may be asked to re-enter/modify the search criteria (Box 13D.210). If the customer re-enters the search criteria, the control loops back to Box 13D.130 wherein the server application runs the search algorithm on the basis of the inputs received from the customer.
  • At least one payment transaction is executed (if any) (Box 13D.300) and one or more databases may be updated (Box 13D.270) through internet, firewall as shown in Box 13D.320 and 13D.330. Said updates may also be done through one or more routers, highly secured VPN Network etc.
  • Said primary databases including, but not limited to, email database, customer database, inventory database, option database may be updated correspondingly as shown by the Boxes 13D.230, 13D.240, 13D.250 and 13D.260.
  • the company may have one or more separate temporary database structure wherein the entries are updated and stored until the final update is made in one or more main databases. One the final update is done, the entries in these temporary databases may be removed/deleted/discarded.
  • the algorithm ends after the needed updates are made in one or more databases and/or one or more severs or if the customer desires not to re-enter/modify the search criteria (Box 13D.400).
  • Second stage in the value option framework is achieving concurrent optimization for at least two of the company, customer, OA, third entity or any combination thereof on occurrence of an event.
  • Fig. 13E describes one of the ways of using the information network system in which interaction between OA, company and event (which may be triggered by the company, OA, customer, any third entity or any combination thereof) takes place.
  • Fig. 13E presents a diagrammatic representation of a chain of actions that takes place corresponding to occurrence of an event. There may be one or more different ways in which said action may take place and may depend upon the factors including, but not limited to, the arrangement between the OA and the company, factors of OA and/or company's choosing and one or more mediums of technology utilized in the system.
  • one or more load balancers may be used to distribute the load across one or more servers (Boxes 13E.140, 13E.150 and 13E.160).
  • One or more different databases may also be updated as per the requirement and the nature of the event. Information is processed through the servers using one or more RAM, Hard Disk Drives and other hardware products and corresponding to the occurrence of the event, updates are made in one or more databases as shown by the Boxes 13E.170, 13E.18O and 13E.190.
  • One or more company servers and databases may also be updated using external communication medium/port (Box 13E.280).
  • the servers may include, but not limited to web servers, application servers, database servers and networking servers.
  • One or more said databases include, but are not limited to, email database, option database, customer database.
  • the Optimization server interacts with one or more databases including, but not limited to, the optimization rule database and customer rule database as shown in the Boxes 13E.170, 13E.18O and 13E.190.
  • One or more optimization algorithm may be run within the optimization server using one or more RAM, Hard Disk Drives.
  • the Optimization server may give one or more possible optimum solutions depending on the factors and rules determined by the company, OA and/or any third entity or any combination thereof, as shown in the Box 13E.220.
  • a set of possible optimum solutions passes through one or more databases including, but not limited to, constraints rule database and constraints (or validation) database as shown by the Boxes 13E.250 and 13E.260 respectively. While interacting with said database, the OA agent may also be approached as shown in Box 13E.260.
  • a test is performed to determine whether the constraints are fulfilled and/or payment transaction is executed (if any) (Box 13E.270). If the constraints are fulfilled and the payment transaction is also executed (if required), a series of database updates as shown by the Boxes 13E.170, 13E.18O and 13E.190 may be done. Once one or more database are updated, the Customer Notification Process (Box 13E.390) takes place, in which the customer is notified, and the algorithm then ends in Box 13E.400. If the constraints are not fulfilled and/or payment transaction (if needed) is not executed, the process ends at Box 13E.400.
  • One or more such kind of information technology system may be implemented for the specific value option framework.
  • the system may be customized as per the specific requirements of the company, value option framework, OA, any third entity, customers and/or any combination thereof.
  • a company can greatly improve its overall business prospects.
  • the company can look to build very high customer retention rates and also increase the number of new customers gained per unit time. It can help to increase the overall sales and thus help increase the overall business value.
  • the company may distribute a portion of additional value gained back to its customers to further strengthen its relationships with them, if it wishes.
  • a company may encourage customers to "opt in” to this system and provide the customer's preferences by giving rewards to customers to provide these preferences and commit early.
  • the value options may be created and priced to motivate customers to make choices that both satisfy their needs and simultaneously allow the company to improve its operations.
  • This method further adds new dimensions to business parameters like inventory. Previously, for a company, inventory was either “Committed” or “Available.” This method adds a new dimension of "flexibility”. With the customer preferences and needs taken beforehand, we add the dimension of flexibility to the inventory. For example, a booked flight seat would conventionally be called committed inventory. But now within the new methodology, if the ticket-holding customer is flexible, his ticket may fall into a pool of flexible inventory availability, which may be sold to other customers, if necessary.
  • customer inventory creates a new type of inventory, called customer inventory.
  • a company by using its powerful value option framework, would be able to capture its customers' and potential customers' future needs in advance.
  • the company would collect information on which customers want to purchase what products, when and with what specifications or parameters. Combining this individual customer data across thousands of customers would generate a customer needs and preference database with appropriate classification and parameters.
  • the needs (and/or preferences) of this database could be classified as customer inventory wherein the items in inventory are the needs of several groups of customer with similar needs. Once the company has built such a database, they can use the customer inventory as and when needed in optimizing their internal operations to maximize value for both the company and the customers.
  • the method allows a company to move from a knowledge-based system to an expert system, which optimizes the decisions based on customer preferences and company economics.
  • the method allows the companies to market a whole new paradigm of services and products surrounded around their original product offerings. This is achieved partly by unbundling formally bundled components of existing products, into components offered to the customer and partly by building new products and services. This allows the customers to choose product features they wish to purchase and saves the company from making investments and incurring costs in providing product components to those who don't want or desire those components.
  • this method accomplishes the following: (1) makes a business more attractive to customers by enabling customers to express their preferences; (2) makes a business more efficient and reduces costs; (3) allows a company to handle problems and disruptions in a quick, efficient manner to generate high customer satisfaction and keep their costs low; (4) helps a company to increase and strengthen its customer base, improve sales per customer, and customer retention, and (5) helps to increase the value customers gain from the purchased products.
  • the above method may be applied to several industries including, without limitation, airlines, hotels, automobiles, media, entertainment (television, radio, internet, etc.), furniture, insurance, computer hardware, travel (e.g., vacations, car rentals, cruises), events (such as theatre, movies, sports games etc.).
  • industries including, without limitation, airlines, hotels, automobiles, media, entertainment (television, radio, internet, etc.), furniture, insurance, computer hardware, travel (e.g., vacations, car rentals, cruises), events (such as theatre, movies, sports games etc.).
  • industries including, without limitation, airlines, hotels, automobiles, media, entertainment (television, radio, internet, etc.), furniture, insurance, computer hardware, travel (e.g., vacations, car rentals, cruises), events (such as theatre, movies, sports games etc.).
  • travel e.g., vacations, car rentals, cruises
  • events such as theatre, movies, sports games etc.
  • UPO Upgrade Product Option
  • a company may implement a UPO VOF in any industry.
  • the customer preference for higher ranked products (defined below) is used as the targeted value element.
  • the first stage in the UPO VOF involves steps (or acts) of: capturing customer dynamics, assessing company operations and economic factors, integrating customer dynamics with company economic factors, formulating the VOF and optimizing the VOF.
  • the second stage involves carrying out a dynamic interaction with the customer and then executing an Event Optimizer process.
  • the terms “Up Product” or “Up Products” refer to one or more products that rank higher than the other products of the company. The ranking here is assumed to be based on past customer preference and may differ from one customer to another. In the same context, the lower ranked product is referred to as the "Base-Product”. The term “Base-Product” also refers to the product, which a customer has currently booked (or selected or purchased). And in that context, an "Up Product” refers to any higher ranked product to which the customer can theoretically be upgraded to.
  • Fig. 14 shows an analysis of the value elements that are believed to matter the most to customers in relation to a product upgrade.
  • important value elements may include, but are not limited to, customers' preference for higher ranked products, utilization process, amenities and special characteristics and/or features, if any, associated with the products.
  • important value elements may include, but are not limited to, Product Price and upgrade price.
  • important value elements may include, but are not limited to, time to request and get upgrade award, and how long before utilization the product must be purchased for the customer to be entitled to an upgrade.
  • important value elements may include, but are not limited to, the ease of getting the upgrade. It may be important to estimate the relative preferences and utilities of these value elements to customers for various products.
  • customers assign ranking to different product offerings.
  • a customer may classify the product offerings into different groups (that may or may not be mutually exclusive) and assign a relative rank to each of them.
  • rankings may be implicit or well established or well known; for which a company may be able to assume/determine customer ranking that would satisfy the majority, based on an analysis of past customer behavior or other forms of market analysis.
  • the ranking may be very subjective; and may differ from one customer to another, and even for the same customer, may differ from time to time.
  • a company may need to perform detailed interaction with customers to determine their ranking.
  • products with higher perceived utility (satisfaction) values are generally ranked higher than those with lower perceived utilities.
  • Most customers would prefer to get a higher ranked product over a lower ranked product.
  • customers cannot get their desired product(s) due to unavailability, price or any other reasons or any combination of the above, they have to settle down with something below their desired value.
  • An assessment of the crucial economic factors of a company may reveal these factors to include, but not be limited to, the fixed and variable costs, non-uniform distribution of demand across different Products under the same category (or products from various categories), higher price for higher ranked products, varying capacities of higher ranked products much more than the capacities in lower ranked products, possibility of revenue dilution, increasing competition from other companies, lost opportunity costs in offering free upgrades to customers through existing upgrade programs (if any) and so forth.
  • An assessment of the crucial economic factors, such as costs, constraints and capacities, may be performed, to determine the factors that affect the profitability, growth and goals of a company in any industry. It might be beneficial if the company utilizing the inventive system and method were able to express cost elements in a real-time or quasi-real-time (i.e., up to date) dynamic fashion so that such information may then be used to assess the profitability or contribution of each product sale opportunity, and to facilitate the operation of the Event Optimizer (so that offers and actions can be based on real-time or near-real-time information). Certainly that is not always required and would not be required in an industry where there is little change in cost elements over a significant time interval. (3) Integration of customer dynamics with company economic factors
  • the Fig. 15 also illustrates an example of how a mapping may be done, between customer value elements and company profiles, for the UPO VOF in any industry.
  • customers who prefer higher ranked products to lower ranked products.
  • customers are also concerned about the price differences between the higher ranked and the lower ranked products. All customers cannot afford to buy confirmed higher ranked products at regular prices. However, many customers would be willing to pay more than their Base-Product Price to get higher ranked products.
  • On the other side of the screen if a company has surplus inventory or capacity or there is delay in selling of a higher ranked product, that condition probably represents the loss of potential revenue (and/or opportunity cost) for that company.
  • FIG. 16 displays the structure of a UPO value option framework (shown in Box 16.100) in any industry.
  • the UPO VOF is related to the value element "preference for higher ranked products", as shown in Box 16.110.
  • the customer receives a conditional option for an upgrade and the company awards the upgrade to the customer provided at least one condition on the option is satisfied.
  • a customer may select (purchase) one or more Base-Products and then select UPO option on one or more Up Products.
  • a company may award one or more Up Products from the selected UPO products or from other products or any combination thereof.
  • UPO VOF In another implementation of UPO VOF, during a successful Initial Transaction, a customer receives an option to utilize up to 'n' out of 'm' selected products (said 'm' products termed "UPO Products "). The 'n' products that are finally selected are termed “Chosen Products”. After each of the n products is defined (or selected or chosen or received), the customer has the right to utilize (or can utilize) said Chosen Product. Apart from the Chosen Products, the remaining products are termed "Released Products ". The Released Products (if any, that were held or blocked for said customer) may be sold to other customers as normal products or UPO Products or used for other purposes.
  • the Released Products in relation to said option may be reused by the company before, after, at or any combination thereof, the time the Released Products and/or Chosen Products are defined (or received or selected).
  • the m UPO Products would contain all the selected Base-Products and Up Products
  • the n Chosen Products would contain all the defined Base-Products and Up Products that the customer may utilize.
  • the customer may prefer to receive only Up Products in the defined n Chosen Products, since the customer would have higher utility for the Up Products, however, the Chosen Products may contain Up Products or Base-Products or both.
  • the value of 'm' is greater than or equal to 2 and the value of 'n' may vary from '0' to 'm' depending upon the specific implementation of the UPO framework.
  • the value of 'm' and/or 'n' may be known (or defined and/or re-defined) before, during, after the Initial Transaction and/or any combination thereof.
  • the value of 'n' may or may not be known (or defined and/or re-defined) at the time of the Initial Transaction.
  • the value of 'm' and/or 'n' may be defined by the company, the customer, another entity or any combination thereof.
  • the value of n may not be defined at the time of Initial Transaction.
  • the new value of 'm' may be greater than or less than the older value of 'm'.
  • the new value of 'n' may also be greater than or less than the older value of 'n ⁇ In some of the cases, the value of new 'n' may be even greater than the older value of 'm'.
  • the UPO Products may be selected by the company, the customer, another entity or any combination thereof.
  • the UPO VOF may enable a company to obtain preferences for Up Products from UPO customers (i.e., those who select UPO) and use said preferences to satisfy the product needs of other customers and/or to optimize the value for company, customers, another entity and/or any combination thereof. Therefore, the company would usually have the right to select (or define) the Chosen Products.
  • the company, the customer, another entity or any combination thereof may select one or more of the Chosen Products related to a UPO.
  • the UPO Products and the Chosen Products may be selected by the same entity, different entities or any combination thereof.
  • the customer may select the UPO Products and the company may select the Chosen Products out of the UPO Products.
  • the company may incorporate the customer information and the data related to the UPO into the sales, production, inventory, other database or information system or any combination of the above.
  • the option granted to the customer may be conditional.
  • One such condition (to upgrade) may be availability of the Up Product associated with the option. It may be possible that the Up Product availability associated with the option is the only condition included in the UPO VOF. If so, after receiving the UPO, a customer may receive a conditional right to be upgraded if the Up Product is available at a certain time and under certain conditions established as the terms and conditions of the option contract.
  • the time when an Initial Transaction is completed i.e., the customer receives a UPO
  • ITT Initial Transaction Time
  • One or more Base-Products and Up Products may be selected, at one or more times, before, after, during, or any combination thereof, the Initial Transaction and/or the time said option is delivered to the customer (or the customer receives said option) or any combination thereof. All the UPO Products may be selected concurrently (i.e., all together in one transaction) or sequentially (i.e., in multiple transactions).
  • a customer may select one or more Products in one or more transactions before the Initial Transaction.
  • Said selected Product(s) let's say X number of them
  • the customer may select only the remaining (m - X) number of UPO Products during the Initial Transaction.
  • All the transactions used to select (or receive) all the Base-Products of a UPO transaction may be related to each other, and hence, may be considered as "related transactions" (as defined earlier).
  • the sequential process may consist of a number of "related transactions" when all the UPO Products are received one after another by paying/receiving a price in one or more transactions or acts.
  • the price may include, but is not limited to, a monetary value, coupons, discount vouchers, other benefits such as loyalty program benefits, or any combination of the above.
  • the transactions may be related due to a relationship during the Initial Transaction, one or more of the previously executed transactions, any other transaction or combination thereof.
  • the UPO VOF may also impose other conditions on the company and/or the customer.
  • the option may impose a payment obligation on the customer if the company upgrades said customer.
  • the option may confer a right upon the company to enforce payment obligation on the customer.
  • the company may take a pre-authorization from the customer to charge the customer using any payment mechanism including, but not limited to, credit card, debit card, debit bank account, third party payment service provider, advance payment by the customer, any other means, or combination thereof.
  • the company may award the upgrade to the customer only if the company receives a payment from the customer in relation to said upgrade.
  • the customer may be required to pay one or more prices at one or more times to receive the option for the upgrade.
  • the company may award the upgrade to a selected group of customers based on any criteria of company's choosing. For example, a company may choose to give preference to its frequent buying customers or high value customers over others.
  • the UPO VOF may also confer a right on the customer to enforce said upgrade provided at least one condition on said option is satisfied.
  • a company may offer UPOs with preference orders attached to it, i.e., if a customer purchases (or receives) a UPO with a preference order of 1, said customer shall have the right to be the first customer among others to be awarded the upgrade.
  • a right is conferred upon the customer to enforce the company to award the upgrade to the customer if Up Product is available at a certain time as per the terms and conditions of the option contract.
  • the UPO VOF may also impose a condition on the company to offer the Up Product to the customer and the customer may have the right to choose between the Base-Product and Up Product and subsequently notify the company about the Chosen Product.
  • a customer may or may not be under a mandatory condition to accept the Chosen Product as selected by the company.
  • the company or the customer may have the right to enforce the Chosen Product on the other party as per the terms and conditions of the option contract.
  • the Box 16.200 illustrates an example of the Initial Transaction between the customer and a company, where the company offers the UPO value option to the customer.
  • a customer may be required to pay a price ($X) to receive said option for an upgrade from the Base-Product to the Up Product, and to agree to pay another amount ($Y) to the company if the company (then or later) upgrades the customer to the Up Product.
  • a company may choose to create one or more instances of the UPO VOF based on factors including, but not limited to, number of UPO Products, Up Products or Released Products, pre-determination of a number of Up Products or Released Products, other factors or any combination thereof.
  • UPO based on a combination of the number of UPO Products (or m) and Chosen Products (or n) would be UPO (m, n).
  • Some UPO instances are shown in Boxes 16.120, 16.130, 16.140 and 16.150.
  • the UPO (2, 1) instance the customer selects two UPO Products and the company may select any 'one' of those two Products as the Chosen Product. If the number of Chosen Products is pre-determined, the UPO (4, 2) instance may imply that the customer receives 4 UPO Products, on the condition that the company may select any 2 out of 4 Products as Chosen Products.
  • the UPO (4, 2) instance may imply that the customer receives 4 UPO Products, on the condition that the company may select none, one or 2 Chosen Products out of UPO Products.
  • n There may also be a minimum limit on n.
  • such UPO VOF implementations may also have price conditions to the customer.
  • a customer receives a UPO to receive two out of any four selected UPO Products, consisting of two Base-Products, Bl and B2, and two Up Products, Ul and U2.
  • the customer has made an Initial Payment of $1000.
  • the company may define any two products as Chosen Products out of the 4 products as per the terms and conditions of the option contract.
  • Ul or U2 or both is (are) defined as the Chosen Product(s)
  • the customer is required pay $50 or $100 or $200 as the UPO Exercise Price, respectively. If neither Ul or U2 (i.e.
  • the Initial Transaction may have terms and conditions applicable to the customer or the company or both. These terms and conditions may be set, preferably, to concurrently benefit both parties.
  • the connections between Box 16.200 and 16.220, and Box 16.200 and 16.210 refer to the terms and conditions to the company and the customer, respectively.
  • the UPO VOF may or may not include any constraints on the UPO Products.
  • a company may restrict UPO applicability and availability on Products that satisfy specific criteria.
  • the two UPO Products may or may not include practically constrained Products.
  • Practical constraints may include one or more constraints that will prevent a customer to utilize a given Product or prevent the customer from utilizing all the UPO Products. Such constraints may include, but are not limited to, time constraints, location constraints and so forth. In other words, it may or may not be practically possible for a customer to utilize both the selected Products due to at least one practical constraint.
  • a customer may select (or receive) UPO Products in several ways; through mutual agreement (e.g., during a direct interaction such as a Product purchase), or the company may grant the UPO Products to the customer without soliciting their interest or permission.
  • a company may grant UPO Products to customers based on the past customer behavior, interaction and so on.
  • the Initial Transaction may impose one or more conditions on the company.
  • a company may be required to explicitly notify the customer prior to or no later than a given date and time (referred to as the Notify Deadline) regarding the Chosen Product. If there is no such explicit notification condition, the Chosen Product may be decided as per the terms and conditions of the option contract.
  • the date and time when the selection of the Chosen Product is notified to the customer is referred to as the Customer Notification Time (or CNT, in short).
  • CNT Customer Notification Time
  • the explicit notification condition is assumed unless specifically mentioned otherwise.
  • the Notify Deadline may be pre-determined or may be determined later (i.e., after the Initial Transaction) by the company, the customer, any other entity, or any combination thereof.
  • a company may determine one or more Notify Deadlines for a product at one or more times (e.g., before, during, after the Initial Transaction or any combination thereof) using factors including, but not limited to, customer needs, expected value of the product, company profitability goals, any other factors or any combination of the above. Customer factors should also be considered in determining the Notify Deadlines, such as the flexibility trade-in periods desired by customers, or any other factor that may affect the behavior of a customer.
  • the Notify Deadline may be pre-determined or may be determined later (i.e., after UPO grant) by the company, the customer or mutually by both.
  • the terms and conditions of the UPO VOF may not allow the company to notify the customer after the last Notify Deadline (i.e., the latest among the Notify Deadlines).
  • flexibility may also be provided to the customer to notify the company about the Chosen Product up to a stipulated Notify Deadline, once the company has offered the Up Product to the customer.
  • a rule may be set that if the company fails to notify the customer before the last Notify Deadline, the Base-Product becomes the Chosen Product and no upgrade is provided to the customer.
  • Another approach may be set that if the customer fails to notify the company about the Chosen Product once the upgrade has been offered to him/her by the company, one or more of the Base-Products, Up Product and/or any combination thereof may be considered as the Chosen Product.
  • the company may select Up Product as the Chosen Product and may charge Exercise Price and/or any other price to the customer.
  • the company may select the Base-Product as the Chosen Product and a price may or may not be charged. Any entity (e.g., the company or the customer) may (or may not) be allowed to change the Default Product once it is selected.
  • the UPO Exercise Price (if any) in the default case may or may not be equal to the UPO Exercise Price for the Default Product for the last Notify Deadline. In the current discussion, a single Notify Deadline is assumed.
  • the customer may be required to pay one or more prices during the Initial Transaction (and/or to receive a UPO, referred to as an Initial Price), at the CNT (and/or the time the customer is upgraded, referred to as an Exercise Price) and/or at any other time, which may or may not be pre-determined between the customer and the company.
  • the UPO Price may be a pre-agreed fixed amount or it may be variable with or without bounds and set later or any combination of the above.
  • the initial price and/or the exercise price may or may not be uniform for all UPOs designed and/or offered to the customers; a company may choose any combination of uniform and/or non uniform prices for the initial and/or exercise price.
  • the company may offer the customer a set of prices to choose from. Since price conditions may depend upon various factors, which may or may not be variable, the same may be decided at anytime.
  • the price conditions may be determined by the customer, the company, another entity, or any combination thereof at one or more times.
  • One or more prices (UPO Initial or UPO Exercise or any other price) may be a negative value, which reflects that instead of the customer paying the company, the company shall pay a price to the customer to get the desired Product as the Chosen Product.
  • UPO prices may be embedded with the Product Price.
  • a customer may be presumed to accept the UPO offer while displaying the embedded Product Price. These presumptions may (or may not) include soliciting prior interest of the customer regarding the UPO offer.
  • the UPO price is merged with the Product Price, and where such price may or may not be separately identifiable, the customer may or may not receive a separate price for UPO.
  • the UPO Price(s) may or may not be embedded within the Product Price.
  • the customer may make the payment directly or indirectly (e.g., through a third party) to the company in relation to said upgrade.
  • the price may consist of a monetary value or a soft/non-monetary value (e.g., coupons, discount vouchers, other benefits such as loyalty program benefits, exchange of another service) or other consideration or any combination of the above.
  • a price may include, but is not limited to, a set of one or more Product prices, a set of one or more UPO Prices (initial and/or exercise) or any combination of the above.
  • a company may choose to implement UPO Prices in many ways. A company may use the method of its choosing to decide on all the Product prices.
  • the UPO Price (Initial, Exercise, and/or any other price, or any combination thereof) may be a function of number of UPO Products and/or Chosen Products, specific products to be granted for UPO Products, Up Products and/or Chosen Products, Notify Deadline, one or more Product prices, any other factors of company's choosing or any combination of the above.
  • Various option pricing strategies may be employed.
  • a user may be shown only one fixed price for the option. If the user purchases the option at a price much lower than his/her maximum price, the potential benefit for the company is less than what could have been achieved.
  • the above said pricing strategy limitation is removed when a bidding process is used. Bidding may help to determine the highest price a user is willing to spend for the upgrade. In bidding, while buying the UPO Option, the user may provide his/her highest offer for the final price. At the time of upgrade, if available, the company may charge the lowest price (less than the highest offer price selected by the user) that delivers the upgrade to the user. If even the highest offer price chosen by the user is lower than the minimum price needed to get the upgrade, then the user is not awarded the upgrade.
  • the highest offer may be input free form or the company may provide a few choices from which the user may select one.
  • the company may also ask, or determine empirically, how much customers will pay for the option. The assumption here is that customers make a logical decision to choose the Up Product and can afford to pay the sum of the initial and the exercise prices (if any).
  • the customer may or may not have to pay during the Initial Transaction.
  • Initial Price may be subsequently returned to the customer, if the upgrade to the Up Product is not awarded to the customer.
  • Exercise Price may also be adjusted with the Initial Price paid by the customer.
  • the company may issue a UPO Pass for the customers in order to facilitate another payment mechanism.
  • the payment for the product and/or the option may be made using the UPO Pass. It may be possible while purchasing a set of one or more UPOs or a UPO Pass, there may be one or more conditions (e.g., such as time based or value based UPO Pass) that limit the applicability of the UPOs.
  • a time based UPO Pass may allow a customer to only be upgraded on the products that may be purchased (received) or utilized within a specified time period.
  • a value based UPO Pass may allow a customer to get upgrades until the sum of the total payment needed for all the upgrades is less than or equal to the value of the UPO Pass.
  • the company and/or another entity may create various types of UPO Pass.
  • the payment transaction may include, but not limited to, direct payment received by the company from the customer, in lieu of relinquishment of one or more rights by the customer, indirect revenue generation (e.g., the customer relinquishes his/her right for an associated product or service, thereby allowing the company to use said associated product or service for revenues or use for other purposes), costs savings obtained (e.g., the customer relinquishes his/her right to services which saves costs for the company), enhanced customer service and loyalty and so forth.
  • direct payment received by the company from the customer in lieu of relinquishment of one or more rights by the customer
  • indirect revenue generation e.g., the customer relinquishes his/her right for an associated product or service, thereby allowing the company to use said associated product or service for revenues or use for other purposes
  • costs savings obtained e.g., the customer relinquishes his/her right to services which saves costs for the company
  • enhanced customer service and loyalty and so forth e.g., enhanced customer
  • each said event may be associated with various terms and conditions on the customer and/or the company.
  • the company and/or the customers may have the right to enforce the Chosen Product(s) on the other party as per the terms and conditions of the option contract.
  • the terms and conditions of the option contract may be binding on the company and the customer only if the customer successfully accepts the company's offer of the option for the upgrade. The customer may be given a choice of options to choose from and take a decision.
  • the company may implement negative UPO, i.e., instead of upgrading the customer to an Up Product, the company may downgrade the customer to a lower ranked product.
  • the company may implement such negative upgrade in one or more situations.
  • the company may implement negative upgrade (downgrade) when there may be huge demand for Up Products at very high prices so that the company may downgrade the customer who may have already bought the Up Product at relatively lower prices and may be willing to accept the lower ranked product in lieu of some or more rewards.
  • the company may implement it in case there is huge demand for lower ranked product.
  • the company may offer the Up Product to the customer and may give an option to downgrade to lower ranked product in future in case one becomes available.
  • the company may offer discounts on higher ranked products, may offer to return the difference between the lower ranked product and higher ranked product, may offer additional reward to the customer and so forth.
  • the company may be able to retain the customer (and not to lose him/her to the competitor) even in the event that the customer is desiring a lower ranked product and the capacity of which may be exhausted with the company.
  • the company may also be successful in this case in creating a flexible pool of customer inventory.
  • the terms and conditions of the UPO VOF may require the customer to purchase (or pay price for reserving) both the lower ranked and higher ranked products with a condition to cancel/return either of the two products as per the terms and conditions of the option contract.
  • a customer reserves a higher ranked product for $1000 (when its actual price is $2200) and a lower ranked product for $705 (when the actual price is $720) with a condition to return at least one of the products.
  • the customer has paid $1705 for reserving both the products with a condition to cancel the reservation for at least one of them.
  • the terms and conditions of the option contract may provide different cancellation charges in different situations.
  • the terms and conditions of the option contract provides cancellation charges for higher ranked product as $18 where as the same for lower ranked product are $1000. So, logically the customer will go for cancellation of higher ranked product and in this case he would be refunded $982 and hence the net amount paid by the customer for getting the lower product would be $723 ($1705 minus $982) which may be equal to the Product Price ($720) plus Initial UPO Price ($3). In this case, the customer has not received the upgrade. Now, consider another case when the higher ranked product is available. The terms and conditions of the option contract provide cancellation charges in this case for higher ranked product as $2000 where as there is no cancellation charges for cancelling the lower ranked product.
  • the customer will cancel the lower ranked product and hence he would be refunded $705. So, the net amount paid by the customer for getting the upgrade (i.e., the higher ranked product) is $1000 ($1705 minus $705) instead of paying the full price (of $2200) for getting the higher ranked product.
  • the assumption here is that customers make a logical decision to choose which product to cancel.
  • a UPO VOF may include a right for a company to upgrade the customer to an Up Product before a stated Notify Deadline.
  • the right may include the condition that the company may notify the customer before, at or after the stated Notify Deadline or any combination thereof.
  • the company may offer (or allow) the customer to finally choose the Chosen Product once the company notifies the customer about the availability of the Up Product.
  • the Initial Transaction i.e., once the option has been granted (and/or sold) to a customer, there may be one or more potential events related to the associated UPO option.
  • there are two related events (named Level 1 Events) for the UPO option namely, 1) Up Product is available at a certain time as per the terms and conditions of the option contract (shown in Box 16.250) and 2) Up Product is not available at a certain time as per the terms and conditions of the option contract, as shown in Box 16.240.
  • Level 2 or higher level events associated with the UPO option. If one or more Up Products are not given to the customers due to unavailability of Up Products in Level 1 events, the customer may be given one or more Up Products if said Up Products are available in Level 2 or higher events related to the UPO option, later on. It may also be possible that even when one or more Up Products are available in Level 1 event which may or may not be given to the customer in Level 1 event, still later on, in Level 2 or higher events, if one or more Up Products are available, said one or more Up Products may be offered (given) to the customers. Said one or more Up Products may be given by the company, another entity and/or by both. The Up Products given in Level 2 or higher events may be given in exchange of one or more previously given Up Products or in addition to the earlier given Up Product(s).
  • the company may use any method it chooses to allocate the upgrades, such as assigning priority based on time of purchase, Product Price paid by the customer, random selection or any other customer priority factors like high buying customer and so forth.
  • a company may inform the customer of the decision related to the upgrade award via any communication channel including, but not limited to, an email, phone, in-person at company's office or sales counter, or may ask the customer to contact the company to know the decision and so forth.
  • UPO Using UPO, a company gets to know the relative preferences and utilities of the higher ranked products over the lower ranked products as some customers purchase this option and others don't. This may lead to an enhanced revenue benefit for the company as well as higher product utility to the customer. There may be some increase in costs for the company, but generally, the additional revenue generated would be more than sufficient to account for the additional upgrade costs (if any).
  • the company may better optimize its product capacity and may possibly be able to sell the lower ranked products to additional customers due to additional capacity generated for the lower ranked products (after a customer is upgraded to the Up Product).
  • a company may estimate the total number of expected upgrades and using the same, may estimate the capacity generated in the lower ranked products (due to potential upgrades) .
  • UPO A customer who receives a UPO is termed "U".
  • Ua the status of said U customer is termed "Ua” (i.e., Accounted, which are one or more Base-Products or lower ranked products for the customer) and in the other UPO Product(s), the status is termed "Uw” (i.e., Awaiting, which are one or more Up Products or higher ranked products for the customer) (both Ua and Uw have been defined above).
  • Ua customer converts to an N customer after the CNT.
  • a company may have N, Ua and Uw type of customers for its products.
  • the UPO VOF may help a company in one or more ways. For example, it may help to accommodate product requests from potential customers. Any new potential customer who requests to obtain a product is assumed to be an N customer. If the available quantity for the desired product (desired by N customer) is insufficient to satisfy the request, then the company may use the quantity (if any, of desired product) that has been assigned to Ua customers, and reassign the same to said N customer. Consequently, the company may then upgrade (assign the Awaiting products, i.e., the products where said Ua customers have Awaiting status to) said Ua customers. By implementing such upgrading of Ua customers from their Accounted products to Awaiting products, a company may better serve incoming demand for products.
  • Bus_N An event where such request comes to the company for a product is termed "Buy_N”.
  • the act to upgrade a Ua customer from its Accounted product (Base-Product) to its Awaiting product (Up Product) is termed "Upgrade_U”.
  • Detailed algorithms are presented below that may be used to manage a system consisting of N, Ua and Uw type of customers.
  • An Upgrade_U algorithm may be run independently of the Buy_N Process and may be used only to upgrade the customers from one or more lower ranked products to one or more higher ranked products.
  • a company may choose any set of criteria to create different levels of its product offerings.
  • a company may choose to subdivide a physically distinct product into two or more sub products, where each sub product may act as a separate product level.
  • the costs, revenues, benefits and conditions shown here are for illustration purposes only and actual values could be different depending on specific values selected by the users for value options, customer behavior, company schedule, pricing, any other factor or any combination of the above.
  • UPO Types Creator Algorithm (to create UPO Types or instances)
  • Fig. 17 presents an example of an algorithm that may be used to create UPO Types or instances (sometimes also referred to as upgrade options or upgrade product options or UPOs or UPO) for a given set of products.
  • a starting point is to consider a list of products of a company, where each product can be ranked in terms of priority (or desirability) to customers.
  • a high priority usually implies a higher utility to the customer and is usually accompanied by a higher product price.
  • the following algorithm as shown in Fig. 17, demonstrates one way to calculate all possible UPO instances for such a set of products.
  • the algorithm uses a recursive loop mechanism.
  • a Set of products is taken as an input and sorted according to the descending order of priority. Priority may be determined in any way the company desires. It may be a subjective guess at customer desires or it may be based on empirical data, for example.
  • the Base-Product BP
  • CUP Collection of Up Products
  • a software routine is called, named herein, the "Option_Creator" routine. It receives the BP and CUP as input, and outputs a set of options, the Option Collection (or OC, in short).
  • the OC is initialized (for the current product level) as an empty set.
  • the BP is combined with each product in the CUP and the combination is added to the Option_Collection (OC), in Act 17.150.
  • the current CUP is assigned as the new SP, the BP becomes the lowest priority product in the new SP and the new CUP becomes the old CUP less the old BP, in Act 17.160.
  • Act 17.170 a test is performed to determine whether the CUP is an empty set. If so, control goes to Act 17.190. If not, to Act 17.180, in which the Option_Creator routine starting in Act 17.140 is called and new conditions are set (a new BP and a new CUP). When Act 17.190 is reached, the OC of the current level Option_Creator is returned to the next higher level of Option Creator from where the current Option_Creator was called and control passes to Act 17.200.
  • the BP of the current level Option_Creator is combined with each member in the returned OC from the lower level. These combinations are added to the OC of the current level.
  • the returned OC from the lower level is added to the OC of the current level.
  • a test is performed to determine if the current level of Option Creator is the highest. If so, the Option_Collection of current level is returned as the final output, in Act 17.230, and then the algorithm ends in Box 17.300. If not, then control goes back to the Act 17.190, where the Acts 17.190 to 17.220 are repeated for the new level of Option_Creator.
  • the computation may be performed using a processor that may calculate results in optimal time.
  • a financial analysis may be performed using the existing company and customer data to determine the optimal terms and conditions of the UPO VOF. 'What-if scenarios may be executed to determine an optimal pricing strategy.
  • the company may want to divide its customers using one or more criteria and design separate UPO VOFs for each customer segment.
  • Second Stage Using the UPO Value Option Framework
  • the company has created a UPO VOF and specific value options within that framework.
  • the company has also segmented customers and designed options accordingly.
  • the company is fully prepared to use a structured format consisting of one or more UPO value options to interact with its customers in real time to generate benefits for both the company and its customers.
  • the second stage of the UPO VOF is now presented.
  • the implementation of the UPO VOF between the company and its customer takes place through two high level acts, as shown in Fig. 18.
  • the 'Get UPO' process an interactive event between the customer and the company's web server, runs to carry out the Initial Transaction of the UPO VOF.
  • a number of algorithms may be executed (e.g. availability, UPO Price, Notify Deadline, Upgrade List and so on) on the company's server to optimally calculate the terms and conditions of the UPO VOF (e.g., availability, UPO Price(s) and other conditions) to concurrently benefit both the company and the customer.
  • an event optimizer process called the UPO Exercise Process (explained later) is executed.
  • the company may award the upgrade to the customer based on the terms and conditions of the option contract and the Chosen Product is notified to the customer.
  • the process may also consist of one or more event optimizer algorithms that may help to optimally select the Chosen Product and/or to optimally use (or reuse) the Released Product.
  • the Get UPO process may be implemented via the Sequential (shown in Fig. 19) or the Concurrent (shown in Fig. 22) process.
  • Sequential There are many ways to do the Sequential process.
  • a customer may select (or purchase) a Product/Set/Order before the Initial Transaction begins.
  • said Product/Set/Order may be referred to as Initial Product/Initial Set/Initial Order or IP/IS/IO, in short, respectively.
  • the Initial Set is also referred to as Initial Product Set (or IPS, in short).
  • a customer may get a UPO, i.e., get one or more UPO Products/Sets/Orders on an OP/OPS/OO, respectively.
  • a UPO Product/Set/Order is also referred to as Option Product/Option Set/Option Order, or OP/OS/OO, in short, respectively.
  • An Option Set is also referred to as Option Product Set (or OPS, in short).
  • the two events one for the Initial Product and the other for the Initial Transaction
  • the UPO VOF may be implemented at different levels including, but not limited to, Product, Set and Order.
  • a company may choose to implement the UPO at any level(s).
  • the implementation level should be the same for all the UPO Products, Chosen Products and Released Products. For example, if UPO is implemented at the Order level, then all the UPO Products and Chosen Products would refer to UPO Orders and Chosen Orders, respectively.
  • a customer interacts with the company's server to receive a UPO.
  • the interaction may take place (for example) via phone, in-person or on a website.
  • the Sequential Get UPO Process is presented first along with its detailed algorithms, followed by a short summary of the Concurrent Get UPO Process.
  • Sequential Get UPO Process when a UPO is implemented at the Set level. It is also assumed here that the customer first purchases an Initial Order with one or more IPS, and then opts to receive a UPO on any of the included IPS.
  • Act 19.140 a test is performed to determine whether the customer wants to get more OPSs on the current Target Set or on another IPS. If the customer wants to get an OPS on another IPS, control loops back to the Act 19.110, where the customer selects another IPS as the Target_Set, and then the process is repeated again for the new Target Set. If the customer wants to get more OPSs on the current Target_Set, control loops back to Act 19.115, where the customer enters the OPS search criteria and then the process is repeated for the new OPS search criteria. If the customer does not want to get any more OPSs, control goes to Act 19.150, where a payment transaction (if needed) may be executed.
  • a customer may need to pay a price for the Product after taking into consideration the Initial UPO Price using a credit card, direct bank account debit or any other payment transaction mechanism.
  • the algorithm ends in Box 19.200.
  • the computation may be performed using a processor that may calculate results in optimal time.
  • the UPO Search algorithm at the Product level is shown in Fig. 20, which expands the Act 120 of Fig. 19.
  • Act 20.100 a set of parameters including the number of customers (IC), the Target_Product and the UPO Search parameters are input to the system.
  • the number of customers refers to those customers for whom this process is being executed.
  • the UPO search parameters include, but are not limited to, Up Product, price of the Up Product, UPO Price and so forth.
  • control goes to Act 20.110, where a list of UPO Types (or upgrade options) for the given Target_Product is read from the company's database. All the upgrade options, thus obtained, are added to a list termed LIST_Option.
  • a list of UPO validation rules is obtained from the company's UPO VOF database and applied to validate all the upgrade options in the LIST_Option list. The ones that do not satisfy the rules are discarded.
  • Validation rules may include, but are not limited to, a Maximum Number of Products per Set Rule, a Maximum Product Price Rule, an Availability Rule and so forth. For example, a Maximum Product Price Rule may discard those upgrade options for which the Product Price of the Up Product related to the upgrade option is more than a specified value..
  • a company may implement any of the validation rules to further qualify the options in the LIST Option list.
  • the first element in the updated LIST_Option list is set as the Current_Option.
  • control goes to Act 20.125, where a group of Comb_NDs is computed for the combination of the Target Product, all the existing options of the Target_Product and the Current_Option, and added to a set called Comb_ND_Set.
  • Act 20.130 a test is performed to determine whether the Comb_ND_Set obtained in the previous Act is Null. If so, control goes to Act 20.150. If not, control goes to Act 20.135, where the UPO availability and UPO Price for the Comb_ND_Set are determined.
  • Act 20.140 another test is performed to determine whether the UPO Availability or the UPO Price is Null. If so, control goes to Act 20.150. If not, control goes to Act 20.160.
  • Act 20.150 the Current OPS is discarded from the LIST OPS list, and control goes to Act 20.160, where a test is performed to determine if more elements are left in the LIST OPS list. If so, control goes to Act 20.165. If not, control goes to Act 20.170.
  • Act 20.165 the next element in the LIST_Option list is set as the Current Option and control loops back to Act 20.135 for further processing of the new Current Option.
  • Act 20.170 the updated LIST Option list along with UPO Prices and associated conditions for each option is returned as the search result, and then the algorithm ends (Box 20.200).
  • the computation may be performed using a processor that may calculate results in optimal time.
  • the following algorithm determines and validates an OPS for a given set of conditions including, but not limited to, availability, Notify Deadline and UPO Price. Said algorithm has already been discussed above in a more generic sense along with one of the ways of its implementation along with various information technology and networking tools including, but not limited to, one or more servers, database, load balancers, firewall, routers, Internet, highly secured VPN, Intranet, RAM, hard disk drives, CPUs, monitors as shown by Fig. 13D.
  • the number of customers (IC), IPS Set (containing all IPS in the Initial Order, and all the OPSs, (if any) already selected/received along with Comb_ND_Set(s) and Comb_OP_Set(s), for each IPS), Target IPS and the OPS Search parameters are input to the system.
  • the definitions and details of Comb_ND_Set and Comb_OP_Set are provided later.
  • the OPS search parameters include, but are not limited to, date, time and location, number of Products per Set, Notify Deadline, UPO Price (Initial and Exercise) and so forth.
  • a customer may be allowed to input Notify Deadline and/or UPO Price on the basis of which valid OPSs (that satisfy the given criteria of Notify Deadline and/or UPO Price) may be searched for and displayed for the customer. For example, a customer may be asked to input the product related parameters, and then a set of Notify Deadlines and UPO Prices may be computed for the products that match the given criteria. In another example, a customer may input both product related parameters and Notify Deadline and/or UPO Price as inputs and then a search may be performed for valid OPSs.
  • a customer may input to the system, one or more products, and/or inputs to search for one or more additional products (e.g., product properties, price etc.) to search for OPS that may be combined with one or more input products (by the customer) to constitute the total set of products for a UPO.
  • a company may also validate the products input by the customer to determine if said products are eligible to be the UPO Products.
  • the search may be best performed using a processor that may calculate results in optimal time.
  • the order in which search parameters are executed may be optimized to reduce the search time, however, it may or may not affect the final outcome.
  • a company may select any order of its choosing.
  • control goes to Act 21.130, where a group of Comb NDs is computed for the combination of the Target lPS, all the existing OPS of the Target_IPS and the Current OPS, and added to a set called Comb_ND_Set.
  • Act 21.135 a test is performed to determine whether the Comb_ND_Set obtained in the previous Act is Null. If so, control goes to Act 21.155. If not, control goes to Act 21.140, where the UPO availability and UPO Price for the Comb ND Set are determined.
  • Act 21.150 another test is performed to determine whether the UPO Availability or the UPO Price is Null. If so, control goes to Act 21.155. If not, control goes to Act 21.160.
  • the next element in the LIST_OPS list is designated as the Current_OPS and control loops back to Act 21.130 to repeat the process for the new Current_OPS.
  • the updated LIST OPS list along with UPO Prices and associated conditions is returned as the search result, and the algorithm ends (Box 21.200).
  • the computation may be performed using a processor that may calculate results in optimal time.
  • a company may set one or more Notify Deadlines of its choosing for its Products. Once the Notify Deadlines have been set for each Product, the next Act is to create a framework to compute the Notify Deadlines, for a group of Products (such as a Set, an Order or any other group).
  • a framework to compute the Notify Deadlines, for a group of Products (such as a Set, an Order or any other group).
  • the following sections present an example of a framework that may be used to obtain a set of Notify Deadlines applicable to a group of Products.
  • a company may use any framework and algorithm of its choosing to obtain the same.
  • a set of Notify Deadlines associated with a Product, a Set and a combination of two or more Sets is called Product ND Set, Set ND Set and Comb ND Set, respectively.
  • Each element in the Product ND Set, Set ND Set and Comb_ND_Set is termed Product ND, Set ND and Comb ND, respectively.
  • the Comb ND Set may be computed by combining the Set_ND_Sets of all the given Sets.
  • a Set_ND_Set may be computed by combining the Product_ND_Sets of all the Products under that Set.
  • the Notify Deadlines can be computed based on various parameters and factors of the company's choosing.
  • One example to compute a Comb_ND_Set is as follows. First compute Set ND Set for all Sets.
  • a Set ND Set is computed by first selecting earliest of the Notify Deadlines of each Product within the concerned Set, and then picking the latest of those Deadlines, and noting that as the Target Deadline. Next step is to pick all those Notify Deadlines that fall after the Target_Deadline. Notify Deadlines thus obtained may be validated using various validation rules based on company factors such as customer utility, product parameters and so forth. Similarly, the Comb_ND_Set may thus be computed by repeating the above process for Set_ND_Sets, thus obtained for each Set.
  • the UPO capacity for an OPS may depend on one or more factors including, but not limited to, Notify Deadline, UPO Prices, expected Product value and so forth.
  • a company may use any method of its choosing to determine UPO capacity of a product. For example, a company may choose to have a fixed UPO capacity for one or more of its products.
  • UPO Capacity is dependent on Notify Deadline.
  • the objective is to determine those Comb_NDs within the Comb_ND_Set on which UPO is available for the given OPS.
  • the UPO Capacity and the Used UPO Capacity (the total number of Products on which UPO has been sold but not exercised) may be calculated for each Comb ND within the Comb ND Set.
  • Available Capacity (AC) would then be the difference of UPO Capacity and Used UPO Capacity for the given Product. If the AC is greater than or equal to the number of incoming customers desiring a UPO, then the UPO capacity is available at a given Comb_ND for the given OPS. The process may be repeated for all Notify Deadlines within Comb_ND_Sets.
  • UPO may be made available on a given OPS for a given Comb ND, if UPO is available on all the Products of OPS for the given Comb_ND.
  • UPO Price Calculation A company may set UPO Prices for a Product using any method of its choosing. Once the UPO Prices have been set for each Product, the next Act is to create a framework to compute UPO Price for a group of Products (such as a Set, an Order or any other group) by using UPO Prices for each Product in the group.
  • the parameter Product OP refer to UPO Price (and may or may not be corresponding to a Notify Deadline) associated with a Product.
  • Set_OP and Comb OP refer to UPO Price (may or may not be corresponding to a Notify Deadline) associated with a Set and a combination of two or more Sets, respectively.
  • a set of Product_OPs, Set_OPs and Comb_OPs is termed Product_OP_Set, Set_OP_Set and Comb_OP_Set, respectively.
  • the Comb_OP_Set is computed by combining the Set_OP_Sets of the IPS and all the OPSs (existing and new).
  • a Set_OP_Set is computed by combining the Product_OP_Sets of all the Products under that Set.
  • One or more Set_OP_Rules may be read from the company's database and applied to calculate Set_OP_Set for each input Set (IPS and all OPSs) using the Product_OP_Sets of all the Products of said Set.
  • a company may use any Set OP Set Rule of its choosing.
  • Set OP Rules may be defined to calculate Set OP as the sum, average, highest, lowest or any other function of Product OPs of all the Products at a given Comb ND.
  • a Comb_OP_Set consists of one or more Comb OPs, and is calculated using one of the pre-determined rules, termed Comb_OP_Rules, to combine the Set_OPs of all the Sets in the combination.
  • a company may use a Comb_OP_Rule of its choosing.
  • Comb_OP_Rules may be defined similar to the Set_OP_Rules.
  • a customer receives all UPO Products concurrently in one transaction.
  • An algorithmic illustration of the Concurrent Get UPO process is displayed in Fig. 22.
  • the UPO (2, 1) instance is assumed here as an example.
  • the customer desires for UPO are input, including, but not limited to, a search criteria for two Sets according to customer's utility (may be similar to the search criteria defined above for the Sequential Get UPO process).
  • the UPO algorithm is run to determine the combinations of two Sets that satisfy inputs.
  • a list of such search results is displayed for the customer along with the associated terms and conditions including, but not limited to, Notify Deadlines, Initial UPO Price, UPO Exercise Price and Product Price for each such combination.
  • the UPO algorithm for the Sequential Get UPO process (defined above) may also be used for the Concurrent Get UPO process.
  • Act 22.120 the customer selects a desired combination of two Sets and the associated conditions such as UPO Exercise V ⁇ ce/Notify Deadline.
  • Act 22.130 a payment transaction is executed, if needed. For example, the customer may pay the Product Price after taking into consideration the Initial UPO Price using a credit card, direct bank account debit or any other payment transaction mechanism.
  • the algorithm ends in Box 22.200. The computation may be performed using a processor that may calculate results in optimal time.
  • the processing goes to the Event Optimizer phase where different acts are executed depending on the trigger event that may occur to make an option to become exercisable.
  • the UPO Exercise Process (and customer notification (or CN, in short) process) as shown in Act 18.200 is executed.
  • the UPO Exercise Process and customer notification (or CN, in short) process
  • Act 18.200 is executed.
  • one or more decisions on the selection of Chosen Product(s) is notified to the customer.
  • the event(s) is (are) related to the value option selected in the first act.
  • the company may use a software application built on the method defined above to optimally award the upgrades to customers who have bought a UPO. Few methods have been described below in detail for the UPO Exercise process.
  • Event Optimizer stage with the help of information technology tools has already been discussed above in a more generic fashion wherein said tools include, but are not limited to, one or more servers, database, load balancers, firewall, routers, Internet, highly secured VPN, Intranet, RAM, hard disk drives, CPUs, monitors as shown by Fig. 13E.
  • said tools include, but are not limited to, one or more servers, database, load balancers, firewall, routers, Internet, highly secured VPN, Intranet, RAM, hard disk drives, CPUs, monitors as shown by Fig. 13E.
  • the UPO VOF helps to create a flexible customer inventory.
  • a company may obtain rights to allocate any of the selected UPO Products to a UPO customer (i.e., award the upgrade to the customer), and thus, said UPO customer acts like a flexible customer inventory that the company may manage to generate revenues.
  • a company may design one or more uses of such flexible customer inventory, where each such use may include one or more events that follow the Initial Transaction.
  • An example (the Buy_N process) was explained earlier.
  • the Buy_N process a company may use the UPO VOF to accommodate requests from potential customers for products.
  • the Buy_N process may especially be used to satisfy requests for products that have already been sold or have low (or no) availability. The details for the Buy N process are presented below.
  • UPO the Alternate Product Option
  • a company may form a group of one or more APO customers and one or more UPO customers, where the options (APO and UPO) obtained by the group members are complementary in nature.
  • a customer (A) who bought an APO to choose either of Pl and P2 as Chosen Product and consider a customer (B) who received a UPO and wants an upgrade from Initial Product (i.e., Base-Product) Pl to Option Product (i.e., Up Product) P2 as Chosen Product.
  • the company may upgrade B and assign P2 as the Chosen Product for B, and vice versa.
  • the customers A and B have taken complementary options and may form a group.
  • the company may need to hold only one unit of inventory in Pl and P2 to satisfy the needs of both A and B (assuming each A and B only need one unit of product).
  • Such a combination of complementary options or VOFs may improve efficiency and concurrently enhance value for all the parties involved (in the given example, for A, B and the company). More details on combining VOFs are provided later.
  • the UPO VOF may also be used to reduce operational costs, constraints or other goals that are impacted by the allocation of products among different customers.
  • the UPO VOF may be used to shave off production costs by reducing production capacity for one or more products that are low in demand. For example, if a company experiences a product with very low sales, it could offer UPO to customers on that product and thus, be able to economically and efficiently upgrade them to different products and thereby be able to cancel production of said product to save its production costs (such as operational costs, staffing costs, maintenance costs and so forth).
  • the company may use UPO Exercise Process as one of the methods to create a system and computer-implemented process to optimally award the available products as upgrades.
  • This method helps to find an optimal upgrade solution to create a win-win situation between the customers and the company.
  • the method may have two or more Acts.
  • the UPO Exercise Process has two Acts, the Upgrade List and the Upgrade Award.
  • the Upgrade List process may use a set of rules to generate a list of upgrade enabled customers.
  • the Upgrade Award process may award upgrades to one or more upgrade enabled customers based on the defined conditions. Tt may be noted, however, that technically, the UPO Exercise process may be performed using any rule/method as desired. The following process may help to optimize (increase) the benefits generated. Fig.
  • the UPO Exercise process starts with an input of a product on which the UPO Exercise process is supposed to be executed, as shown in Act 23.100.
  • Act 23.110 based on predefined times to run the Upgrade List and the Upgrade Award, a test may be performed to determine whether it is time to run the Upgrade List or the Upgrade Award process. If it is time to run the Upgrade List, the scheduler triggers the Upgrade List process, as shown in Act 23.120. If it is time to run the Upgrade Award, the scheduler triggers the Upgrade Award process, in Act 23.130.
  • a company may set one or multiple times to execute the Upgrade List and/or the Upgrade Award processes to maximize the total returns for the company and to push the UPO Exercise process as close to the utilization as possible.
  • the company may generate, at least one Upgrade List before the first Upgrade Award is executed, and at least one Upgrade Award process may follow every run of the Upgrade List process. The details on both Upgrade List and Upgrade Award processes are presented later in the document.
  • Act 23.120 or Act 23.130 control goes to Act 23.140, where a test is performed to determine if any future scheduled runs are pending for either the Upgrade List or the Upgrade Award. If so, control loops back to Act 23.110 for further processing as per that Act. If not, the algorithm ends at this point, in Box 23.200.
  • the computation may be performed using a processor that may calculate results in optimal time.
  • Both Upgrade List and Upgrade Award processes may be run multiple times before the product utilization (anytime starting from the first interaction between the company and customer to the time the product is fully utilized). It may be beneficial for the company to run the UPO Exercise process as close to the utilization of the product as possible. This may help in two ways. First, it may help the company to prevent any form of potential revenue dilution from last minute walk-in customers who may potentially pay higher Product Price for the Option Products. Second, it may help to use all the unused products that may become available at the last minute because of cancellation.
  • Upgrade List The following terms and definitions are needed to understand the algorithm to create an upgrade list: UPO Type, upgrade value and upgrade combination. These terms are presented first followed by the Upgrade List algorithm.
  • UPO Type is simply the UPO bought by the customer.
  • UPO Type is simply the UPO bought by the customer.
  • UPO Type is simply the UPO bought by the customer.
  • UPO Type is simply the UPO bought by the customer.
  • UPO Type is simply the UPO bought by the customer.
  • UPO Type is simply the UPO bought by the customer.
  • UPO Type is simply the UPO bought by the customer.
  • UPO Type is simply the UPO bought by the customer.
  • UPO Type For customers who are in 'regular' (non-option) upgrade programs, there is a need to determine their UPO Types.
  • To determine the UPO Type one may need to determine all the Up Products to which a customer can be awarded an upgrade.
  • the list of such Up Products may be compared with the list of Up Products associated with all UPOs.
  • the UPO whose Up Products match is the UPO Type for said customer.
  • BU1U2 is the UPO Type for said customer.
  • the UPO Types for other customers may be determined in a similar fashion.
  • the company may define UPO Type for standby customers, in the industries wherever applicable.
  • the following describes one of the methods to treat standby customers just like confirmed customers to maintain the uniformity in processing the UPO Exercise algorithm.
  • a standby customer here, may be defined as a customer who currently does not have a confirmed product, but is waiting to get confirmation for that or other products, whereas the confirmed customers have confirmed orders for said product.
  • a new dummy product, Standby (or S, in short), may be assumed and all the standby customers may be treated to have the confirmed dummy product (S), which may then be added to the list of products.
  • S confirmed dummy product
  • B Base-Product
  • Ul Up Products
  • U2 Up Products
  • U2 User
  • U2 Up Products
  • a Set with B, Ul and U2 products, would have a new list of products in descending priority, U2>U1>B>S.
  • a customer may be on a standby list for one or more products of a Set or on one or more products of different Sets and/or any combination thereof.
  • the customers in the S product may be assigned the UPO Types, as follows; SC refers to the UPO Type for a standby for Base-Product (B) only, SUl refers to the UPO Type for a standby for Up Product (Ul) only, SU2 refers to the UPO Type for a standby for Up Product (U2) only, SU1U2 refers to the UPO Type for a standby for Up Product (Ul) and Up Product (U2), SBU2 refers to the UPO Type for a standby for Base-Product (B) and Up Product (U2), SBUl refers to the UPO Type for a standby for Base-Product (B) and Up Product (Ul) and SBU 1U2 refers to the UPO Type for a standby for Base-Product (B), Up Products (Ul) and (U2). If a company wants to employ the above mechanism to create a dummy product for standby customers, it may be beneficial to include the virtual standby product in the list of
  • Upgrade Value may be defined as the total value a company may realize by upgrading a customer from a given Base -Product to a given Up Product. Upgrade Value may be expressed, as follows,
  • Upgrade Value Payment + Soft Value — Upgrade Cost
  • the term 'payment' refers to the price paid by the customer to the company when he/she is awarded an upgrade from the Base-Product to the Up Product.
  • 'Soft Value' refers to a combination of any indirect and/or intangible value a company may generate when a customer is awarded an upgrade from the Base-Product to the Up Product.
  • 'Upgrade Cost' refers to the marginal upgrade cost (if any) to a company to upgrade the customer from Base-Product to an Up Product.
  • Said "Soft value” may be based on various factors and parameters including, but not limited to, company's past experiences with the customer, the number of times said customer has or has not received an upgrade in last 'n' number of attempts, customers who require special attention or care, customers belonging to a certain category, other privileged customers for one or more reasons and so forth.
  • a company may use the final exercise price as the "payment" portion of the upgrade value.
  • the soft value for the UPO customers may be calculated using one or more functions of the long term value of the customer to the company, trip parameters, upgrade path and so forth.
  • a company may use any mechanism or methodology to calculate the upgrade value of the UPO customer.
  • the upgrade value may be calculated for the customers in the 'regular' (non-option) upgrade programs and the standby customers.
  • the 'payment' portion of the upgrade value may be zero, however, their 'soft value' may be high.
  • the payment portion may be calculated as follows,
  • the Product Price refers to the total Product Price the standby customer is expected to pay to the company if he/she is awarded the desired product.
  • the term "Recapture Probability” refers to a probability that a standby customer may be assigned another product in another Set of the same (or different) company so that the company, in concern, does not lose the potential revenue from the standby customer if the customer is not awarded the desired product.
  • a company may calculate recapture probability by any method of its choosing.
  • a company may choose to use any other mechanism to determine the upgrade value for one or more customers in the input list.
  • the computerized system (built using the method defined here) may also allow manual overrides by the company user (e.g., an analyst or an agent) to allow the user to allocate special upgrade values to satisfy the customer relations objectives (for e.g. enhance chances for some elite customers to get upgrades over other customers) or for any other reasons, that may include enhancing or reducing the soft values of customers to modify their chances to get upgrades, however, while maintaining the conditions of the options contract executed with the UPO customers.
  • An upgrade combination may consist of one or more members sorted in an order, and may need only one available product for its topmost member to generate an upgrade for all its members.
  • the topmost member has the highest Up Product associated among all the members in the combination.
  • the award of upgrades for an upgrade combination may work in a cascading style, where a new available product allotted to the combination may be awarded to its topmost member, the product vacated by the topmost member (after his/her upgrade) may be awarded to the second (next) topmost member and the chain goes on until the product vacated by the second lowest member is awarded to the lowest member.
  • a product and a list of customers to be upgraded is taken as an input along with the UPO Type and the upgrade value for each customer.
  • the input list of customers may include all customers who have bought any type of UPOs.
  • This list may also include the upgrade-enabled customers in the other regular upgrade programs (e.g., loyalty program, elite, staff or corporate program).
  • a company may also want to include the standby customers in the Exercise UPO process to optimize a desired objective function across all customers. For example, a company may desire to optimize the total revenue by optimally allocating the available products among the UPO customers, the regular upgrade customers and the standby customers.
  • the UPO Types and the upgrade values are taken as an input for each customer in the input list.
  • Act 24.110 a list of all types of upgrade combinations for the input product is read from the company's database. An algorithm to create different types of upgrade combinations for a list of products is presented later.
  • the following algorithm as shown in Fig. 25, demonstrates one of the ways to calculate all the types of upgrade combinations for a given set of products.
  • the algorithm uses a recursive loop mechanism.
  • a Set of Products is input and sorted according to the descending order of priority. Priority may be determined in any way the company desires. It may be a subjective guess at customer desires or it may be based on empirical data, for example.
  • UP a parameter, is initialized and the product with the lowest priority is assigned as the UP.
  • the control enters into a routine consisting of two loops, an outer loop and an inner loop.
  • a list of the types of upgrade combinations for UP defined by the notation L(UP), is initialized as an empty set. '.
  • Base-Product (or BASE, in short), a parameter, is assigned the lowest priority product and control, then enters the inner loop.
  • Act 25.140 a test is performed to determine whether the current BASE is same as the current UP. If so, control brakes the inner loop and passes to Act 25.150, where the L(UP) for the current UP is returned. If not, control remains within the inner loop and passes to Act 25.142, where the list for the current BASE, L(BASE), is assigned to a collection Cl.
  • a list of all upgrade options that may provide an upgrade from the current BASE to the current UP is read from the company's database and is assigned to a collection called C2, and then C2 is added to L(UP), in Act 25.144.
  • C2 is added to L(UP), in Act 25.144.
  • each member in the collection Cl is combined with each member in the collection C2 and these combinations are then added to L(UP), in Act 25.146.
  • Act 25.148 the product that is one level higher than the current BASE in the sorted SP list is assigned as the new BASE.
  • the computation may be performed using a processor that may calculate results in optimal time.
  • a company may create a data structure (or a computer-readable medium) that may include an ability to store therein an indication of each customer of a company who may be eligible to receive an upgrade award and, for each said customer, an indication of each award for which the customer may be eligible and one or more values associated with the award.
  • Such said values may include, without limitation, a total upgrade value, a payment value, a soft value and an upgrade cost related to said upgrade; a Base-Product value, and an Up Product value; and one or more values specifying traits or characteristics of the customer and so forth.
  • Fig. 26 presents an illustrative Upgrade Award process.
  • the computation may be performed using a processor that may calculate results in optimal time.
  • the product availability is obtained (e.g. from a company's product allocation database).
  • an Upgrade Award rule is obtained (e.g. from the company's UPO system database).
  • the most recent Upgrade List is obtained (from the company's UPO system database).
  • Act 26.150 a test is performed to determine whether the selected upgrade combination is enabled to be upgraded or not.
  • An upgrade combination is enabled if all of its members are enabled to be upgraded.
  • a member of an upgrade combination may become disabled to be upgraded for one or more reasons, such as cancellation, failure to approve payment of charges for the final upgrade, the customer was already awarded an upgrade to a higher product and so forth. Once a customer is awarded or disabled from being upgraded, all the combinations that include this customer become disabled from the Upgrade Award process.
  • the Upgrade Award process awards the newly available product to the topmost member of the upgrade combination, and the respective released products to the rest of the combination members in Act 26.170.
  • the Upgrade Award process may charge the customers for a payment amount (if any) using any payment method such as a pre-stored charge card, a company credit account, a direct debit authorization for a bank account, etc.
  • a company may take the authorization or set the payment terms when the customer is receiving the option or at any other time. The customer may pre-authorize the company to charge only on the condition when the customer is being awarded the upgrade.
  • a company may set up different rules to handle it, such as to discard that member, and hence, the corresponding upgrade combination (and follow the Act 26.190), or to seek another form of payment at that point from the customer or to go ahead with the upgrade and then ask for payment from the customer at the time of customer purchasing or utilizing the product or at any other time.
  • a company may use any Upgrade Award rule of its choosing including, but not limited to, to maximize the total upgrade value (monetary or soft value or a combination of both), the number of upgrades or the number of customers buying or purchasing the product, to balance demand across multiple products, to optimize customer service for all or a selected group of customers, to optimize operations and to accomplish any other objectives and/or any combination thereof.
  • any Upgrade Award rule of its choosing including, but not limited to, to maximize the total upgrade value (monetary or soft value or a combination of both), the number of upgrades or the number of customers buying or purchasing the product, to balance demand across multiple products, to optimize customer service for all or a selected group of customers, to optimize operations and to accomplish any other objectives and/or any combination thereof.
  • the upgrade value of each combination member preferably is added together to get the total upgrade value of the entire upgrade combination. Then, all the upgrade combinations from all the upgrade lists (one for each Up Product) are combined together to form one list sorted by descending value, and the topmost upgrade combination is selected as the target to be considered first for an upgrade award.
  • the Upgrade Award rule When the Upgrade Award rule is set to maximize the number of customers in the product, the number of upgrade awards given to standby customers may have to be optimized. Hence, an upgrade combination that includes a standby customer may be given preference over the one that does not include it.
  • a company may also choose to select the target upgrade combination randomly: to add all the upgrade combinations from all the upgrade lists of a product to one list and then to randomly select an upgrade combination as the target combination.
  • An upgrade award may be given at any time before and/or during the utilization of product. It may also be given at a pre-determined time. For one or more Upgrade Award rules, a company may need to iterate over possible solutions. Especially in the Act 26.140, the process to choose the target upgrade combination may involve one or more sub-acts (one or more of which may be iterative) that enable the company to accomplish the overall objective.
  • the company may use next level (one or more levels as needed) of Upgrade Award rule(s) to further prioritize the upgrade combinations.
  • the next level of upgrade combination may include one or more of the rules defined above.
  • Both the company and the customer may have the right to enforce the upgrade award on each other as per the terms and conditions of the option contract.
  • the company may have the right to charge the customer for the upgrade amount if the customer is upgraded.
  • the company may inform/notify the customer and/or take approval from customer to charge the customer's account before awarding upgrade.
  • the customer may also have the right to enforce upgrade on the company within the terms and conditions of the options contract.
  • the terms and conditions of the option contract may also specify fulfillment of one or more conditions before the company may award upgrade to the customers. Some of the conditions may be such as payment for upgrade, availability of highest product prior to company starting the upgrades and so forth.
  • a company may use the UPO VOF for any other purpose of its choosing. In all such uses, the company may use a system defined below that can help to optimally allocate product capacity among customers.
  • the following system presents an example of a system (along with its methods and algorithms) that may be used to upgrade UPO customers within their selected UPO Products. However, a company may use any other process of its choosing to upgrade UPO customers within their selected UPO Products.
  • the Buy_N process is used as an example to demonstrate the system and its set of methods and algorithms.
  • the process of upgrading Y customers (i.e., UPO customers) within their selected UPO Products is termed "Upgrade_U" process.
  • the Upgrade_U process may allow the company to optimally upgrade UPO customers from their Accounted Products (Base- Products) and to one of their Awaiting Products (Up Products) to satisfy a pre-defined goal.
  • the cost in the Buy_N process and Upgrade_U algorithm may also refer to the price that the customer may pay to the company to receive an upgrade.
  • Fig. 27 displays a flow chart of an example of a Buy N algorithm, which is executed during a dynamic interaction between the customer and the company.
  • an interaction may include a situation when a customer interacts with a company to obtain (or purchase) products, or when a company presents offerings to a customer (with or without a solicitation by the customer).
  • a few parameters have been assumed to add context and enhance understanding. It is assumed that a customer is interacting with a company to purchase products, and that UPO VOF is implemented at the Set level.
  • the search criteria are input.
  • Various search parameters for a desired Product Set are taken as the input to the system.
  • Act 27.110 a search process is executed to search for all Product Sets that satisfy inputs. The details of the search process are described later.
  • Act 27.120 all the search results are displayed before the customer in an interface (such as in a web browser, a telephone operator stating the search results over the phone etc.).
  • Control then goes to Act 27.130, where the customer selects a Set (or Product Set). The selection of the Set may be followed by a payment and/or purchase of the selected Set.
  • Act 27.140 a test is performed to determine whether Upgrade U process has been applied on the selected Set. If so, control goes to Act 27.150, where the Upgrade U process is completed for the selected Set, and control then goes to Box 27.200. If not, control goes to Box 27.200, where the algorithm exits.
  • the completion of the Upgrade_U process may include one or more Acts that may be executed to incorporate the fact that said Set was selected by the customer. For example, one of such acts may be to record the selection of said Set to a database and/or to change the Accounted Status for one or more UPO customers (who were affected in the Upgrade U process).
  • Fig. 28 expands Act 110 of Fig. 27 and demonstrates an example of a search algorithm that may be used to determine Product Sets that satisfy the inputs.
  • IC number of incoming customers
  • ICJBenef ⁇ t i.e., the benefit that a company may receive if the incoming customers select and/or purchase one or more Sets
  • the input search criteria are taken as the input parameters to the system.
  • the term "Incoming Customers" refers to the customers who interact with the company in the current transaction (Buy_N). It is assumed that each customer desire one unit of capacity and thus, total units of capacity desired is equal to the total number of incoming customers.
  • IC_Benefit and/or IC may not be available as an input, and may be calculated during the search process.
  • Act 28.110 all the Sets that satisfy the 'search criteria' are searched from the company database. The Sets, thus obtained, are added to a list termed LIST Set. The first element in the LIST Set list is designated as Current_Set.
  • Act 28.140 another test is performed to determine whether EAC (Effective Available capacity) of the Current Product is greater than or equal to IC. If so, control goes to Act 28.145. If not, control goes to Act 28.150, where the Upgrade_U algorithm is executed to determine the possibility (and associated process steps and costs) to create capacity in the Current_Set.
  • EAC Effective Available capacity
  • Act 28.160 a test is performed to determine whether it is possible (by using Upgrade U) to create capacity in the Current Set and the IC Benefit is greater than or equal to the cost to create that capacity as determined in the Act 28.150. If both conditions are true, control goes to Act 28.170. If either condition is false, control goes to Act 28.165. In Act 28.165, the Current Set is discarded from the LIST Set list, and control then goes to Act 28.170.
  • Act 28.145 a test is performed to determine whether more elements are left in the LIST_Product list. If so, control goes to Act 28.135, where the next element in the LIST_Product list is designated as the Current_Product and control loops back to Act 28.130, to repeat the process for the new Current_Product. If not, control goes to Act 28.170.
  • Fig. 29 expands Act 150 of Fig. 28 and demonstrates an example of an algorithm to apply the Upgrade U algorithm to create one or more units of capacity in one or more Produces) within a Desired Set (the Set in which capacity needs to be created).
  • various input parameters are taken in the system. Input parameters include IC, Desired_Set and Incoming Benef ⁇ t (i.e., benefit a company may realize if capacity is created in the Desired Set)
  • control goes to Act 29.110, in which all the Products in the Desired_Set are listed in the LIST Product list.
  • the first Product in the LIST Product list is designated as Current_Product.
  • Act 29.120 a test is performed to determine whether the Available Capacity (AC) of the Current Product is greater than or equal to IC. If so, control goes to Act 29.130. If not, control goes to Box 29.300, where the algorithm ends.
  • Act 29.130 another test is performed to determine whether EAC (Effective Available capacity) of the Current Product is greater than or equal to IC. If so, then control goes to Act 29.140. If not, control goes to Act 29.150.
  • AC Available Capacity
  • the Upgrade_U algorithm is called for each Ua in the Current_Product and the algorithm follows a recursive loop. Each of the Ua becomes Current_Ua for the corresponding Upgrade_U call.
  • the necessary input parameters for each of the UpgradeJJ includes the Current_Product as 'COPP', CurrentJLJa as 'COPU', Current_Ua as 'Caller_U ⁇ Curre ⁇ t_Product as 'Initiator_Product', one of the incoming customers as 'Initiator_U' and Incoming Benefit as 'Benefit'.
  • the Upgrade_U call returns a U Series collection for each Ua in the Current_Product. The details of the Upgrade U algorithm are discussed in the next section.
  • a P_Series collection for the Current_Product is calculated through the following operations: (1) create groups of Ua from all Ua of the Current_Product for which Upgrade U was called, where the number of Ua in each group is equal to "IC-EAC" (EAC of the Current Product), (2) make combinations of the U_Series collection of all members of each group (combine each Series_Element of each U_Series of each member with that of each of the rest of the members of that group), (3) merge all members within each combination to formulate a merged Series_Element, (4) collect all such merged Series_Elements, thus obtained, into P_Series collection of the Current_Product. Details on making combinations and merging are provided later.
  • Act 29.180 a test is performed to determine whether more elements are left in the LIST_Product list. If so, control goes to Act 29.185, where the next element in the LIST Product list is designated as the Current_Product and control loops back to Act 29.120 to repeat the process for the new Current_Product. If not, control goes to Act 29.190.
  • a S_Series collection for the Desired_Set is calculated from the P_Series collections of all the Products using the combination and merging process (details provided later).
  • an optimal Series Element from the S_Series collection is determined using Optimal Series Element Rule (which is read from a database).
  • control goes to Act 29.210, where the optimal Series_Element is returned and the algorithm exits at Box 29.300. 'Upgrade_U' Algorithm
  • Fig. 30 represents an algorithmic illustration for Upgrade_U.
  • the Upgrade U is a recursive algorithm, which returns a collection of Series_Element termed "U_Series" collection for the Ua for which the algorithm has been called.
  • Act 30.100 a set of parameters including COPU, COPP, CallerJJ, Initiator Product, Initiator U and Benefit are input to the system.
  • Act 30.110 all the Awaiting Sets of the Caller U are added to a list termed LIST Set.
  • the first element in the LIST Set list is designated as Current Set.
  • Act 30.120 all the Products that belong to the Current Set are added to another list termed P LIST.
  • the first element in the P_LIST list is designated as Current_Product.
  • Act 30.130 a test is performed to determine whether the Current_Product is present in the COPP. If so, the Current Set is discarded in Act 30.135, and control goes to Act 30.260. If not, control goes to Act 30.140.
  • Act 30.140 another test is performed to determine whether the Current Product is present in the Accounted Set of the Caller U. If so, the Current_Product is skipped in Act 30.145, and control then goes to Act 30.190. If not, control goes to Act 30.150, where another test is performed to determine if the EAC of the Current_Product is greater than or equal to 1. If so, control goes to Act 30.220. If not, control goes to Act 30.160.
  • the necessary input parameters for each of the Upgrade U includes 'COPP' (includes the COPP of one level up Upgrade U and the Current Product), 'COPU' (includes the COPU of one level up Upgrade U and the Current Ua), the Current Ua as 'Caller U', the Current Product as 'Initiator Product', Caller U of one level up Upgrade U as 'Initiator U' and benefit of the highest level Upgrade U as 'Benefit'.
  • Each of the Upgrade_U call returns a U Series collection for every Ua for which Upgrade U was called.
  • Act 30.170 the algorithm receives the returned U_Series collection from all the Upgrade_U algorithm calls in Act 30.160. Control then goes to Act 30.180, where a P_Series collection for the Current_Product is calculated by adding all the Series_Elements from all the returned U_Series collection obtained in Act 30.170. Control then goes to Act 30.190.
  • Act 30.190 a test is performed to determine whether more Products are left in the P LIST list. If so, control branches out to Act 30.200, where the next Product in the P_LIST list is designated as the Current_Product, and control then goes to Act 30.130 where the process is repeated for the new Current_Product. If not, control goes to Act 30.230.
  • the S Series collection is calculated for the Current_Set by combining and merging all the P_Series collection of all the Products (not taking the skipped Product(s) into consideration, if any).
  • a new ChildU is created using the Caller_U.
  • the ChildU consists of COI (where the current Initiator Product is designated as Initiator_Product and the current Initiator_U is designated as Initiator_U), Accounted_Set of the Caller U designated as the Initial_Accounted_Set, current Awaiting_Set designated as the Final_Accounted_Set, and the cost to upgrade current Caller_U from the Initial_Accounted_Set to the Final_Accounted_Set designated as the CCU.
  • the ChildU, thus created, is added to every Series_Element in the S_Series collection and the CCU of the same ChildU is added to the CSE (Cost of Series_Element) of every Series_Element. Control then goes to Act 30.250.
  • a Qualify_Series_Element rule is read from the company's database and is applied to validate all the Series_Elements in the S_Series collection. The invalid Series Elements are discarded from the S_Series collection.
  • a company may select any rule of its choosing. For example, a Qualify_Series_Element rule may only qualify those Series Elements for which the CSE is greater than or equal to the 'Benefit'.
  • control goes to Act 30.260.
  • Act 30.260 a test is performed to determine whether more Sets are left in the LIST_Set list. If so, control branches out to Act 30.295, where the next element in the LIST_Set list is designated as the Current Set, and then control loops back to Act 30.120, where the process is repeated for the new Current_Set. If not, control goes to Act 30.270, where the U_Series collection is obtained by adding all the Series Elements of all the S_Series collections for all the Awaiting_Sets of the Caller_U. Next, the U_Series collection is returned in Act 30.280, and the algorithm ends in Box 30.300.
  • Combinations of P_Series in order to formulate S_Series are calculated by cross multiplication of Series_Elements (of each P Series).
  • a company may choose to implement any method of its choosing to make combinations.
  • One method is as follows.
  • n number of Series say Si, S 2 , S 3 ... S n , with kl, k2, k3...kn number of Series Element respectively.
  • Merging of a given number of Series Elements is done in a sequential process, where two given Series_Elemnts are merged together in one Act to obtain a single merged Series_Element (let's say M), and then the merged element, M, is merged with the third given Series_Element to obtain a new merged element, and so on.
  • the main objective of merging is to ensure that the Series_Elements created are valid and synchronized with each other with respect to capacity utilization of various products involved.
  • a given unit of product capacity at any given point must only be accounted for one customer, otherwise, it may lead to a shortage situation, where one product is allocated to more than one customer leading to dissatisfaction for customers.
  • a company may choose any method of its choosing to perform merging of Series Elements, and specifically to perform merging of two Series Elements.
  • the method of merging chosen may affect the total value realized.
  • One example of such a method is given.
  • a company may choose to discard all merged Series_Elements that have either one or more common Chi IdU or common End_Product.
  • a common ChildU in two Series_Elements suggest that in both Series_Elements upgrading of one specific Ua is needed. If each Series_Element requires upgrading of Ua to two different Sets, it may present a contradictory situation.
  • a common End_Product in two or more Series_Elements may require to upgrade more than one Ua customer to a specific Product, which may or may not be feasible depending on the AC (and EAC) of that product.
  • a common End_Product may also represent one or more contradictory or invalid situations.
  • a merged Series Element, M obtained from merging of two Series Elements Sl and S2, may consist of the COEP (addition of COEP of Sl and S2), COCU (addition of COCU of Sl and S2) and CSE (addition of CSE of Sl and S2).
  • COEP addition of COEP of Sl and S2
  • COCU addition of COCU of Sl and S2
  • CSE addition of CSE of Sl and S2
  • the Chosen Product may be defined by the company, the customer, another entity or any combination thereof. However, the company may want to keep the right to select (or define) the Chosen Product in the UPO VOF. A company may use any method of its choosing to define the Chosen Product. A company may use a software application built on the method defined above to optimally define the Chosen Product to UPO customer.
  • Fig. 31 displays an example of an algorithm that may be used to execute the Customer Notification process.
  • Act 31.100 a group of (one or more) customers is taken as input.
  • Act 31.110 a set of one or more Customer Notify Rules may be used to define the Chosen Product.
  • a company may choose any Customer Notify Rule of its choosing.
  • the Customer Notify Rules may depend upon expected value of the Product, expected sales volume and so forth. For example, a company may choose a Customer Notify Rule which selects the Product with the higher value as the Chosen Product. Alternatively, a rule may be chosen, which selects the Product with the lower value as the Chosen Product.
  • a company may also want to use the Upgrade_U algorithm (as used in the Buy_N process given above) to determine the optimal Chosen Product that satisfies a pre-determined goal.
  • one or more Ua may be upgraded in the process of selecting the optimal Chosen Product.
  • a Customer Notify Rule may also select the Product with the higher sales volume as the Chosen Product.
  • a Customer Notify Rule may specify that if UPO VOF is used in conjunction with any other VOF (such as FRO VOF and so on), then the Grouping Rules (defined later) may govern the selection of the Chosen Product.
  • UPO VOF may be used in conjunction with one or more other VOFs, for example, the APO (the Alternate Product Option) VOF.
  • a customer who receives an APO is termed "A" type of customer.
  • a company may form a group of one or more APO customers and one or more UPO customers, where the options (APO and UPO) obtained by the group members are complimentary in nature. As an example, consider two customers A(Pl, P2) and U[up(P2), base(Pl)].
  • the notation A(Pl, P2) implies a customer A who has received an APO and has the flexibility to choose either of Pl or P2 as the Chosen Product.
  • the notation U[up(P2), base(Pl)] implies a customer U who received a UPO and wishes to get an upgrade from Pl (i.e., the Base-Product) to P2 (i.e., the Up product).
  • Pl i.e., the Base-Product
  • P2 i.e., the Up product
  • the company may upgrade U to P2.
  • P2 i.e., the Chosen Product
  • the company may not upgrade U and hence U gets Pl.
  • the customers A and U have taken complimentary options and may form a-group.
  • the company may need to hold only one unit of inventory in Pl and P2 to satisfy the needs of both A and U (assuming each A and U only need one unit of product).
  • Such a combination of complimentary options or VOFs may improve efficiency and concurrently enhance value for all the parties involved (in the context of the current example, enhance value for U, A and the company).
  • the implementation of the grouping of U type and A type of customers may be done in one or more ways.
  • One way to implement such grouping is to first offer and secure one or more U type of customers and based on such customer(s), the company may offer complimentary APOs to customers to make groups.
  • the company may first offer and secure APO customers and based on such APO customer(s), company offers complimentary UPOs to customers to make groups.
  • the company may offer UPO and APO separately and then define a process to make complimentary groups of A and U customers (such groups termed "AU_Groups").
  • a company may choose to create AU_Groups at various group levels such as implementation of grouping at Level 1, Level 2 and so on.
  • an AU_Group involves one each of A and U type of customers.
  • An example of Level 1 grouping has already been given above (the two customer, A and U, example).
  • Level 2 grouping the grouping involves making complimentary groups for more than 2 customers.
  • A(Pl, P2, P3) Ul [up(P2, P3), base(Pl)] and U2[up(Pl, P3), base(P2)].
  • the notation A(Pl, P2, P3) implies a customer A who received an APO on Pl, P2 and P3 (flexibility to choose any one of Pl, P2 or P3 as the Chosen Product).
  • the notation Ul[up(P2, P3), base(Pl)] implies a customer Ul who received a UPO and wishes to get an upgrade from Pl (Base- Product) to either P2 or P3 (any of the two Up products), and U2[up(Pl, P3), base(P2)] implies a customer U2 who received a UPO and wishes to get an upgrade from P2 (Base- Product) to either Pl or P3 (any of the two Up products).
  • a company may group these three customers together. If A decides to choose P.I as the Chosen Product, the company may upgrade Ul to P2 and U2 to P3. Alternatively, if A decides to choose P2 as the Chosen Product, the company may upgrade Ul to P3 and U2 to Pl.
  • a "unit” represents one unit of product (or product capacity) and each customer needs only one unit of a product.
  • the company may need to hold (or block) a total of 5 units of capacity to ensure complete satisfaction of needs of A, Ul and U2, i.e., 3 units for A (1 unit each of Pl, P2 and P3 as A could choose any product), 1 unit for Ul in Pl (Base-Product) and 1 unit for U2 in P2.
  • Even by blocking (or holding) 5 units of space there may be no guarantee that the company would be able to satisfy upgrade needs for Ul or U2 (in the event they are not grouped together).
  • an AU_Group mechanism may create an efficient structure with minimal holding (and/or blocking) of capacity to satisfy the needs of all the concerned customers.
  • the grouping may also be implemented at higher levels such as Level 3 grouping, Level 4 grouping, Level 5 grouping and so on.
  • An example of the Level 3 grouping may be Al-Ul-U2-U3.
  • a company may choose to implement grouping at various product levels such as Product, Set and Order.
  • a company may also change terms and conditions of one or more option contracts of one or more UPO and/or APO customers (for e.g., price, notify deadline and so on) to solicit customer participation in UPO/APO to create more AU_Groups.
  • the company may also offer incentives to customers to choose complimentary UPO/APO offerings to enable the company to create more AU_Groups.
  • the implementation methods mentioned above for grouping are for illustration purposes only and a company may choose to implement grouping in one or more other ways or by combining above said methods or by combining one or more other ways along with one or more above said methods.
  • Fig. 32 displays a flow chart that illustrates one way of implementing grouping of A and U type of customers.
  • sets of A and U customers are taken as input.
  • a set of one or more Grouping Rules is read from the company's database (32.210).
  • a grouping rule may depend upon the number of A and/or U type of customers, desired capacity redundancy in the system, the permissible time factor to create AU Groups, any other rule of company choosing, any combination thereof and so on.
  • a company may choose a Grouping Rule whereby new groups are created by first ungrouping one or more of the AU_Groups (created earlier but unexercised, for example, groups for which the customer has not been notified, or if notified, the customer has not utilized the Product and the terms of option contract allows for a change in the Chosen Product).
  • a Grouping Rule may create groups of only those A and U type of customers who are yet to be grouped and discarding all A/U customers, which have already been grouped.
  • a company may implement any Grouping Rule to formulate AU_Groups. The choice to Grouping rules may enhance the overall value for the company (for example, reduce the total capacity required to satisfy product needs for all A and U customers).
  • the number of units of the Product required (or blocked) should be equal to the number of units the customers shall be eventually utilizing.
  • the company may attempt to achieve such theoretical minima.
  • the grouping may enhance customers' experience, and may comprise operating a system that delivers a UPO to at least a "first customer” to utilize up to n of m selected products for said first customer, where n is less than or equal to m; operating a system that delivers an APO to at least a "second customer” to utilize up to k of p selected products, where k is less than or equal to p; operating a system to define each of the k Chosen Products, whereby after each of the k Chosen Products is defined, said "second customer” can utilize said Chosen Product; operating a system wherein a company defines t Chosen Produces) for said "first customer” after each of said k Chosen Products is defined, wherein after each of said t products is defined, said first customer can utilize said defined product, where t is less than or equal to n.
  • Said t products may be a subset of n products, m products or both. Said t products or n products or both may also include one or more products not included in said m selected products. Similarly, k products may be a subset of p products, or may include one or more products other than said p products.
  • the grouping may be performed for a multiplicity of at least one of said first or second customers and may combine together at least one of each of said first and second customers to formulate at least one group with at least one complementary set of options. The grouping may enable a company to utilize at least one of said m or p products at least after delivery of any of said first or second options.
  • UPO VOF may be used in conjunction with one or more other VOFs, for example, the FRO (Flexibility Reward Option) VOF.
  • FRO Flexible Reward Option
  • a customer who receives a FRO is termed "Y" type of customer.
  • a company may form a group of one or more FRO customers and one or more UPO customers, where the options (UPO and FRO) obtained by the group members are complimentary in nature.
  • the implementation of the grouping of U type and Y type of customers may be done in one or more ways.
  • One way to implement such grouping is to first offer and secure one or more Y type of customers and based on such customer(s), the company may offer complimentary UPOs to other customers to make groups.
  • the company may first offer and secure UPO and based on such UPO customers), company offers complimentary FROs to other customers to make groups.
  • the company may offer UPO and FRO separately and then define a process to make complimentary groups of U and Y customers (such groups termed "UY_Groups").
  • a company may choose to create UY_Groups at various group levels such as implementation of grouping at Level 1, Level 2 and so on.
  • a UY_Group involves one each of U and Y type of customers.
  • Level 2 grouping is given below.
  • Level 2 grouping the grouping involves making complimentary groups for more than 2 customers.
  • Y(Pl, P3) Ul [up(P2), base(P3)] and U2[up(Pl), base(P2)].
  • the notation Y(Pl, P3) implies a customer Y who has received a FRO and is flexible to have either Pl or P2 as the Chosen Product.
  • the notation Ul[up(P2), base(P3)] implies a customer Ul who received a UPO and wishes to get an upgrade from P3 (i.e., the Base-Product) to P2 (i.e., the Up Product), and U2[up(Pl), base(P2)] implies a customer U2 who received a UPO and wishes to get an upgrade from P2 (i.e., the Base-Product) to Pl (i.e., the Up Product).
  • a notation Y-Ul- U2 represents this example. Thus, there are three products Pl, P2, and P3 and they are occupied by Y, U2, and Ul respectively. The three customers have different value needs.
  • the customer Y is flexible on either Pl or P3 if he/she receives a desired reward for trading-in his/her flexibility.
  • the customer Ul has a Base-Product P3 and wishes to get P2 as the Up Product. If a company is able to upgrade Ul to P2 from P3, it may generate incremental value for both the customer and the company. But in the existing framework (i.e., without using conjunction of more than one VOFs), the company may not be able to achieve this without an available capacity on product P2.
  • U2 has a Base- Product P2 and wishes to get Pl as the Up Product.
  • a company may customize the desired values for the three customers by leveraging on Y's flexibility and upgrading Ul and U2.
  • the company may assign P3 as Chosen Product to Y, upgrade U2 from P2 to Pl, and upgrade Ul from P3 to P2.
  • the company may be able to generate customer surpluses in the process of Ul and U2 upgrades, which would not have been possible normally.
  • a company may be able to generate incremental value for all the parties involved and satisfy the desired needs to a level of customization.
  • Such a combination of complimentary options or VOFs may improve efficiency and concurrently enhance value for all the parties involved (in the context of the current example, enhance value for Y, Ul, U2 and the company).
  • a "unit” represents one unit of product (or product capacity) and each customer needs only one product.
  • the company may need to hold (or block) more than 3 units of capacity to ensure complete satisfaction of needs of Y, Ul and U2. This implies, to satisfy a total need of 3 products, the company may need to hold (or block) more than 3 products, creating a redundant capacity of at least one product that the company may not be able to use otherwise.
  • a UY_Group mechanism may create an efficient structure with minimal holding (and/or blocking) of capacity to satisfy the needs of all the concerned customers.
  • the grouping may also be implemented at higher levels such as Level 3 grouping, Level 4 grouping, Level 5 grouping and so on.
  • An example of the Level 3 grouping may be Al-Ul-U2-U3.
  • a company may choose to implement grouping at various levels.
  • a company may also change terms and conditions of one or more option contracts of one or more UPO and/or FRO customers to create more UY Groups.
  • the company may also offer incentives to customers to choose complimentary UPO/FRO offerings to enable the company to create more UY_Groups.
  • the implementation methods mentioned above for grouping are for illustration purposes only and a company may choose to implement grouping in one or more other ways or by combining above said methods or by combining one or more other ways along with one or more above said methods.
  • Fig. 33 displays a flow chart that illustrates one way of implementing grouping of U and Y type of customers.
  • Act 33.100 sets of U and Y customers are taken as input.
  • Act 33.1 10 a set of one or more Grouping Rules is read from the company's database (33.210).
  • a grouping rule may depend upon the number of U and/or Y type of customers, desired capacity redundancy in the system, the permissible time factor to create UY_Groups, any other rule of company choosing, any combination thereof and so on.
  • a company may choose a Grouping Rule whereby new groups are created by first ungrouping one or more of the UY_Groups (created earlier but unexercised, for example, groups for which the customer has not been notified, or if notified, the customer has not utilized the Product and the terms of option contract allows for a change in the Chosen Product).
  • a Grouping Rule may create groups of only those U and Y type of customers who have yet to be grouped and discarding all U/Y customers which have already been grouped.
  • a company may implement any Grouping Rule to formulate UY_Groups.
  • the choice to Grouping rules may enhance the overall value for the company (for example, reduce the total capacity required to satisfy product needs for all U and Y customers). Theoretically, the number of units of the Product required (or blocked) should be equal to the number of customers shall be eventually utilizing. Thus, by implementing the grouping and with the help of appropriate Grouping Rules, the company may attempt to achieve such theoretical minima.
  • the grouping may enhance customers' experience, and may comprise operating a system that delivers a UPO to at least a "first customer" to utilize up to n of m selected products for said first customer, where n is less than or equal to m; operating a system that delivers a FRO to at least a "second customer” to utilize up to k of p selected products, where k is less than or equal to p; operating a system to define each of the k Chosen Products, whereby after each of the k Chosen Products is defined, said second customer can utilize said Chosen Product; operating a system wherein a company defines t Chosen Produces) for said first customer after each of said k Chosen Products is defined, wherein after each of said t products is defined, said first customer can utilize said defined product, where t is less than or equal to n.
  • Said t products may be a subset of n products, m products or both. Said t products or n products or both may also include one or more products not included in said m selected products. Similarly, k products may be a subset of p products, or may include one or more products other than said p products.
  • the grouping may be performed for a multiplicity of at least one of said first or second customers and may combine together at least one of each of said first and second customers to formulate at least one group with at least one complementary set of options. The grouping may enable a company to utilize at least one of said m or p products at least after delivery of any of said first or second options. Using UPO to optimize various factors
  • the UPO VOF enables a systematic approach to sell the unused Up Products as well as to satisfy the unmet needs of the customers. It may also allow a company to achieve other optimization objectives.
  • the UPO VOF may enable the company to optimize one or more categories of freebie (defined above) customers and may earn additional revenue. It may also assist a company to reduce liability from off the balance sheet items such as pending loyalty program units of customers by accepting UPO payments in loyalty program units instead of cash.
  • the UPO VOF structure provides the company an opportunity to reuse/resell the released products after upgrades (after the customer holding the products are upgraded) for potential sales or any other purpose.
  • a company may calculate expected number of upgrade awards based on expected UPO sales and expected demand to estimate the number of expected Released Products. These Released Products may be added back to the company inventory, where they may be sold as regular products or may be utilized for other non revenue purposes.
  • the UPO VOF structure may also enable the company to increase potential revenue and/or fulfill its revenue maximization goals, non-revenue goals, maximization of customer satisfaction, utility and loyalty and/or any combination of these. There may be many other instances of next level of optimization attained by the company there by generating additional revenue, greater customer satisfaction and loyalty or any combination of these.
  • UPO VOF Different business models may be used to implement a UPO VOF.
  • the business models mentioned below, without limitation, may be used to implement the UPO VOF in any industry.
  • a company may choose to implement a UPO VOF individually or in conjunction with one or more partners and/or other companies.
  • an entity may use the allocated products to offer UPO to customers and/or to sell the products as regular products.
  • the allocation of product may be conditional. For example, one of the conditions may require a return of at least one allocated product within a specified time period and/or other consideration(s).
  • the customer may select or purchase one or more products from the company and/or said entity and then interact with said entity to receive one or more UPO Products in relation to said (already purchased) products.
  • Said entity may also receive product allocation from more than one company, and thus, offer UPOs on products from multiple companies to a single customer during the Initial Transaction for UPO.
  • the OA may use those products and operate a service to offer UPOs to the customers.
  • a customer may receive one or more products from the OA, and then receive a UPO on those selected products from the OA.
  • Another approach would be for a customer to select one or more products from the company and then receive the UPO option from the OA on one or more of those selected products.
  • a customer may select (receive) one or more products from both the company and the OA, and then receive the UPO option on one or more of those selected products from the OA. It is also possible that the customer receives a UPO from the company or both from the company and the OA on a given set of selected products.
  • the OA and the company may simultaneously offer UPOs to the customers, i.e., a customer may either approach the company or the OA to receive a UPO on desired products.
  • the OA may operate as the sole provider of the UPO to all the customers of a company.
  • the OA and the company may choose to work together and jointly offer UPOs to the customers.
  • the OA or the company may offer UPO to customers using either or both of the Sequential or the Concurrent Get UPO processes.
  • an OA may be able to offer UPO on products from one or multiple companies.
  • An OA may receive allocation of products from two or more companies.
  • a customer may purchase one or more products from one or more companies and/or from the OA, and then receive a UPO option on one or more of those selected products from the OA. Even if the OA may not be entitled to or does not receive product allocation from a company, it may still be able to formulate an agreement with one or more companies to offer UPOs on the products of said companies. Thus, a customer may be able to receive a UPO on products from multiple companies, giving the customer higher chances to get upgrade and more variety to choose from.
  • a customer may receive a UPO on two products from two different companies and may get upgrades to either of those products within the terms and conditions of the option contract and the OA and/or any one or all of the companies will then notify the customer about the Chosen Product within the terms and conditions of the option contract. This may provide a lot of value for the customers.
  • An OA may be able to thus create a multi-company UPO VOF Framework, which may tremendously enhance the value for the customers. All the participating companies that allocate products to and/or partner with the OA to offer UPO may also gain from an overall increase in the total spending by the consumers, enhanced overall customer satisfaction and/or other operational benefits. Either or both of the OA and the company may process the purchase of the selected products associated with a UPO received (or purchased) by the customer. A customer may receive products from the OA or the company for the products related to the UPO grant. Any entity (e.g., the OA and the company) may process products offered only by that entity or by either of the two entities.
  • the OA and the company may engage in a business agreement to implement a UPO program.
  • the business agreement may divide the total benefit generated by the UPO program between the two parties using any mechanism or criteria as desired.
  • the total UPO Revenue Benefit may be shared between the two parties.
  • the company may allocate products to the OA.
  • One or more companies may allocate only part of or their entire product inventory to the OA to offer those products to the customers by way of regular and/or UPO Products.
  • the OA may offer some revenue or fee to the company for all or a portion of the products allocated. This fee may be given only for the products that the OA is able to utilize or for all the allocated products.
  • the lending fee may be a lump sum amount, may depend upon the number of products allocated or may depend on one or more factors as desired.
  • the agreement may include a provision where the OA may return the allocated products back to the company at a certain time and date.
  • the company may allot OA at least one product and said OA may deliver UPO on at least one of said allocated products.
  • the OA may or may not enter into an agreement with the company to provide such option on its products.
  • the OA may sell back at least one allocated product to said company or to at least one entity other than the company or both.
  • An OA may offer a company flexible customer inventory (generated from UPO) at one or more terms and conditions. The company may be able to use this flexibility to generate benefit from one or more ways, such as the Buy_N process, reducing operational costs and so forth. Some of these examples have been explained earlier.
  • An OA may formulate an agreement with one or more companies on one or more VOFs, such as on both UPO and APO VOFs, to offer a combination of VOFs to customers.
  • the UPO VOF may include different conditions regarding the payments of prices related to the UPO. For example, a customer may be asked to make (or receive) payments only to the company even if he/she is receiving products and/or options from the OA. Similarly, the customer may be required only to pay to (or receive from) the OA even if he or she received the products and/or options from the companies.
  • the condition may also be set for a customer to make one or more payments to the company for the products and/or options received from that company, and to make one or more payments to the OA for the products and/or options received from that OA.
  • the condition may allow the customer to make partial payments to the company and the rest to the OA or vice versa, the basis of which distribution may depend upon various.
  • the customer may be required to pay to a third party or may be required to pay to any of the combination of the entities mentioned above.
  • a client-server architecture may be used to implement the UPO VOF.
  • a company may use a computer hardware and software infrastructure of its choosing to implement a UPO VOF.
  • the UPO VOF may be best implemented using one or more computer- implemented methods to operate a computer-implemented service (and/or system) to offer UPOs to the customers that may include, but not limited to, recording the information pertaining to the offered and/or sold UPOs in a database. It may also include operating a computer-implemented service (and/or system) or other service (and/or system) to execute the UPO Exercise process and award upgrades to one or more customers, to define the Chosen Products, and recording the information pertaining to said upgrade awards, Chosen Products (or defined Products), and/or other related information and for all the products related to a UPO in a database.
  • an application server may be used along with a database (e.g., a relational database) that stores all the information relevant to the company and the customer.
  • the database may include all the relevant information sufficient to identify products the company chooses to make eligible for UPO.
  • One or more users e.g., a business analyst or manager
  • the database shall also store all the information pertaining to all the acts (in stage one) used by a company while formulating the UPO VOF.
  • a similar or a different application server and/or a cluster of application servers (functioning concurrently) along with one or more web servers and a set of one or more database servers may be used for the Get UPO as explained in Fig. 13D above and UPO Exercise processes (including, but not limited to, Customer Notification processes) in the stage two of the UPO VOF.
  • the application server communicates with a web server and the database (e.g., a relational database either the same database used for stage one or a different one).
  • This database (for stage two) stores all the relevant information pertaining to all the acts executed during and in relation to the processes and algorithms run for stage two.
  • UPO VOF may depend upon including, but not limited to, the scale of the implementation, business requirements and number of entities involved.
  • the entities may interact through a series of hardware products and services with the OA/company server(s).
  • the OA may or may not be different than the company and the OA server may be the same as that of the company server.
  • the information technology and network system to implement UPO VOF may include tools, without limitation, such as one or more CPUs, Hard Disk Drives, RAM, one or more series of Routers, Internet, Firewall, highly secured VPN, Intranet, load balancers, servers, primary databases, secondary databases and so forth.
  • the company may have one or more separate temporary database structure wherein the entries are updated and stored until the final update is made in one or more main databases. One the final update is done, the entries in these temporary databases may be removed.
  • the entire system may run at the premises of OA, company and/or any third entity or any combination thereof. It may also be possible to run a part of the system at one place and rest at one or more other places.
  • the system may also be implemented even if one or more servers may be kept off-shore locations and may be accessed remotely.
  • the geographical locations of one or more hardware product and/or services may be different depending upon including, but not limited to, the factors of company's choice, ease of accessibility, infrastructure facilities.
  • the structure or the interaction architecture of the system may vary depending on factors including, but not limited to, the set up of the company, changes in the technology and with the introduction of new and better technology enhancing the interaction process.
  • a customer may interact with either one or more of the Get UPO, the UPO Exercise process, Buy_N, the CN processes either directly or indirectly using a local or a remote terminal (e.g., a computer with a browser and an access to the Internet) that is able to access the web server(s) that host the Get UPO and UPO Exercise and CN processes.
  • a customer may also interact with an operator (or a computer operator) using any communication mechanism (e.g., in-person, phone, using email, Internet chat, text messaging system) who then communicates with the web server through the Intranet and/or Internet.
  • the system for the stage one and/or stage two may be hosted and run by the company, an OA, a third party service provider or any combination of the above.
  • the web server, application server and database for both stage one and stage two shall be managed by the OA.
  • the OA may also have partial (or complete) access to the company database and systems through a highly secured environment (for example, a virtual private network).
  • a highly secured environment for example, a virtual private network.
  • all the computer hardware and software infrastructure for both stage one and stage two may be hosted by either or both (mutually) of the sides depending upon the business agreement between them.
  • the UPO VOF may be implemented in any industry.
  • the implementation of the UPO VOF in the airline industry is discussed here in.
  • the customer preference for higher ranked flights is used as the targeted value element.
  • the selected value element i.e., the customer need for higher ranked flights
  • the UPO VOF may be appropriately termed Upgrade Flight Option (UFO) VOF.
  • UFO Upgrade Flight Option
  • the first stage in the UFO VOF involves steps (or acts) of: capturing customer dynamics, assessing airline operations and economic factors, integrating customer dynamics with airline economic factors, formulating the VOF and optimizing the VOF.
  • the second stage involves carrying out a dynamic interaction with the customer and then executing an Event Optimizer process.
  • Up Flight or Up Flights refer to one or more flights that rank higher than other flights of the same airline.
  • the ranking may depend on customer preference and may differ from one customer to another and may be based on past customer preference.
  • the lower ranked flight is referred to as the "Base-Flight”.
  • Base-Flight also refers to a flight, which a customer has currently booked (or selected or purchased).
  • an "Up Flight” refers to any higher ranked flight to which the customer may theoretically be upgraded to. For example, in general, most business travelers would rank morning and evening flights higher than the afternoon flights, non-stop flights higher than connecting flights (or those with stops).
  • the afternoon booked flight and the preferred evening flight would be considered as the Base-Flight and the Up Flight, respectively.
  • a customer who is booked on a specific morning flight may also prefer another morning flight (let's say the 9 am flight).
  • the 8 am flight and the 9 am flight would be considered as the Base-Flight and the Up Flight, respectively for said customer.
  • the flight offering consists of a complex framework of value elements.
  • rankings may be presumed (or are implicit). For example, ranking for flights (e.g., morning and evening flights are ranked higher than the afternoon and red eye flights), Ticket Price (e.g., lower prices are ranked higher than higher prices) and the number of connections (e.g., non-stop flights are ranked higher than connecting flights) may be presumed.
  • Ticket Price e.g., lower prices are ranked higher than higher prices
  • connections e.g., non-stop flights are ranked higher than connecting flights
  • An airline may need to determine such rankings explicitly through interaction with various customers segments. As explained earlier, customers assign ranking to different flight offerings.
  • a customer may classify the flight offerings into different groups (that may or may not be mutually exclusive) and assign a relative rank to each of them.
  • rankings may be implicit or well established or well known; for which an airline may be able to assume/determine customer ranking that would satisfy the majority, based on an analysis of past customer behavior or other forms of market analysis.
  • the ranking may be very subjective; and may differ from one customer to another, and even for the same customer, may differ from time to time.
  • an airline may need to perform detailed interaction with customers to determine their ranking.
  • flights with higher perceived utility (satisfaction) values are generally ranked higher than those with lower perceived utilities.
  • Most customers would prefer to get a higher ranked flight over a lower ranked flight.
  • customers cannot get their desired flight(s) due to unavailability, price or any other reasons or any combination of the above, they have to settle down with something below their desired value.
  • Fig. 34 shows an analysis of the value elements that are believed to matter the most to customers in relation to a flight upgrade.
  • important value elements may include, but are not limited to, customers' preference for higher ranked flights, seat assignment, seating comfort and space, in-flight food and other amenities, special characteristics and/or features, if any, associated with the flights, priority check-in and boarding and special luggage handling.
  • important value elements may include, but are not limited to, Ticket Price and upgrade price.
  • important value elements may include, but are not limited to, time to request and get upgrade award, and how long before departure the ticket must be purchased for the customer to be entitled to an upgrade.
  • important value elements may include, but are not limited to, the ease of getting the upgrade. It may be important to estimate the relative preferences and utilities of these value elements to customers for various flights.
  • An assessment of the crucial economic factors for an airline may reveal these factors to include, but not be limited to, the fixed and variable costs across various flights, non-uniform distribution of demand across different flights, higher price for higher ranked flights, varying capacities of higher ranked flights much more than the capacities in lower ranked flights, possibility of revenue dilution, lost opportunity costs in offering free upgrades to customers through existing upgrade programs (if any), the marginal costs of carrying an additional customer in different flights, the number of unused seats after departure, increased competition from low cost carriers, the need to develop competitive advantages against low cost carriers, customer attrition rate, and commoditization of the airline industry.
  • One may dig deeper into details for different flights such as load factors, spoilage, seat availability, costs per customer mile, marginal costs per customer mile, lost opportunity costs in offering free upgrades to customers through existing upgrade programs, and so forth.
  • An assessment of the crucial economic factors, such as costs, constraints and capacities, may be performed, to determine the factors that affect the profitability, growth and goals of the airline. It might be beneficial if the airline utilizing the inventive system and method were able to express cost elements in a real-time or quasi-real-time (i.e., up to date) dynamic fashion so that such information may then be used to assess the profitability or contribution of each sale opportunity (at the flight level) , and to facilitate the operation of the Event Optimizer (so that offers and actions can be based on real-time or near-real-time information).
  • Fig. 35 also illustrates an example of how a mapping may be done, between customer value elements and airline profiles, for the UFO VOF.
  • customers who prefer higher ranked flights to lower ranked flights.
  • customers are also concerned about the price differences between the higher ranked and the lower ranked flights.
  • AU customers cannot afford to buy confirmed higher ranked flights at regular prices.
  • many customers would be willing to pay more than their Ticket Price to get higher ranked flights.
  • On the other side of the screen if a flight takes off with one or more empty seats, that condition probably represents the loss of potential revenue (and/or opportunity cost) for that airline.
  • Fig. 36 displays the structure of UFO value option framework (shown in Box 36.100) in the airline industry.
  • the UFO VOF is related to the value element "preference for higher ranked flights", as shown in Box 36.110.
  • the customer receives a conditional option for an upgrade and the airline awards the upgrade to the customer provided at least one condition on the option is satisfied.
  • a customer may select (purchase) one or more Base-Flights and then select UFO option on one or more Up Flights.
  • An airline may award one or more Up Flights from the selected UFO Flights or from other flights or any combination thereof.
  • UFO VOF In another implementation of UFO VOF, during a successful Initial Transaction, a customer receives an option to utilize up to 'n' out of 'm' selected flights (said 'm' flights termed "UFO Flights "). The 'n' flights that are finally selected are termed “Chosen Flights ". After each of the n Flights is defined (or selected or chosen or received), the customer has the right to utilize (or can utilize) said Chosen Flight. Apart from the Chosen Flights, the remaining flights are termed "Released Flights". The Released Flights (if any, that were held or blocked for said customer) may be sold to other customers as normal flights or UFO Flights or used for other purposes.
  • the Released Flights in relation to said option may be reused by the airline before, after, at or any combination thereof, the time the Released Flights and/or Chosen Flights are defined (or received or selected).
  • the m UFO Flights would contain all the selected Base-Flights and Up Flights
  • the n Chosen Flights would contain all the defined Base-Fights and Up Flights that the customer may utilize.
  • the customer may prefer to receive only Up Flights in the defined n Chosen Flights, since the customer would have higher utility for the Up Flights, however, the Chosen Flights may contain Up Flights or Base-Products or both.
  • the value of 'm' is greater than or equal to 2 and the value of 'n' may vary from '0' to 'm' depending upon the specific implementation of the UFO framework.
  • the value of 'm' and/or 'n' may be known (or defined and/or re-defined) before, during, after the Initial Transaction and/or any combination thereof.
  • the value of 'n' may or may not be known (or defined and/or re-defined) at the time of the Initial Transaction.
  • the value of 'm' and/or 'n' may be defined by the airline, the customer, another entity or any combination thereof.
  • the value of n may not be defined at the time of Initial Transaction.
  • the new value of 'm' may be greater than or less than the older value of 'm ⁇
  • the new value of 'n' may also be greater than or less than the older value of 'n'. In some of the cases, the value of new 'n' may be even greater than the older value of 'm ⁇
  • the UFO Flights may be selected by the airline, the customer, another entity or any combination thereof.
  • the UFO VOF may enable an airline to obtain preferences for Up Flights from UFO customers (i.e., those who select UFO) and use said preferences to satisfy the travel needs of other customers and/or to optimize the value for airline, customers, another entity and/or any combination thereof. Therefore, the airline would usually have the right to select (or define) the Chosen Flights.
  • the airline, the customer, another entity or any combination thereof may select one or more of the Chosen Flights related to a UFO.
  • the UFO Flights and the Chosen Flights may be selected by the same entity, different entities or any combination thereof.
  • the customer may select the UFO Flights and the airline may select the Chosen Flights out of the UFO Flights.
  • the airline may incorporate the customer information and the data related to the UFO into the sales, production, inventory, other database or information system or any combination of the above.
  • the option granted to the customer may be conditional.
  • One such condition (to upgrade) may be the seat availability in the Up Flight associated with the option. It may be possible that the seat availability in the Up Flight associated with the option is the only condition included in the UFO VOF. If so, after receiving the UFO, a customer may receive a right to be upgraded if there is seat availability in the Up Flight at a certain time and under certain conditions established as the terms and conditions of the option contract.
  • the time when an Initial Transaction is completed i.e., the customer receives a UFO
  • ITT Initial Transaction Time
  • One or more Base- Flights and Up Flights may be selected, at one or more times, before, after, during, or any combination thereof, the Initial Transaction and/or the time said option is delivered to the customer (or the customer receives said option) or any combination thereof. All the UFO Flights may be selected concurrently (i.e., all together iri one transaction) or sequentially (i.e., in multiple transactions).
  • a customer may select one or more flights in one or more transactions before the Initial Transaction. Said selected flight(s) (let's say X number of them), thus, may be considered as part of m UFO Flights of the UFO (m, n) transaction, and the customer may select only the remaining (m - X) number of UFO Flights during the Initial Transaction. All the transactions used to select (or receive) all the Base- Flights of a UFO transaction may be related to each other, and hence, may be considered as "related transactions”.
  • the sequential process may consist of a number of "related transactions" when all the UFO Flights are received one after another by paying/receiving a price in one or more transactions or acts.
  • the price may include, but is not limited to, a monetary value, coupons, discount vouchers, other benefits such as loyalty program benefits, frequent flyer miles or any combination of the above.
  • the transactions may be related due to a relationship during the Initial Transaction, one or more of the previously executed transactions, any other transaction or combination thereof.
  • the UFO VOF may also impose other conditions on the airline and/or the customer.
  • the option may impose a payment obligation on the customer if the airline upgrades said customer.
  • the option may confer a right upon the airline to enforce payment obligation on the customer.
  • the airline may take a pre-authorization from the customer to charge the customer using any payment mechanism including, but not limited to, credit card, debit card, debit bank account, third party payment service provider, advance payment by the customer, any other means, or combination thereof.
  • the airline may award the upgrade to the customer only if the airline receives a payment from the customer in relation to said upgrade.
  • the customer may be required to pay one or more prices at one or more times to receive the option for the upgrade.
  • the airline may award the upgrade to a selected group of customers based on any criteria of airline's choosing. For example, an airline may choose to give preference to its frequent flyer customers or high value customers over others.
  • the UFO VOF may also confer a right on the customer to enforce said upgrade provided at least one condition on said option is satisfied.
  • an airline may offer UFOs with preference orders attached to it, i.e., if a customer purchases (or receives) a UFO with a preference order of 1, said customer shall have the right to be the first customer among others to be awarded the upgrade.
  • a right is conferred upon the customer to enforce the airline to award the upgrade to the customer if a seat is available in the related Up Flight at a certain time as per the terms and conditions of the option contract.
  • the UFO VOF may also impose a condition on the airline to offer the Up Flight to the customer and the customer may have the right to choose between the Base-Flight and Up Flight and subsequently notify the airline about the Chosen Flight.
  • a customer may or may not be under a mandatory condition to accept the Chosen Flight as selected by the airline.
  • the airline or the customer may have the right to enforce the Chosen Flight on the other party as per the terms and conditions of the option contract.
  • the Box 36.200 illustrates an example of the Initial Transaction between the customer and an airline, where the airline offers the UFO value option to the customer.
  • a customer may be required to pay a price ($X) to receive said option for an upgrade from the afternoon flight (Base-Flight) to morning flight (Up Flight), and to agree to pay another amount (SY) to the airline if the airline (then or later) upgrades the customer to the morning flight.
  • An airline may choose to create one or more instances of the UFO VOF based on factors including, but not limited to, number of UFO Flights, Up Flights or Released Flights, pre-determination of a number of Up Flights or Released Flights, other factors or any combination thereof. For example, a UFO based on a combination of the number of UFO Flights (or m) and Chosen Flights (or n) would be UFO (m, n). Some UFO instances are shown in Boxes 36.120, 36.130, 36.140 and 36.150. In the UFO (2, 1) instance, the customer selects two UFO Flights and the airline may select any 'one' of those two flights as the Chosen Flight depending on whether upgrade is available or not.
  • the UFO (4, 2) instance may imply that the customer receives 4 UFO Flights, on the condition that the airline may select any 2 out of 4 flights as Chosen Flights.
  • the UFO (4, 2) instance may imply that the customer receives 4 UFO Fights, on the condition that the airline may select none, one or 2 Chosen Flights out of UFO Flights.
  • UFO VOF implementations may also have price conditions to the customer.
  • a customer receives a UFO to receive two out of any four selected UFO Flights, consisting of two Base-Flights, Bl and B2, and two Up Flights, Ul and U2.
  • the customer has made an Initial Payment of $1000.
  • the airline may define any two flights as Chosen Flights out of the 4 flights as per the terms and conditions of the option contract.
  • Ul or U2 or both is (are) defined as the Chosen Flight(s), the customer is required pay $50 or $100 or $200 as the UFO Exercise Price, respectively. If neither Ul or U2 (i.e.
  • the Initial Transaction may have terms and conditions applicable to the customer, the airline, any other entity or any combination thereof. These terms and conditions may be set, preferably, to concurrently benefit at least two of the above said parties.
  • the connections between Box 36.200 and 36.220, and Box 36.200 and 36.210 refer to the terms and conditions to the airline and the customer, respectively.
  • the UFO VOF may or may not include any constraints on the UFO Flights.
  • an airline may restrict UFO applicability and availability on flights that satisfy specific criteria.
  • the two UFO Flights may or may not include practically constrained flights.
  • Practical constraints may include one or more constraints that will prevent a customer to utilize a given flight or prevent the customer from utilizing all the UFO Flights. Such constraints may include, but are not limited to, time constraints, location constraints and so forth. In other words, it may or may not be practically possible for a customer to utilize both the selected flights due to at least one practical constraint.
  • one flight may be scheduled to be airborne when the other flight is scheduled to depart, thus not allowing any customer on the former flight to take the latter flight, or the distance between the departure airports of the two flights may prevent customers from flying on both flights (that depart within hours of each other).
  • a customer may select (or receive) UFO Flights in several ways; through mutual agreement (e.g., during a direct interaction such as a purchase for ticket for a flight), or the airline may grant the UFO Flights to the customer without soliciting their interest or permission. For example, to enhance customer satisfaction or for any other purpose, an airline may grant UFO Flights to customers based on the past customer behavior, interaction and so on.
  • the Initial Transaction may impose one or more conditions on the airline.
  • An airline may be required to explicitly notify the customer prior to or no later than a given date and time (referred to as the Notify Deadline) regarding the Chosen Flight. If there is no such explicit notification condition, the Chosen Flight may be decided as per the terms and conditions of the option contract. In either case, (explicit or implicit notification), the date and time when the selection of the Chosen Flight is notified to the customer is referred to as the Customer Notification Time (or CNT, in short). In the current discussion, the explicit notification condition is assumed unless specifically mentioned otherwise.
  • the Notify Deadline may be pre-determined or may be determined later (i.e., after the Initial Transaction) by the airline, the customer, any other entity, or any combination thereof.
  • An airline may determine one or more Notify Deadlines for a flight at one or more times (e.g., before, during, after the Initial Transaction or any combination thereof) using factors including, but not limited to, customer needs, expected value of the seat, airline profitability goals, any other factors or any combination of the above. Customer factors should also be considered in determining the Notify Deadlines, such as the upgrade periods desired by customers, or any other factor that may affect the behavior of a customer.
  • the Notify Deadline may be pre-determined or may be determined later (i.e., after UFO grant) by the airline, the customer or mutually by both.
  • the terms and conditions of the UFO VOF may not allow the airline to notify the customer after the last Notify Deadline (i.e., the latest among the Notify Deadlines).
  • flexibility may also be provided to the customer to notify the airline about the Chosen Flight up to a stipulated Notify Deadline, once the airline has offered the Up Flight to the customer.
  • a rule may be set that if the airline fails to notify the customer before the last Notify Deadline, the Base-Flight becomes the Chosen Flight and no upgrade is provided to the customer.
  • Another approach may be set that if the customer fails to notify the airline about the Chosen Flight once the upgrade has been offered to him/her by the airline, one or more of the Base-Flights, Up Flights and/or any combination thereof may be considered as the Chosen Flight.
  • the airline may select Up Flight as the Chosen Flight and may charge Exercise Price and/or any other price to the customer.
  • the airline may select the Base-Flight as the Chosen Flight and a price may or may not be charged. Any entity (e.g., the airline or the customer) may (or may not) be allowed to change the Default Flight once it is selected.
  • the UFO Exercise Price (if any) in the default case may or may not be equal to the UFO Exercise Price for the Default Flight for the last Notify Deadline. In the current discussion, a single Notify Deadline is assumed.
  • the customer may be required to pay one or more prices during the Initial Transaction (and/or to receive a UFO, referred to as an Initial Price), at the CNT (and/or the time the customer is upgraded, referred to as an Exercise Price) and/or at any other time, which may or may not be pre-determined between the customer and the airline.
  • the UFO Price may be a pre-agreed fixed amount or it may be variable with or without bounds and set later or any combination of the above.
  • the initial price and/or the exercise price may or may not be uniform for all UFOs designed and/or offered to the customers; an airline may choose any combination of uniform and/or non uniform prices for the initial and/or exercise price.
  • the airline may offer the customer a set of prices to choose from. Since price conditions may depend upon various factors, which may or may not be variable, the same may be decided at anytime.
  • the price conditions may be determined by the customer, the airline, another entity, or any combination thereof at one or more times.
  • One or more prices (UFO Initial or UFO Exercise or any other price) may be a negative value, which reflects that instead of the customer paying the airline, the airline shall pay a price to the customer to get the desired flight as the Chosen Flight.
  • One or more of the UFO prices may be embedded with the Ticket Price.
  • a customer may be presumed to accept the UFO offer while displaying the embedded Ticket Price. These presumptions may (or may not) include soliciting prior interest of the customer regarding the UFO offer.
  • the customer may or may not receive a separate price for UFO.
  • the UFO Price(s) may or may not be embedded within the Ticket Price.
  • the customer may make the payment directly or indirectly (e.g., through a third party) to the airline in relation to said upgrade.
  • the price may consist of a monetary value or a soft/non-monetary value (e.g., coupons, discount vouchers, other benefits such as loyalty program benefits, frequent flyer miles, exchange of another service) or other consideration or any combination of the above.
  • a price may include, but is not limited to, a set of one or more Ticket Prices, a set of one or more UFO Prices (initial and/or exercise) or any combination of the above.
  • An airline may choose to implement UFO Prices in many ways. An airline may use the method of its choosing to decide on the Ticket Prices of all the flights.
  • the UFO Price (Initial, Exercise, and/or any other price, or any combination thereof) may be a function of number of UFO Flights and/or Chosen Flights, specific flights to be granted for UFO Flights, Up Flights and/or Chosen Flights, Notify Deadline, one or more Ticket Prices, any other factors of airline's choosing or any combination of the above.
  • Various option pricing strategies may be employed. For example, in a fixed price strategy, a user may be shown only one fixed price for the option. If the user purchases the option at a price much lower than his/her maximum price, the potential benefit for the airline is less than what could have been achieved.
  • Bidding may help to determine the highest price a user is willing to spend for the upgrade.
  • the user may provide his/her highest offer for the final price.
  • the airline may charge the lowest price (less than the highest offer price selected by the user) that delivers the upgrade to the user. If even the highest offer price chosen by the user is lower than the minimum price needed to get the upgrade, then the user is not awarded the upgrade.
  • the highest offer may be input free form or the airline may provide a few choices from which the user may select one. The airline may also ask, or determine empirically, how much customers will pay for the option.
  • the assumption here is that customers make a logical decision to choose the Up Flight and can afford to pay the sum of the initial and the exercise prices (if any).
  • the customer may or may not have to pay during the Initial Transaction.
  • Initial Price may be subsequently returned to the customer, if the upgrade to the Up Flight is not awarded to the customer.
  • Exercise Price may also be adjusted with the Initial Price paid by the customer.
  • the airline may issue a UFO Pass for the customers in order to facilitate another payment mechanism. The payment for the ticket and/or the option may be made using the UFO Pass.
  • a time based UFO Pass may allow a customer to only be upgraded to the flights that fall within a specified time period.
  • a value based UFO Pass may allow a customer to get upgrades until the sum of the total payment needed for all the upgrades is less than or equal to the value of the UFO Pass.
  • the airline and/or another entity may create various types of UFO Pass.
  • the payment transaction may include, but not limited to, direct payment received by the airline from the customer, in lieu of relinquishment of one or more rights by the customer, indirect revenue generation (e.g., the customer relinquishes his/her right or accepts a lower limit on the baggage to allow the airline to sell the preserved cargo capacity for other revenues or other purposes)), costs savings obtained (e.g., the customer relinquishes his/her right to meals which saves costs for the airline), enhanced customer service and loyalty and so forth.
  • direct payment received by the airline from the customer in lieu of relinquishment of one or more rights by the customer
  • indirect revenue generation e.g., the customer relinquishes his/her right or accepts a lower limit on the baggage to allow the airline to sell the preserved cargo capacity for other revenues or other purposes
  • costs savings obtained e.g., the customer relinquishes his/her right to meals which saves costs for the airline
  • enhanced customer service and loyalty so forth.
  • each said event may be associated with various terms and conditions on the customer and/or the airline.
  • the airline and/or the customers may have the right to enforce the Chosen Flight(s) on the other party as per the terms and conditions of the option contract.
  • the terms and conditions of the option contract may be binding on the airline and the customer only if the customer successfully accepts the airline's offer of the option for the upgrade.
  • the customer may be given a choice of options to choose from and take a decision.
  • the airline may implement negative UFO, i.e., instead of upgrading the customer to an Up Flight, the airline may downgrade, the customer to a lower ranked flight.
  • the airline may implement such negative upgrade in one or more situations.
  • the airline may implement negative upgrade (downgrade) when there may be huge demand for Up Flights at very high prices so that the airline may downgrade the customer who may have already bought the Up Flight at relatively lower prices and may be willing to accept the lower ranked flight in lieu of some or more rewards.
  • the airline may implement it in case there is huge demand for lower ranked flight.
  • the airline may offer the Up Flight to the customer and may give an option to downgrade to lower ranked flight in future in case one becomes available.
  • the airline may offer discounts on higher ranked flights, may offer to return the difference between the lower ranked flight and higher ranked flight, may offer additional reward to the customer and so forth.
  • the airline may be able to retain the customer (and not to lose him/her to the competitor) even in the event that the customer is desiring a lower ranked flight and the capacity of which may be exhausted with the airline.
  • the airline may also be successful in this case in creating a flexible pool of customer inventory.
  • the terms and conditions of the UFO VOF may require the customer to purchase (or pay price for reserving) both the lower ranked and higher ranked flights with a condition to cancel/return either of the two flights as per the terms and conditions of the option contract.
  • a customer reserves a higher ranked flight for $400 (when its actual price is $650) and a lower ranked flight for $305 (when the actual price is $310) with a condition to return at least one of the flights.
  • the customer has paid $705 for reserving both the flights with a condition to cancel the reservation for at least one of them.
  • the terms and conditions of the option contract may provide different cancellation charges in different situations.
  • the terms and conditions of the option contract provides cancellation charges for higher ranked flight as $10 where as the same for lower ranked flight are $500. So, logically the customer will go for cancellation of higher ranked flight and in this case he would be refunded $390 and hence the net amount paid by the customer for getting the lower flight would be $315 ($705 minus $390) which may be equal to the Ticket Price of the flight ($310) plus Initial UFO Price ($5). In this case, the customer has not received the upgrade. Now, consider another case when the higher ranked flight is available. The terms and conditions of the option contract provide cancellation charges in this case for higher ranked flight as $500 where as there is no cancellation charges for cancelling the lower ranked flight.
  • the customer will cancel the lower ranked flight and hence he/she would be refunded $305. So, the net amount paid by the customer for getting the upgrade (i.e., the higher ranked flight) is $400 ($705 minus $305) instead of paying the full price (of $650) for getting the higher ranked flight.
  • the assumption here is that customers make a logical decision to choose which flight to cancel.
  • a UFO VOF may include a right for an airline to upgrade the customer to an Up Flight before a stated Notify Deadline.
  • the right may include the condition that the airline may notify the customer before, at or after the stated Notify Deadline or any combination thereof.
  • the airline may offer (or allow) the customer to finally choose the Chosen Flight once the airline notifies the customer about the availability of the Up Flight.
  • the Initial Transaction i.e., once the option has been granted (and/or sold) to a customer
  • there are two related events for the UFO option namely, 1) Up Fight is available at a certain time (shown in Box 36.250) and 2) Up Flight is not available at a certain time as per the terms and conditions of the option contract, as shown in Box 36.240.
  • the customer may be given one or more Up Flights if said Up Flights are available in Level 2 or higher events related to the UFO option, later on. It may also be possible that even when one or more Up Flights are available in Level 1 event which may or may not be given to the customer in Level 1 event, still later on, in Level 2 or higher events, if one or more Up Flights are available, said one or more Up Flights may be offered (given) to the customers. Said one or more Up Flights may be given by the airline, another entity and/or by both. The Up Flights given in Level 2 or higher events may be given in exchange of one or more previously given Up Flights or in addition to the earlier given Up Flight(s).
  • the airline may use any algorithm it desires in order to allocate the seats in the Up Flights. For example, the customers may have been given the ability, while buying the option, to specify the maximum amount the customer is willing to pay to exercise the option. Then the airline would probably choose to allocate all the seats available in the Up Flights so as to maximize its revenue.
  • the airline may use any method it chooses to allocate the upgrades, such as assigning priority based on time of purchase, Ticket Price paid by the customer, random selection or any other customer priority factors like frequent flyer miles and so forth.
  • the airline may also award cabin upgrade (downgrade) to a customer to the customer in addition to awarding the Up Flight.
  • the customer may be upgraded from the Base-Flight to the Up Flight and simultaneously, the airline may also award a cabin upgrade to said customer in the Up Flight.
  • An airline may choose to bump one or more customers from one or more flights in order to create availability to award one or more upgrades to UFO customers.
  • the airline may inform the customer of the decision related to the upgrade award via any communication channel including, but not limited to, a re-issued ticket sent over email, an email, phone, in-person at an airline counter, or may ask the customer to contact the airline to know the decision.
  • UFO Using UFO, an airline gets to know the relative preferences and utilities of the morning flights (higher ranked flights) over the afternoon flights (lower ranked flights) as some customers purchase this option and others don't. This may lead to an enhanced revenue benefit for the airline as well as higher travel utility to the customer. There may be some increase in costs for the airline, but generally, the additional revenue generated would be more than sufficient to account for the additional upgrade costs (if any).
  • the airline may better optimize its seat availability and may possibly be able to sell the lower ranked flights to additional customers due to additional capacity generated for the lower ranked flights (after a customer is upgraded to the Up Flight from his/her Base-Flight).
  • An airline may estimate the total number of expected upgrades and using the same, may estimate the number of vacated seats (due to potential upgrades) in the lower ranked flights. Using this estimate, an airline may be able to add back these seats to the airline inventory to be used for potential sales and/or other purposes.
  • a customer who receives a UFO is termed "U".
  • UFO A customer who receives a UFO is termed "U”.
  • Ua the status of said U customer
  • Uw the status of said U customer
  • Ua and Uw the status of said U customer
  • Awaiting which are one or more Up Fights or higher ranked flights for the customer
  • the UFO VOF may help an airline in one or more ways. For example, it may help to accommodate flight requests from potential customers. Any new potential customer who requests to obtain a flight is assumed to be an N customer. If the available seats in the desired flight (desired by N customer) is insufficient to satisfy the request, then the airline may use the seats (if any, of desired flight) that has been assigned to Ua customers, and reassign the same to said N customer. Consequently, the airline may then upgrade (assign the Awaiting flights, i.e., the flights where said Ua customers have Awaiting status to) said Ua customers. By implementing such upgrading of Ua customers from their Accounted flights to Awaiting flights, an airline may better serve incoming demand for flights.
  • Bus N An event where such request comes to the airline for a flight is termed "Buy N”.
  • the act to upgrade a Ua customer from its Accounted flight (Base-Flight) to its Awaiting flight (Up Flight) is termed "Upgrade U”.
  • Detailed algorithms are presented below that may be used to manage a system consisting of N, Ua and Uw type of customers.
  • An Upgrade U algorithm may be run independently of the Buy_N Process and may be used only to upgrade the customers from one or more lower ranked flights to one or more higher ranked flights.
  • Fig. 37 provides details on four typical instances of UFO.
  • Fl the highest ranked flight
  • F2 being the second ranked flight
  • F3 being the least ranked flight.
  • an airline may now create four instances of UFO, namely, F3-F2, F3-F1, F2-F1 and F3-F2-F1.
  • a sold UFO may be defined by four parameters such as in the notation MN (I, F),where, M is the Base-Flight (the current flight of the customer when the option is purchased), N is the Up Flight to which the owner of the option can be upgraded, I is the initial price paid by the owner to buy the option, and F is the exercise price which will be paid by the owner if and when he/she is upgraded.
  • a customer booked in the F3 flight may purchase a F3-F1 or "F3 to Fl” option to get an upgrade to the flight Fl if Fl becomes available.
  • a F3-F2 or “F3 to F2” option may be purchased by a customer booked on flight F3 to get a potential upgrade to flight F2 if F2 becomes available.
  • a F3-F2-F1 or a "F3 to F2 or Fl " option may be made available to a customer who purchased ticket on flight F3 for a potential upgrade to either flight F2 or flight Fl, depending on availability.
  • a F2-F1 or "F2 to Fl” UFO may be made available to a customer with a ticket on flight F2, for potential upgrade to flight Fl if Fl becomes available.
  • the number of Up Flights affect the total number of UFO instances.
  • the number of UFO instances typically increases with an increase in the number of Up Flights available for a customer.
  • the number of instances does not have to be equal to the number of Up Flights available, of course.
  • UFO Types Creator Algorithm (to create UFO Types or instances)
  • UFO Types creator algorithm has been explained in detail in the UPO VOF.
  • the implementation of UFO Types Creator Algorithm in the context of the airline industry has been explained through an example given below.
  • the algorithm of Fig. 38 may be used to create UFO instances in the airline industry, as follows. Consider an instance where there are 4 flights available for customer, namely, A, B, C and D. The priority order among the flights is A>B>OD, where the flight A has the highest rank and the flight D has the lowest rank.
  • a Set of Flights is input to form the SP, with flights sorted according to the descending order of priority, A>B>OD.
  • the BP is set to D and the CUP is set to comprise flights C, B and A.
  • Option_Creator (D, [C, B, A]) is called, the notation (D, [C, B, A]) indicating D is input as the BP and the CUP is input as the set [C, B, A].
  • the OC of the current level is initialized as an empty set. Then, a combination is formed of each Up Flight in the CUP set [C, B, A] with Base- Flight D and these combinations are added to the Option_Collection to form OC [DC, DB, DA], per Act 38.150.
  • the current CUP set [C, B, A] is assigned as the new SP and the lowest flight in the new SP, i.e., C, is the new BP, per Act 38.160.
  • a test is performed to determine if the CUP set is empty. It is not, so the process continues for a new (lower) level where Option_Creator (C, [B 5 A]) is called and executed. This is followed by another (lower) level where the Option_Creator (B, [A]) is called and executed.
  • the Acts 38.140 to 38.180 are repeated in a loop until the CUP set is empty. In this case, that happens with A as the BP. Then the Option Collection [BA] is returned at that point, per Act 38.190.
  • control is at Act 38.200, where C, the BP of the current level Option_Creator (C, [B, A]) is combined with each member of the returned OC[BA] from the lower level and the result [CBA] is added to the OC[CB, CA] of the current level.
  • Control goes to Act 38.210, where the returned OC[BA] is added to the OC of the current level.
  • the returned OC[BA, CB, CA, CBA] from lower level is added to the OC of current level.
  • a financial analysis may be performed on the UFO VOF using the existing airline and customer data to determine the optimal terms and conditions of the UFO VOF. 'What-if scenarios may be executed to determine the optimal pricing strategy.
  • the airline may want to divide its customers into one or more customer segments, and design UFO VOFs separately for each customer segments.
  • the airline After completing the first stage of the method, the airline has created a UFO VOF and specific value options within that framework. The airline has also segmented customers. The airline is fully prepared to use a structured format consisting of UFO value options to interact with its customers in real time to generate benefits for both the airline and its customers. The second stage of the UFO VOF is now presented.
  • the UFO VOF between the airline and its customer takes place through two high level acts, as shown in Fig. 39.
  • the 'Get UFO' process an interactive event between the customer and the airline web server, runs to carry out the Initial Transaction of the UFO VOF.
  • a number of algorithms may be executed on the airline's server (e.g. availability, UFO Price, Notify Deadline, Upgrade List and so on) to optimally calculate the terms and conditions of the UFO VOF (e.g., availability, UFO Price(s) and other conditions) to concurrently benefit at least two of the airline, its customers, another entity or any combination thereof.
  • an event optimizer process called the UFO Exercise Process is executed.
  • the airline may award the upgrade to the customer based on the terms and conditions of the option contract and the Chosen Flight is notified to the customer.
  • the process may also consist of one or more event optimizer algorithms that may help to optimally select the Chosen Flight and/or to optimally use (or reuse) the Released Flight.
  • UFO Exercise Process is similar to UTO Exercise Process which is explained in the UTO VOF discussed below.
  • the Get UFO process may be implemented via the Sequential (shown in Fig. 44) or the Concurrent (shown in Fig. 46) process.
  • Sequential There are many ways to do the Sequential process.
  • a customer may select (or purchase) a Leg/Segment/Itinerary before the Initial Transaction begins.
  • said Leg/Segment/Itinerary may be referred to as Initial Leg/Initial Segment/Initial Itinerary or IL/IS/II, in short, respectively.
  • the Initial Segment is also referred to as Initial Flight Segment (or IFS, in short).
  • a customer may get a UFO, i.e., get one or more UFO Legs/Segments/Itineraries on an IL/IS/IO, respectively.
  • a UFO Leg/Segment/Itinerary is also referred to as Option Leg/Option Segment/Option Itinerary, or OL/OS/OI, in short, respectively.
  • An Option Segment is also referred to as Option Flight Segment (or OFS, in short).
  • the two events one for the Initial Flight and the other for the Initial Transaction
  • the UFO VOF may be implemented at different levels including, but not limited to, Itinerary, Segment and Leg.
  • An airline may choose to implement the UFO at any level(s).
  • the implementation level should be the same for all the UFO Flights, Chosen Flights and Released Flights. For example, if UFO is implemented at the Itinerary level, then all the UFO Flights and Chosen Flights would refer to UFO Itineraries and Chosen Itineraries, respectively.
  • a customer interacts with the airline's server to receive UFO.
  • the interaction may take place (for example) via phone, in-person or on a website.
  • the Sequential Get UFO Process is presented first along with its detailed algorithms, followed by a short summary of the Concurrent Get UFO Process.
  • Sequential Get UFO Process when UFO is implemented at the Segment level. It is also assumed here that the customer first purchases an Initial Itinerary with one or more IFS, and then opts to receive a UFO on any of the included IFS.
  • a customer has purchased an Itinerary and then gets a UFO through the interactive interface of the web pages as shown in Figures 40, 41, 42 and 43.
  • Fig. 40 displays the summary of the purchased Itinerary, which is made of two Segments: BOS to SEA (onward journey) and SEA to BOS (return journey). Clicking on the marketing banner representing "Get UFO", the customer is linked to the Web page shown in Fig. 41 and a Get UFO interaction begins.
  • the series of web pages in Figures 41, 42 and 43 may (for example) be displayed in a customer's browser by an airline's web server, to facilitate the interaction between the customer and the airline when the customer comes to participate in Get UFO (during or after the Initial Itinerary is purchased).
  • the Initial Itinerary is displayed in Fig. 41.
  • the customer may choose to Get UFO on any IFS by clicking the "Click here to Get UFO Flights" link corresponding to that IFS. Once the link is clicked, the "Search UFO Flights" section appears (shown in Fig. 41), where the customer may enter the search criteria for OFS and then click on the "Search UFO Flights" button.
  • the Get UFO algorithm running "behind the scenes" on a server of the airline qualifies the availability, applicability and price conditions on all the available OFSs (Option Flight Segments) and displays them in the screen as shown in Fig. 42.
  • Initial UFO Price a set of one or more Notify Deadlines and the corresponding UFO Exercise Prices are shown in the form of "Select” buttons (shown in the "UFO Notify Deadline/UFO Exercise Price” section in Fig. 42).
  • the customer may select any desired OFS (along with the Notify Deadline and UFO Exercise Price) by clicking on a "Select" button associated with any of the Notify Deadlines displayed in the corresponding row.
  • the "Select" button he/she is hyperlinked to the web page as shown in Fig. 43, where the summary of the IFS and the selected OFS is shown.
  • the customer may choose to get more OFS on the same IFS, or to get UFO on another IFS in the Initial Itinerary.
  • the customer may repeat the OFS search process for that IFS. Once all the desired OFSs have been selected, the customer clicks the "Continue" button (shown in Fig. 43). A payment transaction is executed to complete the purchase of the UFO option.
  • Act 44.140 a test is performed to determine whether the customer wants to get more OFSs on the current Target IFS or on another OFS. If the customer wants to get an OFS on another IFS, control loops back to the Act 44.110, where the customer selects another IFS as the Target IFS, and then the process is repeated again for a new Target_IFS. If the customer wants to get more OFSs on the current Target_IFS, control loops back to Act 44.115, where the customer enters the OFS search criteria and then the process is repeated for the new OFS search criteria. If the customer does not want to get any more OFSs, control goes to Act 44.150, where a payment transaction (if needed) may be executed.
  • the customer may pay that price for UFO using a credit card, direct bank account debit or any other payment transaction mechanism. For example, a customer may need to pay a price for the OFS after taking into consideration the Initial UFO Price using a credit card, direct bank account debit or any other payment transaction mechanism.
  • the algorithm ends in Box 44.200.
  • the computation may be performed using a processor that may calculate results in optimal time.
  • the following algorithm determines and validates an OFS for a given set of conditions including, but not limited to, availability, Notify Deadline and UFO Price. Said algorithm has already been discussed above in a more generic sense along with one of the ways of its implementation along with various information technology and networking tools including, but not limited to, one or more servers, database, load balancers, firewall, routers, Internet, highly secured VPN, Intranet, RAM, hard disk drives, CPUs, monitors as shown by Fig. 13D.
  • the number of customers (IC), IFS_Set (containing all IFS in the Initial Itinerary, and all the OFSs, (if any) already selected/received along with Comb ND Set(s) and Comb_OP_Set(s), for each IFS), Target IFS and the OFS Search parameters are input to the system.
  • the OFS search parameters may include, but are not limited to, departure date and time, origin, destination, number of Legs per Segment, Notify Deadline, UFO Price (Initial and Exercise) and so forth.
  • a customer may be allowed to input Notify Deadline and/or UFO Price on the basis of which valid OFSs (that satisfy the given criteria of Notify Deadline and/or UFO Price) may be searched for and displayed for the customer.
  • a customer may be asked to input the origin and destination related parameters, and then a set of Notify Deadlines and UFO Prices may be computed for the flights that match the given criteria.
  • a customer may input both the origin and destination and Notify Deadline and/or UFO Price as inputs and then a search may be performed for valid OFSs.
  • a customer may input to the system, one or more flights, and/or inputs to search for one or more additional flights (e.g., origin and destination, price etc.) to search for OFS that may be combined with one or more input flights (by the customer) to constitute the total set of flights for a UFO.
  • an airline may also validate the flights input by the customer to determine if said flights are eligible to be the UFO Flights.
  • Act 45.1 10 an OFS Search is performed for the given criteria.
  • the search may be best performed using a processor that may calculate results in optimal time.
  • the order in which search parameters are executed may be optimized to reduce the search time, however, it may or may not affect the final outcome.
  • An airline may select any order of its choosing.
  • Act 45.1 10 Flight Segments are determined that match the search criteria and the resulting Segments are added to a list termed LIST OFS.
  • Act 45.120 a list of OFS validation rules is obtained from the airline's UFO VOF database and the rules are used to validate all the Segments in the LIST-OFS list. Segments that do not satisfy the rules are discarded.
  • Validation rules may include, but are not limited to, a Maximum Number of Legs per Segment Rule, a Maximum Ticket Price Rule, an Availability Rule and so forth.
  • a Maximum Ticket Price Rule may discard those Segments for which the Ticket Price related to the upgrade option is more than a specified value.
  • An airline may implement any rule of its choosing to further qualify the Segments in the LIST OFS list. As a last step in Act 45.120, the first element in the updated LIST OFS list is designated as the Current_OFS.
  • control goes to Act 45.130, where a group of Comb NDs is computed for the combination of the Target_IFS, all the existing OFS of the Target_IFS and the Current OFS, and added to a set called Comb_ND_Set.
  • Act 45.135 a test is performed to determine whether the Comb_ND_Set obtained in the previous Act is Null. If so, control goes to Act 45.155. If not, control goes to Act 45.140, where the UFO availability and UFO Price for the Co ⁇ nb_ND_Set are determined.
  • Act 45.150 another test is performed to determine whether the UFO Availability or the UFO Price is Null. If so, control goes to Act 45.155. If not, control goes to Act 45.160.
  • the next element in the LIST OFS list is designated as the Current OFS and control loops back to Act 45.130 to repeat the process for the new Current_OFS.
  • the updated LISTJDFS list is returned as the search result, and then the algorithm ends (Box 45.200).
  • the computation may be performed using a processor that may calculate results in optimal time. This algorithm may be used while implementing the search process at Leg and/or Itinerary level. Computation of Notify Deadlines
  • An airline may set one or more Notify Deadlines of its choosing for its Flights. Once the Notify Deadlines have been set for each Flight, the next Act is to create a framework to compute the Notify Deadlines for a group of Flights (such as a Segment, an Itinerary or any other group).
  • a framework to compute the Notify Deadlines for a group of Flights (such as a Segment, an Itinerary or any other group).
  • the following sections present an example of a framework that may be used to obtain a set of Notify Deadlines applicable to a group of Flights.
  • An airline may use any framework and algorithm of its choosing to obtain the same.
  • a set of Notify Deadlines associated with a Leg, a Segment and a combination of two or more Segments is called Leg _ND_Set, Seg_ND_Set and Comb_ND_Set, respectively.
  • Each element in the Leg_ND_Set, Seg_ND_Set and Comb_ND_Set is termed Leg_ND, Seg_ND and Comb ND, respectively.
  • the Comb_ND_Set may be computed by combining the Seg_ND_Sets of all the given Segments.
  • a Seg_ND_Set may be computed by combining the Leg_ND_Sets of all the Legs under that Segment.
  • the Notify Deadlines may be computed based on various parameters and factors of the airline's choosing.
  • One example to compute a Comb_ND_Set is as follows.
  • a Seg_ND_Set is computed by first selecting earliest of the Notify Deadlines of each Leg within the concerned Segment, and then picking the latest of those Deadlines, and noting that as the Target_Deadline. Next step is to pick all those Notify Deadlines that fall after the Target_Deadline. Notify Deadlines thus obtained may be validated using various validation rules based on airline factors such as customer utility, flight parameters and so forth. Similarly, the Comb_ND_Set may thus be computed by repeating the above process for Seg_ND_Sets, thus obtained for each Segment.
  • the UFO capacity for an OFS may depend on one or more factors including, but not limited to, Notify Deadline, UFO Prices, expected Seat value in a flight and so forth.
  • An airline may use any method of its choosing to determine UFO capacity of a flight. For example, an airline may choose to have a fixed UFO capacity for one or more of its flights.
  • UFO Capacity is dependent on Notify Deadline.
  • the objective is to determine those Comb NDs within the Comb_ND_Set on which UFO is available for the given OFS.
  • the UFO Capacity and the Used UFO Capacity (the total number of Flights on which UFO has been sold but not exercised) may be calculated for each Comb_ND within the Comb_ND_Set.
  • Available Capacity (AC) would then be the difference of UFO Capacity and Used UFO Capacity for the given Flight. If the AC is greater than or equal to the number of incoming customers desiring a UFO, then the UFO capacity is available at a given Comb ND for the given OFS.
  • the process may be repeated for all Notify Deadlines within Comb ND Sets.
  • UFO may be made available on a given OFS for a given Comb ND, if UFO is available on all the Flights of OFS for the given Comb_ND.
  • An airline may set UFO Prices for a Flight Leg using any method of airline's choosing. Once the UFO Prices have been set for each Flight Leg, the next Act is to create a framework to compute UFO Price for a group of Flight Legs (such as a Segment, an Itinerary or any other group) by using UFO Prices for each Flight Leg in the group.
  • the parameter Leg_OP refer to UFO Price (and may or may not be corresponding to a Notify Deadline) associated with a Flight Leg.
  • Seg_OP and Comb_OP refer to UFO Price (may or may not be corresponding to a Notify Deadline) associated with a Segment and a combination of two or more Segments, respectively.
  • a set of Leg OPs, Seg OPs and Comb OPs is termed Leg_OP_Set, Seg_OP_Set and Comb_OP_Set, respectively.
  • the Comb_OP_Set is computed by combining the Seg OP Sets of the IFS and all the OFSs (existing and new).
  • a Seg_OP_Set is computed by combining the of all the Flight Legs under that Segment.
  • Seg_OP_Ru1es may be read from the airline's database and applied to calculate Seg OP Set for each input Segment (IFS and all OFSs) using the Leg OP Sets of all the Flight Legs of said Segment.
  • An airline may use any Seg_OP_Set Rule of its choosing.
  • Seg_OP_Rules may be defined to calculate Seg_OP as the sum, average, highest, lowest or any other function of Leg_OPs of all the Flight Legs at a given Comb ND.
  • a Comb_OP_Set consists of one or more Comb_OPs, and is calculated using one of the pre-determined rules, termed Comb_OP_Rules, to combine the Seg OPs of all the Segments in the combination.
  • An airline may use a Comb_OP_Rule of its choosing.
  • Comb_OP_Rules may be defined similar to the Seg_OP_Rules.
  • a customer receives all UFO Flights concurrently in one transaction.
  • An algorithmic illustration of an example of the Concurrent Get UFO process is displayed in Fig. 46.
  • the UFO (2, 1) instance is assumed here as an example.
  • the customer desires for UFO are input, including, but not limited to, a search criteria for Up Flights (may be similar to the search criteria defined above for the Sequential Get UFO process).
  • the UFO algorithm is run to determine the combinations of two Segments that satisfy inputs.
  • a list of such search results is displayed for the customer along with the associated terms and conditions including, but not limited to, Notify Deadlines, Initial UFO Price, UFO Exercise Price and Ticket Price for each such combination.
  • the UFO algorithm for the Sequential Get UFO process (defined above) may also be used for the Concurrent Get UFO process.
  • Act 46.120 the customer selects a desired combination of two Segments and the associated conditions such as UFO Exercise P ⁇ ce/Notijy Deadline.
  • Act 46.130 a payment transaction is executed, if needed. For example, the customer may pay the Ticket Price after taking into consideration the Initial UFO Price using a credit card, direct bank account debit or any other payment transaction mechanism.
  • the algorithm ends in Box 46.200. The computation may be performed using a processor that may calculate results in optimal time.
  • the processing goes to the Event Optimizer phase where different acts are executed depending on the trigger event that may occur to make an option to become exercisable.
  • the UFO Exercise Process and Customer Notification (or CN, in short) process
  • Act 39.200 is executed.
  • one or more decisions on the selection of Chosen Flight(s) is (are) notified to the customer.
  • the event(s) is (are) related to the value option selected in the first act.
  • the airline may use a software application built on the method defined above to optimally award the upgrades to customers who have bought a UFO.
  • Event Optimizer stage with the help of information technology tools has already been discussed above in a more generic fashion wherein said tools include, but are not limited to, one or more servers, database, load balancers, firewall, routers, Internet, highly secured VPN, Intranet, RAM, hard disk drives, CPUs, monitors as shown by Fig. 13E.
  • said tools include, but are not limited to, one or more servers, database, load balancers, firewall, routers, Internet, highly secured VPN, Intranet, RAM, hard disk drives, CPUs, monitors as shown by Fig. 13E.
  • One of the methods have been described later in the UTO Exercise Process. Another method is described below in detail for the UFO Exercise process.
  • the UFO VOF helps to create a flexible customer inventory.
  • an airline may obtain rights to allocate any of the selected UFO Flights to a UFO customer (i.e., award the upgrade to the customer), and thus, said UFO customer acts like a flexible customer inventory that the airline may manage to generate revenues.
  • An airline may design one or more uses of such flexible customer inventory, where each such use may include one or more events that follow the Initial Transaction.
  • An example (the Buy_N process) was explained earlier.
  • the Buy_N process an airline may use the UFO VOF to accommodate requests from potential customers for flights.
  • the Buy N process may especially be used to satisfy requests for flights that have already been sold or have low (or no) availability. The details for the Buy N process are presented below.
  • UFO VOF the Alternate Flight Option
  • An airline may form a group of one or more AFO customers and one or more UFO customers, where the options (AFO and UFO) obtained by the group members are complementary in nature.
  • A customer who bought an AFO to choose either of Fl and F2 as Chosen Flight
  • B customer who received a UFO and wants an upgrade from Initial Flight (i.e., Base-Flight) Fl to Option Flight (i.e., Up Flight) F2.
  • the airline may upgrade B and assign F2 as the Chosen Flight for B, and vice versa.
  • the customers A and B have taken complementary options and may form a group.
  • the airline may need to hold only one unit of inventory in Fl and F2 to satisfy the needs of both A and B (assuming each A and B only need one seat in a flight).
  • Such a combination of complementary options or VOFs may improve efficiency and concurrently enhance value for all the parties involved (in the given example, for A, B and the airline). More details on combining VOFs are provided later.
  • the UFO VOF may also be used to reduce operational costs, constraints or other goals that are impacted by the allocation of flights among different customers.
  • the UFO VOF may be used to shave off production costs by reducing production capacity for one or more flights and/or products that are low in demand. For example, if an airline experiences a flight with very low ticket sales, it could offer UFO to customers on that flight and thus, be able to economically and efficiently upgrade them to different flights and thereby be able to cancel said flight to save its flying costs (such as crew costs, staffing costs like gate agents, ground mechanics, maintenance costs and so forth) and even simultaneously generating revenue from said cancelled flight.
  • flying costs such as crew costs, staffing costs like gate agents, ground mechanics, maintenance costs and so forth
  • the cost in the Buy_N process and Upgrade U algorithm may also refer to the price that the customer may pay to the airline to receive an upgrade.
  • Fig. 47 displays a flow chart of an example of a Buy N algorithm, which is executed during a dynamic interaction between the customer and the airline.
  • an interaction may include a situation when a customer interacts with an airline to obtain (or purchase) tickets, or when an airline presents offerings to a customer (with or without a solicitation by the customer). It is assumed that a customer is interacting with an airline to purchase tickets, and that UFO VOF is implemented at the Segment level. This process may be implemented at Leg level and/or Itinerary level.
  • the search criteria are input.
  • Various search parameters for a desired Flight Segment are taken as the input to the system.
  • Act 47.110 a search process is executed to search for all Flight Segments that satisfy inputs. The details of the search process are described later.
  • Act 47.120 all the search results are displayed before the customer in an interface (such as in a web browser, a telephone operator stating the search results over the phone etc.).
  • Control then goes to Act 47.130, where the customer selects a Segment (or Flight Segment). The selection of the Segment may be followed by a payment and/or purchase of the selected Segment.
  • Act 47.140 a test is performed to determine whether Upgrade_U process has been applied on the selected Segment. If so, control goes to Act 47.150, where the Upgrade_U process is completed for the selected Segment, and control then goes to Box 47.200. If not, control goes to Box 47.200, where the algorithm exits.
  • the completion of the Upgrade_U process may include one or more Acts that may be executed to incorporate the fact that said Segment was selected by the customer. For example, one of such acts may be to record the selection of said Segment to a database and/or to change the Accounted Status for one or more UFO customers (who were affected in the Upgrade_U process).
  • Fig. 48 expands Act 110 of Fig. 47 and demonstrates an example of a search algorithm that may be used to determine Flight Segments that satisfy the inputs.
  • IC number of incoming customers
  • IC_Benef ⁇ t i.e., the benefit that an airline may receive if the incoming customers select and/or purchase one or more Segments
  • the input search criteria are taken as the input parameters to the system.
  • the term "Incoming Customers” refers to the customers who interact with the airline in the current transaction (Buy_N). It is assumed that each customer desire one unit of capacity seat) and thus, total units of capacity (seats) desired is equal to the total number of incoming customers.
  • ICJBenefit and/or IC may not be available as an input, and may be calculated during the search process.
  • Act 48.110 all the Segments that satisfy the 'search criteria' are searched from the airline database. The Segments, thus obtained, are added to a list termed LIST_Segment. The first element in the LIST_Segment list is designated as Current Segment.
  • Act 48.140 another test is performed to determine whether EAC (Effective Available capacity) of the Current_Leg is greater than or equal to IC. If so, control goes to Act 48.145. If not, control goes to Act 48.150, where the Upgrade_U algorithm is executed to determine the possibility (and associated process steps and costs) to create capacity in the Current_Segment.
  • Act 48.160 a test is performed to determine whether it is possible (by using Upgrade_U) to create capacity in the Current_Segment and the IC_Benefit is greater than or equal to the cost to create that capacity as determined in the Act 48.150. If both conditions are true, control goes to Act 48.170. If either condition is false, control goes to Act 48.165. In Act 48.165, the Current_Segment is discarded from the LIST Segment list, and control then goes to Act 48.170.
  • EAC Effective Available capacity
  • Act 48.145 a test is performed to determine whether more elements are left in the LIST_Leg list. If so, control goes to Act 48.135, where the next element in the LISTJLeg list is designated as the Current Leg and control loops back to Act 48.130, to repeat the process for the new Current_Leg. If not, control goes to Act 48.170.
  • Fig. 49 expands Act 150 of Fig. 48 and demonstrates an example of an algorithm to apply the Upgrade_U algorithm to create one or more than one unit of capacity (seat) in one or more Leg(s) within a Desired_Segment (the Segment in which capacity needs to be created).
  • various input parameters are taken in the system. Input parameters include IC, Desired_Segment and Incoming Benefit (i.e., benefit an airline may realize if capacity is created in the Desired_Segment)
  • control goes to Act 49.110, in which all the Rooms in the Desired_Segment are listed in the LIST_Leg list.
  • the first Leg in the LIST_Leg list is designated as Current Leg.
  • Act 49.120 a test is performed to determine whether the Available Capacity (AC) of the Current_Leg is greater than or equal to IC. If so, control goes to Act 49.130. If not, control goes to Box 49.300, where the algorithm ends.
  • Act 49.130 another test is performed to determine whether EAC (Effective Available capacity) of the Cur ⁇ ent_Leg is greater than or equal to IC. If so, then control goes to Act 49.140. If not, control goes to Act 49.150.
  • the Upgrade_U algorithm is called for each Ua in the Current_Leg and the algorithm follows a recursive loop. Each of the Ua becomes Current_Ua for the corresponding Upgrade_U call.
  • the necessary input parameters for each of the UpgradeJJ includes the Current_Leg as 'COPP', Current_Ua as 'COPU', Current Ua as 'Caller_U', Current Leg as 'Initiator Leg', one of the incoming customers as 'Initiator_U' and Incoming_Benefit as 'Benefit'.
  • the Upgrade_U call returns a U_Series collection for each Ua in the Current_Leg. The details of the Upgrade_U algorithm are discussed in the next section.
  • a P_Series collection for the Current_Leg is calculated through the following operations: (1) create groups of Ua from all Ua of the Current Leg for which Upgrade_U was called, where the number of Ua in each group is equal to "IC-EAC" (EAC of the Current Leg), (2) make combinations of the U Series collection of all members of each group (combine each Series Element of each U_Series of each member with that of each of the rest of the members of that group), (3) merge all members within each combination to formulate a merged Series_Element, (4) collect all such merged Series_Elements, thus obtained, into P_Series collection of the Current_Leg.
  • IC-EAC EAC of the Current Leg
  • Act 49.180 a test is performed to determine whether more elements are left in the LIST_Leg list. If so, control goes to Act 49.185, where the next element in the LIST_Leg list is designated as the Current_Leg and control loops back to Act 49.120 to repeat the process for the new Current_Leg. If not, control goes to Act 49.190.
  • a S Series collection for the Desired_Segment is calculated from the P_Series collections of all the Legs using the combination and merging process.
  • an optimal Series_Element from the S_Series collection is determined using Optimal_Series_Element Rule (which is read from a database).
  • control goes to Act 49.210, where the optimal Series_Element is returned and the algorithm exits at Box 49.300.
  • Fig. 50 represents an algorithmic illustration for Upgrade_U.
  • the Upgrade_U is a recursive algorithm, which returns a collection of Series_Element termed "U_Series" collection for the Ua for which the algorithm has been called.
  • a set of parameters including COPU, COPP, Caller U, Initiator Room, Initiator_U and Benefit are input to the system.
  • Act 50.110 all the Awaiting Segments of the Caller U are added to a list termed LIST_Segment.
  • the first- element in the LIST Segment list is designated as Current_Segment.
  • Act 50.120 all the Legs that belong to the Current_Segment are added to another list termed P_LIST.
  • the first element in the P_LIST list is designated as Current_Leg.
  • Act 50.130 a test is performed to determine whether the Current Leg is present in the COPP. If so, the Current Segment is discarded in Act 50.135, and control goes to Act 50.260. If not, control goes to Act 50.140.
  • Act 50.140 another test is performed to determine whether the Current_Leg is present in the Accounted_Segment of the Caller_U. If so, the Current_Leg is skipped in Act 50.145, and control then goes to Act 50.190. If not, control goes to Act 50.150, where another test is performed to determine if the EAC of the Current_Leg is greater than or equal to 1. If so, control goes to Act 50.220. If not, control goes to Act 50.160.
  • the algorithm enters into a recursive loop where the Upgrade_U algorithm is called for each of the Ua in the Current_Leg that is not present in the COPU. Each of the Ua becomes Current_Ua for the corresponding Upgrade_U call.
  • the necessary input parameters for each of the Upgrade_U includes 'COPP'- (includes the COPP of one level up Upgrade U and the Current_Leg), 'COPU' (includes the COPU of one level up Upgrade_U and the Current Ua), the Current_Ua as 'Caller_U', the Current_Leg as 'Initiator Leg', Caller U of one level up Upgrade_U as 'Initiator_U' and benefit of the highest level Upgrade U as 'Benefit'.
  • Each of the Upgrade_U call returns a U_Series collection for every Ua for which Upgrade_U was called.
  • Act 50.170 the algorithm receives the returned U_Series collection from all the Upgrade_U algorithm calls in Act 50.160. Control then goes to Act 50.180, where a P_Series collection for the CurrentJLeg is calculated by adding all the Series_Elements from all the returned U_Series collection obtained in Act 50.170. Control then goes to Act 50.190.
  • Act 50.190 a test is performed to determine whether more Legs are left in the P_LIST list. If so, control branches out to Act 50.200, where the next Leg in the P LIST list is designated as the Current_Leg, and control then goes to Act 50.130 where the process is repeated for the new Current Leg. If not, control goes to Act 50.230.
  • the S_Series collection is calculated for the Current_Segment by combining and merging all the P Series collection of all the Legs (not taking the skipped Leg(s) into consideration, if any).
  • a new ChildU is created using the Caller_U.
  • the ChildU consists of COI (where the current InitiatorJLeg is designated as Initiator_Leg and the current Initiator_U is designated as Initiator_U), Accounted_Segment of the Caller_U designated as the Initial_Accounted_Segment, current Awaiting_Segment designated as the Final Accounted Segment, and the cost to upgrade current Caller U from the Initial_Accounted_Segment to the Final_Accounted_Segment designated as the CCU.
  • the ChildU thus created, is added to every Series_Element in the S_Series collection and the CCU of the same ChildU is added to the CSE (Cost of Series Element) of every Series_Element. Control then goes to Act 50.250.
  • a Qualify_Series_Element rule is read from the airline's database and is applied to validate all the Series_Elements in the S_Series collection. The invalid Series Elements are discarded from the S Series collection.
  • An airline may select any rule of its choosing. For example, a Qualify_Series_Element rule may only qualify those Series_Elements for which the CSE is greater than or equal to the 'Benefit'.
  • control goes to Act 50.260.
  • Act 50.260 a test is performed to determine whether more Segments are left in the LIST_Segment list. If so, control branches out to Act 50.295, where the next element in the LIST_Segment list is designated as the Current_Segment, and then control loops back to Act 50.120, where the process is repeated for the new Cui ⁇ ent_Segment. If not, control goes to Act 50.270, where the U Series collection is obtained by adding all the Series_Elements of all the S_Series collections for all the Awaiting_Segments of the Caller_U. Next, the U_Series collection is returned in Act 50.280, and the algorithm ends in Box 50.300.
  • Combinations of P_Series in order to formulate S Series are calculated by cross multiplication of Series_Elements (of each P_Series).
  • An airline may choose to implement any method of its choosing to make combinations.
  • One method is as follows.
  • n number of Series say Si, S 2 , S 3 ... S n , with kl, k2, k3...kn number of Series_Element respectively.
  • Merging of a given number of Series Elements is done in a sequential process, where two given Series_Elements are merged together in one Act to obtain a single merged Series_Element (let's say M), and then the merged element, M, is merged with the third given Series Element to obtain a new merged element, and so on.
  • the main objective of merging is to ensure that the Series Elements created are valid and synchronized with each other with respect to capacity utilization of various legs involved.
  • a given unit of flight capacity (seat) at any given point must only be accounted for one customer, otherwise, it may lead to a shortage situation, where one seat is allocated to more than one customer leading to dissatisfaction for customers.
  • An airline may choose any method of its choosing to perform merging of Series Elements, and specifically to perform merging of two Series_Elements.
  • the method of merging chosen may affect the total value realized.
  • One example of such a method is given.
  • an airline may choose to discard all merged Series Elements that have either one or more common ChildU or common EndJLeg.
  • a common Chi IdU in two Series Elements suggest that in both Series Elements upgrading of one specific Ua is needed. If each Series_Element requires upgrading of Ua to two different Segments, it may present a contradictory situation.
  • a common End Leg in two or more Series Elements may require to upgrade more than one Ua customer to a specific flight, which may or may not be feasible depending on the AC (and EAC) of that flight.
  • a common End_Leg may also represent one or more contradictory or invalid situations.
  • a merged Series_Element, M obtained from merging of two Series Elements Sl and S2, may consist of the COEP (addition of COEP of Sl and S2), COCU (addition of COCU of Sl and S2) and CSE (addition of CSE of Sl and S2).
  • the Chosen Flight may be defined by the airline, the customer, another entity or any combination thereof. However, the airline may want to keep the right to select (or define) the Chosen Flight in the UFO VOF. An airline may use any method of its choosing to define the Chosen Flight. An airline may use a software application built on the method defined above to optimally define the Chosen Flight to UFO customer.
  • Fig. 51 displays an example of an algorithm that may be used to execute the Customer Notification process.
  • Act 51.100 a group of (one or more) customers is taken as input.
  • Act 51.1 10 a set of one or more Customer Notify Rules may be used to define the Chosen Flight.
  • An airline may choose any Customer Notify Rule of its choosing.
  • the Customer Notify Rules may depend upon expected value of the flight, expected sales volume and so forth. For example, a hotel may choose a Customer Notify Rule which selects the flight with the higher value as the Chosen Flight. Alternatively, a rule may be chosen, which selects the flight with the lower value as the Chosen Flight.
  • an airline may also want to use the Upgrade_U algorithm (as used in the Buy_N process given above) to determine the optimal Chosen Flight that satisfies a pre-determined goal.
  • one or more Ua may be upgraded in the process of selecting the optimal Chosen Flight.
  • a Customer Notify Rule may also select the flight with the higher sales volume as the Chosen Flight.
  • a Customer Notify Rule may specify that if UFO VOF is used in conjunction with any other VOF (such as FRO VOF and so on), then the Grouping Rules (defined later) may govern the selection of the Chosen Flight.
  • NFO Non-Stop Flight Option
  • the customers may be upgraded from connecting flights (i.e., flights with one or more stoppages) to non-stop (i.e., zero connection or direct) flights and hence may be termed as Non-Stop Flight Option (NFO) VOF or Direct Flight Option (DFO) VOF.
  • NFO Non-Stop Flight Option
  • DFO Direct Flight Option
  • a customer may experience one or more hassles associated with the connecting flights including, but not limited to, layovers between the connecting flights (which may vary from few minutes to hours and in some cases even to days), increased probability for baggage loss and/or damage, baggage handling at connecting airports, increase in travel time due to connecting flights, hassle of check in with handbags at the stops before boarding each of the connecting flight, change of terminals, distance between the terminals of the two connecting flights, security check lines and so forth.
  • layover time is too short, it may lead to missing of connecting flight and if the layover time is too long, it may check passenger endurance limit to the extreme.
  • Non-stop flights may add value in terms of saving traveling time and/or one or more of the above mentioned hassles.
  • NFO VOF structure may help an airline to generate revenues from the customer segment willing to pay more than the regular ticket price but is unwilling/cannot afford the high ticket price for non-stop flights.
  • Connecting flights may include, but not limited to, the flights with one or more connections, flights with one or more stoppages even though the flight number may or may not change and so forth.
  • the customer may buy NFO to upgrade to the higher priced non-stop flight (with no connections).
  • a payment transaction may or may not be executed at Initial Transaction.
  • the airline may award the upgrade to the customer on or before the stated Notify Deadline as per the terms and conditions of the option contract and may charge the customer for the upgrade price.
  • NFO VOF structure may help an airline in optimizing across various airline parameters, including but not limited to, load factors, customer loyalty and satisfaction, baggage handling, dealing with over booking problem in the flights, airport congestion, airport security, staffing issues and so forth.
  • NFO VOF may be implemented in the similar fashion as UFO VOF described above. All the algorithms of the UFO VOF may be implemented in NFO VOF structure including, but not limited to, in segmenting the customers, generating award lists, combinations, in upgrading a customer and having a new customer in his/her place and so forth.
  • the airline may generate some revenue initially as well by charging some initial price to the customers.
  • On or before the stipulated Notify Deadline if the airline feels that it has surplus inventory of seats in Flight F2, it may upgrade some NFO Customers (who have purchased/selected/received the NFO option for Flight F2 and are booked in Flight Fl) from Fl to F2.
  • the airline may charge customers exercise price for such upgrade.
  • NFO VOF may also be considered as a part of the UFO VOF.
  • the customers may assign higher preference to non-stop flights in comparison to connecting flights (with one or more stops). Said preferences may be used as value element "preference for higher ranked flights" as discussed in the UFO VOF.
  • the UPO VOF may be implemented in any industry.
  • the implementation of the UTO VOF in the airline industry is discussed here in.
  • the customer preference for higher ranked cabins is used as the targeted value element.
  • the selected value element i.e., the customer need for higher ranked cabins
  • the UPO VOF may be appropriately termed Upgrade Ticket Option (UTO) VOF.
  • UTO Upgrade Ticket Option
  • the first stage in the UTO VOF involves steps (or acts) of: capturing customer dynamics, assessing airline operations and economic factors, integrating customer dynamics with airline economic factors, formulating the VOF and optimizing the VOF.
  • the second stage involves carrying out a dynamic interaction with the customer and then executing an Event Optimizer process.
  • Up Cabin or Up Cabins refer to one or more cabins that rank higher than the other cabins present in the same flight. The ranking here is assumed to be based on past customer preference.
  • the lower ranked cabin is referred to as the “Base-Cabin”.
  • Base-Cabin also refers to the cabin to which a customer is currently booked.
  • an "Up Cabin” refers to any higher ranked cabin to which the customer may theoretically be upgraded to. For example, in a flight with first, business and coach cabins, the first class and business cabins would be referred to as Up Cabins and coach as the Base-Cabin.
  • the Base-Cabin for a coach customer is coach, and he/she may be upgraded to either of the two Up Cabins, first or business.
  • the Base-Cabin for a business cabin customer is business and he/she may only be upgraded to one Up Cabin, the first cabin. For simplicity, the following sections assume a flight with only two cabins, first and coach, unless mentioned otherwise.
  • the flight offering consists of a complex framework of value elements.
  • rankings may be presumed (or are implicit). For example, ranking for cabins (e.g., first or business cabin are ranked higher than the coach cabin), Ticket Price (e.g., lower prices are ranked higher than higher prices) and the number of connections (e.g., non-stop flights are ranked higher than connecting flights) may be presumed.
  • There are other product features for which the ranking is subjective and may not be easy to presume such as seating type (aisle or window), meals (desired or not), flight selection (one flight versus another) and so forth.
  • An airline may need to determine such rankings explicitly through interaction with various customers segments. As explained earlier, customers assign ranking to different cabin offerings.
  • a customer may classify the cabin offerings into different groups (that may or may not be mutually exclusive) and assign a relative rank to each of them.
  • rankings may be implicit or well established or well known; for which an airline may be able to assume/determine customer ranking that would satisfy the majority, based on an analysis of past customer behavior or other forms of market analysis.
  • the ranking may be very subjective; and may differ from one customer to another, and even for the same customer, may differ from time to time.
  • an airline may need to perform detailed interaction with customers to determine their ranking.
  • cabins with higher perceived utility (satisfaction) values are generally ranked higher than those with lower perceived utilities.
  • Most customers would prefer to get a higher ranked cabin over a lower ranked cabin.
  • customers may not get their desired cabin(s) due to unavailability, price or any other reasons or any combination of the above, they have to settle down with something below their desired value.
  • Fig. 54 shows an analysis of the value elements that are believed to matter the most to customers in relation to a flight cabin upgrade.
  • important value elements may include, but are not limited to, customers' preference for higher ranked cabins, seat assignment, seating comfort and space, in-flight food and other amenities, special characteristics and/or features, if any, associated with the flights, priority check-in and boarding and special luggage handling.
  • important value elements may include, but are not limited to, Ticket Price and upgrade price.
  • important value elements may include, but are not limited to, time to request and get upgrade award, and how long before departure the ticket must be purchased for the customer to be entitled to an upgrade.
  • important value elements may include, but are not limited to, the ease of getting the upgrade. It may be important to estimate the relative preferences and utilities of these value elements to customers for various cabins.
  • An assessment of the crucial economic factors for an airline may reveal these factors to include, but not be limited to, the fixed and variable costs across various cabins, non-uniform distribution of demand across different cabins, higher price for higher ranked cabins, perishable inventory of seats, varying capacities of higher ranked cabins much more than the capacities in lower ranked cabins, possibility of revenue dilution, lost opportunity costs in offering free upgrades to customers through existing upgrade programs (if any) and so forth.
  • the marginal costs of carrying an additional customer in different cabins the number of unused seats after departure, increased competition from low cost carriers, the need to develop competitive advantages against low cost carriers, customer attrition rate, and commoditization of the airline industry.
  • One may dig deeper into details for different cabins such as load factors, spoilage, seat availability, costs per customer mile, marginal costs per customer mile, lost opportunity costs in offering free upgrades to customers through existing upgrade programs, and so forth.
  • An assessment of the crucial economic factors, such as costs, constraints and capacities, may be performed, to determine the factors that affect the profitability, growth and goals of the airline. It might be beneficial if the airline utilizing the inventive system and method were able to express cost elements in a real-time or quasi-real-time (i.e., up to date) dynamic fashion so that such information may then be used to assess the profitability or contribution of each sale opportunity (at the cabin level) , and to facilitate the operation of the Event Optimizer (so that offers and actions may be based on realtime or near-real-time information).
  • Fig. 55 also illustrates an example of how a mapping may be done, between customer value elements and airline profiles, for the UTO VOF.
  • customers who prefer first cabin to coach cabin or, in generic terms, there is a preference for a higher ranked cabin over a lower ranked cabin.
  • customers are also concerned about the price differences between the higher ranked and the lower ranked cabins. All customers may not afford to buy confirmed higher ranked cabin seats at regular prices. However, many customers would be willing to pay more than their Ticket Price to get seats in the higher ranked cabins (such as first cabin).
  • An opportunity thus, exists to concurrently generate an incremental revenue benefit for the airline from consumer surplus, and to maximize the purchase utilities for the customers as a group (including those who have a preference for higher ranked cabins at appropriate prices). More specifically, as shown in the interaction between the Box 55.210 and Box 55.220, a mapping is performed between important customer value elements and airline economic factors. The value element "preference for higher ranked cabins" is extracted, as shown in Box 55.230, and the UTO framework is created.
  • Fig. 56 displays the structure of UTO value option framework (shown in Box 56.100) in the airline industry.
  • the UTO VOF is related to the value element "preference for higher ranked cabins", as shown in Box 56.1 10.
  • the customer receives a conditional option for an upgrade and the airline awards the upgrade to the customer provided at least one condition on the option is satisfied.
  • a customer may select (purchase) one or more Base-Cabins and then select UTO option on one or more Up Cabins.
  • An airline may award one or more Up Cabins from the selected UTO Cabins or from other cabins) or any combination thereof.
  • UTO Cabins In another implementation of UTO VOF, during a successful Initial Transaction, a customer receives an option to utilize up to 'n' out of 'm' selected cabins (said 'm' cabins termed "UTO Cabins").
  • the 'n' cabins that are finally selected are termed "Chosen Cabins ".
  • the customer has the right to utilize (or may utilize) said Chosen Cabin.
  • the remaining cabins are termed "Released Cabins”.
  • the Released Cabins (if any, that were held or blocked for said customer) may be sold to other customers as normal flights or UTO Cabins or used for other purposes.
  • the Released Cabins in relation to said option may be reused by the airline before, after, at or any combination thereof, the time the Released Cabins and/or Chosen Cabins are defined (or received or selected).
  • the m UTO Cabins would contain all the selected Base-Cabins and Up Cabins
  • the n Chosen Cabins would contain all the defined Base-Cabins and Up Cabins that the customer may utilize.
  • the customer may prefer to receive only Up Cabins in the defined n Chosen Cabins, since the customer would have higher utility for the Up Cabins, however, the Chosen Cabins may contain Up Cabins or Base Cabins or both.
  • the value of 'm' is greater than or equal to 2 and the value of 'n' may vary from '0' to 'm' depending upon the specific implementation of the UTO framework.
  • the value of 'm' and/or 'n' may be known (or defined and/or re-defined) before, during, after the Initial Transaction and/or any combination thereof.
  • the value of 'n' may or may not be known (or defined and/or re-defined) at the time of the Initial Transaction.
  • the value of 'm * and/or 'n' may be defined by the airline, the customer, another entity or any combination thereof.
  • the value of n may not be defined at the time of Initial Transaction.
  • the value of m is redefined after being defined at least once before, the new value of 'm' may be greater than or less than the older value of 'm'.
  • the new value of 'n' may also be greater than or less than the older value of 'n'. In some of the cases, the value of new 'n' may be even greater than the older value of 'm ⁇
  • the UTO Cabins may be selected by the airline, the customer, another entity or any combination thereof.
  • the UTO VOF may enable an airline to obtain preferences for Up Cabins from UTO customers (i.e., those who select UTO) and use said preferences to satisfy the travel needs of other customers and/or to optimize the value for airline, customers, another entity and/or any combination thereof. Therefore, the airline would usually have the right to select (or define) the Chosen Cabins.
  • the airline, the customer, another entity or any combination thereof may select one or more of the Chosen Cabins related to a UTO.
  • the UTO Cabins and the Chosen Cabins may be selected by the same entity, different entities or any combination thereof.
  • the customer may select the UTO Cabins and the airline may select the Chosen Cabins out of the UTO Cabins.
  • the airline may incorporate the customer information and the data related to the UTO into the sales, production, inventory, other database or information system or any combination of the above.
  • the option granted to the customer may conditional.
  • One such condition (to upgrade) may be the seat availability in the Up Cabin associated with the option. It may be possible that the seat availability in the Up Cabin associated with the option is the only condition included in the UTO VOF. If so, after receiving the UTO, a customer may receive a right to be upgraded if there is seat availability in the Up Cabin at a certain time and under certain conditions established as the terms and conditions of the option contract.
  • the time when an Initial Transaction is completed i.e., the customer receives a UTO
  • ITT Initial Transaction Time
  • One or more Base- Cabins and Up Cabins may be selected, at one or more times, before, after, during, or any combination thereof, the Initial Transaction and/or the time said option is delivered to the customer (or the customer receives said option) or any combination thereof. All the UTO Cabins may be selected concurrently (i.e., all together in one transaction) or sequentially (i.e., in multiple transactions). In the sequential case, a customer may select one or more cabins in one or more transactions before the Initial Transaction.
  • Said selected cabin(s) (let's say X number of them), thus, may be considered as part of m UTO Cabins of the UTO (m, n) transaction, and the customer may select only the remaining (m - X) number of UTO Cabins during the Initial Transaction. All the transactions used to select (or receive) all the Base- Cabins of a UTO transaction may be related to each other, and hence, may be considered as "related transactions".
  • the sequential process may consist of a number of "related transactions" when all the UTO Cabins are received one after another by paying/receiving a price in one or more transactions or acts.
  • the price may include, but is not limited to, a monetary value, coupons, discount vouchers, other benefits such as loyalty program benefits, frequent flyer miles or any combination of the above.
  • the transactions may be related due to a relationship during the Initial Transaction, one or more of the previously executed transactions, any other transaction or combination thereof.
  • the UTO VOF may also impose other conditions on the airline and/or the customer.
  • the option may impose a payment obligation on the customer if the airline upgrades said customer.
  • the option may confer a right upon the airline to enforce payment obligation on the customer.
  • the airline may take a pre-authorization from the customer to charge the customer using any payment mechanism including, but not limited to, credit card, debit card, debit bank account, third party payment service provider, advance payment by the customer, any other means, or combination thereof.
  • the airline may award the upgrade to the customer only if the airline receives a payment from the customer in relation to said upgrade.
  • the customer may be required to pay one or more prices at one or more times to receive the option for the upgrade.
  • the airline may award the upgrade to a selected group of customers based on any criteria of airline's choosing. For example, an airline may choose to give preference to its frequent flyer customers or high value customers over others.
  • the UTO VOF may also confer a right on the customer to enforce said upgrade provided at least one condition on said option is satisfied. For instance, an airline may offer UTOs with preference orders attached to it, i.e., if a customer purchases (or receives) a UTO with a preference order of 1, said customer shall have the right to be the first customer among others to be awarded the upgrade.
  • the UTO VOF may also impose a condition on the airline to offer the Up Cabin to the customer and the customer may have the right to choose between the Base-Cabin and Up Cabin and subsequently notify the airline about the Chosen Cabin.
  • a customer may or may not be under a mandatory condition to accept the Chosen Cabin as selected by the airline.
  • the airline or the customer may have the right to enforce the Chosen Cabin on the other party as per the terms and conditions of the option contract.
  • the Box 56.200 illustrates an example of the Initial Transaction between the customer and an airline, where the airline offers the CF (UTO) value option to the customer.
  • CF CF
  • a customer may be required to pay a price ($X) to receive said option for an upgrade from the cabin (Base-Cabin) to the first cabin (Up Cabin), and to agree to pay another amount ($Y) to the airline if the airline (then or later) upgrades the customer to the first cabin.
  • An airline may choose to create one or more instances of the UTO VOF based on factors including, but not limited to, number of UTO Cabins, Up Cabins respectively or Released Cabins, pre-determination of a number of Up Cabins or Released Cabins, other factors or any combination thereof.
  • factors including, but not limited to, number of UTO Cabins, Up Cabins respectively or Released Cabins, pre-determination of a number of Up Cabins or Released Cabins, other factors or any combination thereof.
  • a UTO based on a combination of the number of UTO Cabins (or m) and Chosen Cabins (or n) would be UTO (m, n).
  • Some or UTO instances are shown in Boxes 56.120, 56.130, 56.140 and 56.150.
  • the customer selects two UTO Cabins and the airline may select any 'one' of those two cabins as the Chosen Cabin depending on whether upgrade is available or not.
  • the UTO (4, 2) instance may imply that the customer receives 4 UTO Cabins, on the condition that the airline may select any 2 out of 4 Cabins as Chosen Cabins.
  • the UTO (4, 2) instance may imply that the customer receives 4 UTO Cabins, on the condition that the airline may select none, one or 2 Chosen Cabins out of UTO Cabins. There may also be a minimum limit on n.
  • UTO VOF implementations may also have price conditions to the customer.
  • a customer receives a UTO to receive two out of any four selected UTO Cabins, consisting of two Base-Cabins, Bl and B2, and two Up Cabins, Ul and U2.
  • the customer has made an Initial Payment of $1000.
  • the airline may define any two cabins as Chosen Cabins out of the 4 cabins as per the terms and conditions of the option contract.
  • the Initial Transaction may have terms and conditions applicable to the customer, the airline, any other entity or any combination thereof. These terms and conditions may be set, preferably, to concurrently benefit at least two of the above said parties.
  • the connections between Box 56.200 and 56.220, and Box 56.200 and 56.210 refer to the terms and conditions to the airline and the customer, respectively.
  • the UTO VOF may or may not include any constraints on the UTO Cabins.
  • an airline may restrict UTO applicability and availability on cabins that satisfy specific criteria.
  • the two UTO Cabins may or may not include practically constrained cabins.
  • Practical constraints may include one or more constraints that will prevent a customer to utilize a given cabin or prevent the customer from utilizing all the UTO Cabins and are applicable when the Up Cabin is in a flight other than the flight in which the customer has the Base-Cabin.
  • constraints may include, but are not limited to, time constraints, location constraints and so forth. In other words, it may or may not be practically possible for a customer to utilize both the selected cabins due to at least one practical constraint.
  • one flight may be scheduled to be airborne when the other flight is scheduled to depart, thus not allowing any customer on the former flight to take upgrade on the latter flight, or the distance between the departure airports of the two flights may prevent customers from flying on both flights (that depart within hours of each other).
  • a customer may select (or receive) UTO Cabins in several ways; through mutual agreement (e.g., during a direct interaction such as a purchase for ticket for a flight), or the airline may grant the UTO Cabins to the customer without soliciting their interest or permission. For example, to enhance customer satisfaction or for any other purpose, an airline may grant UTO Cabins to customers based on the past customer behavior, interaction and so on.
  • the Initial Transaction may impose one or more conditions on the airline.
  • An airline may be required to explicitly notify the customer prior to or no later than a given date and time (referred to as the Notify Deadline) regarding the Chosen Cabin. If there is no such explicit notification condition, the Chosen Cabin may be decided as per the terms and conditions of the option contract. In either case, (explicit or implicit notification), the date and time when the selection of the Chosen Cabin is notified to the customer is referred to as the Customer Notification Time (or CNT, in short). In the current discussion, the explicit notification condition is assumed unless specifically mentioned otherwise.
  • the Notify Deadline may be pre-determined or may be determined later (i.e., after the Initial Transaction) by the airline, the customer, any other entity, or any combination thereof.
  • An airline may determine one or more Notify Deadlines for a cabin at one or more times (e.g., before, during, after the Initial Transaction or any combination thereof) using factors including, but not limited to, customer needs, expected value of the seat, airline profitability goals, any other factors or any combination of the above. Customer factors should also be considered in determining the Notify Deadlines, such as the upgrade periods desired by customers, or any other factor that may affect the behavior of a customer.
  • the Notify Deadline may be pre-determined or may be determined later (i.e., after UTO grant) by the airline, the customer or mutually by both.
  • the terms and conditions of the UTO VOF may not allow the airline to notify the customer after the last Notify Deadline (i.e., the latest among the Notify Deadlines).
  • flexibility may also be provided to the customer to notify the airline about the Chosen Cabin up to a stipulated Notify Deadline, once the airline has offered the Up Cabin to the customer.
  • a rule may be set that if the airline fails to notify the customer before the last Notify Deadline, the Base-Cabin becomes the Chosen Cabin and no upgrade is provided to the customer.
  • Another approach may be set that if the customer fails to notify the airline about the Chosen Cabin once the upgrade has been offered to him/her by the airline, one or more of the Base-Cabins, Up Cabins and/or any combination thereof may be considered as the Chosen Cabin.
  • the airline may select Up Cabin as the Chosen Cabin and may charge Exercise Price and/or any other price to the customer.
  • the airline may select the Base-Cabin as the Chosen Cabin and a price may or may not be charged. Any entity (e.g., the airline or the customer) may (or may not) be allowed to change the Default Cabin once it is selected.
  • the UTO Exercise Price (if any) in the default case may or may not be equal to the UTO Exercise Price for the Default Cabin for the last Notify Deadline. In the current discussion, a single Notify Deadline is assumed.
  • the customer may be required to pay one or more prices during the Initial Transaction (and/or to receive a UTO, referred to as an Initial Price), at the CNT (and/or the time the customer is upgraded, referred to as an Exercise Price) and/or at any other time, which may or may not be pre-determined between the customer and the airline.
  • the UTO Price may be a pre-agreed fixed amount or it may be variable with or without bounds and set later or any combination of the above.
  • the initial price and/or the exercise price may or may not be uniform for all UTOs designed and/or offered to the customers; an airline may choose any combination of uniform and/or non uniform prices for the initial and/or exercise price.
  • the airline may offer the customer a set of prices to choose from. Since price conditions may depend upon various factors, which may or may not be variable, the same may be decided at anytime.
  • the price conditions may be determined by the customer, the airline, another entity, or any combination thereof at one or more times.
  • One or more prices (UTO Initial or UTO Exercise or any other price) may be a negative value, which reflects that instead of the customer paying the airline, the airline shall pay a price to the customer to get the desired cabin as the Chosen Cabin.
  • One or more of the UTO prices may be embedded with the Ticket Price.
  • a customer may be presumed to accept the UTO offer while displaying the embedded Ticket Price. These presumptions may (or may not) include soliciting prior interest of the customer regarding the UTO offer.
  • the customer may or may not receive a separate price for UTO.
  • the UTO Price(s) may or may not be embedded within the Ticket Price.
  • the customer may make the payment directly or indirectly (e.g., through a third party) to the airline in relation to said upgrade.
  • the price may consist of a monetary value or a soft/non-monetary value (e.g., coupons, discount vouchers, other benefits such as loyalty program benefits, frequent flyer miles, exchange of another service) or other consideration or any combination of the above.
  • a price may include, but is not limited to, a set of one or more Ticket Prices, a set of one or more UTO Prices (initial and/or exercise) or any combination of the above.
  • An airline may choose to implement UTO Prices in many ways. An airline may use the method of its choosing to decide on the Ticket Prices of all the flights.
  • the UTO Price (Initial, Exercise, and/or any other price, or any combination thereof) may be a function of number of UTO Cabins and/or Chosen Cabins, specific cabins to be granted for UTO Cabins, Up Cabins and/or Chosen Cabins, Notify Deadline, one or more Ticket Prices, any other factors of airline's choosing or any combination of the above.
  • Various option pricing strategies may be employed. For example, in a fixed price strategy, a user may be shown only one fixed price for the option. If the user purchases the option at a price much lower than his/her maximum price, the potential benefit for the airline is less than what could have been achieved
  • Bidding may help to determine the highest price a user is willing to spend for the upgrade.
  • the user may provide his/her highest offer for the final price.
  • the airline may charge the lowest price (less than the highest offer price selected by the user) that delivers the upgrade to the user. If even the highest offer price chosen by the user is lower than the minimum price needed to get the upgrade, then the user is not awarded the upgrade.
  • the highest offer may be input free form or the airline may provide a few choices from which the user may select one. The airline may also ask, or determine empirically, how much customers will pay for the option.
  • the assumption here is that customers make a logical decision to choose the Up Cabin and may afford to pay the sum of the initial and the exercise prices (if any).
  • the customer may or may not have to pay during the Initial Transaction.
  • Initial Price may be subsequently returned to the customer, if the upgrade to the Up Cabin is not awarded to the customer.
  • Exercise Price may also be adjusted with the Initial Price paid by the customer.
  • the airline may issue a UTO Pass for the customers in order to facilitate another payment mechanism. The payment for the ticket and/or the option may be made using the UTO Pass.
  • a time based UTO Pass may allow a customer to only be upgraded to the flights that fall within a specified time period.
  • a value based UTO Pass may allow a customer to get upgrades until the sum of the total payment needed for all the upgrades is less than or equal to the value of the UTO Pass.
  • the airline and/or another entity may create various types of UTO Pass.
  • the payment transaction may include, but not limited to, direct payment received by the airline from the customer, in lieu of relinquishment of one or more rights by the customer, indirect revenue generation (e.g., the customer relinquishes his/her right or accepts a lower limit on the baggage to allow the airline to sell the preserved cargo capacity for other revenues or other purposes)), costs savings obtained (e.g., the customer relinquishes his/her right to meals which saves costs for the airline), enhanced customer service and loyalty and so forth.
  • direct payment received by the airline from the customer in lieu of relinquishment of one or more rights by the customer
  • indirect revenue generation e.g., the customer relinquishes his/her right or accepts a lower limit on the baggage to allow the airline to sell the preserved cargo capacity for other revenues or other purposes
  • costs savings obtained e.g., the customer relinquishes his/her right to meals which saves costs for the airline
  • enhanced customer service and loyalty so forth.
  • Each said event may be associated with various terms and conditions on the customer and/or the airline.
  • the airline and/or the customers may have the right to enforce the Chosen Cabin(s) on the other party as per the terms and conditions of the option contract.
  • the terms and conditions of the option contract may be binding on the airline and the customer only if the customer successfully accepts the airline's offer of the option for the upgrade.
  • the customer may be given a choice of options to choose from and take a decision.
  • the airline may implement negative UTO, i.e., instead of upgrading the customer to an Up Cabin, the airline may downgrade the customer to a lower ranked cabin. The airline may implement such negative upgrade in one or more situations.
  • the airline may implement negative upgrade (downgrade) when there may be huge demand for Up Cabins at very high prices so that the airline may downgrade the customer who may have already bought the Up Cabin at relatively lower prices and may be willing to accept the lower ranked cabin in lieu of some or more rewards.
  • the airline may implement it in case there is huge demand for lower ranked cabin.
  • the airline may offer the Up Cabin to the customer and may give an option to downgrade to lower ranked cabin in future in case one becomes available.
  • the airline may offer discounts on higher ranked cabins, may offer to return the difference between the lower ranked cabin and higher ranked cabin, may offer additional reward to the customer and so forth.
  • the airline may be able to retain the customer (and not to lose him/her to the competitor) even in the event that the customer is desiring a lower ranked cabin and the capacity of which may be exhausted with the airline.
  • the airline may also be successful in this case in creating a flexible pool of customer inventory.
  • the terms and conditions of the UTO VOF may require the customer to purchase (or pay price for reserving) both the lower ranked and higher ranked cabins with a condition to cancel/return either of the two cabins as per the terms and conditions of the option contract.
  • a customer reserves a higher ranked cabin for $700 (when its actual price is $1500) and a lower ranked cabin for $550 (when the actual price is $555) with a condition to cancel reservation for at least one of the cabins.
  • the customer has paid $1250 for reserving both the cabins with a condition to cancel the reservation for at least one of them.
  • the terms and conditions of the option contract may provide different cancellation charges in different situations.
  • the terms and conditions of the option contract provides cancellation charges for higher ranked cabin as $10 where as the same for lower ranked cabin are $1000. So, logically the customer will go for cancellation of higher ranked cabin and in this case he would be refunded $690 and hence the net amount paid by the customer for getting the lower cabin would be $560 ($1250 minus $690) which may be equal to the Ticket Price of the cabin ($555) plus Initial UTO Price ($5). In this case, the customer has not received the upgrade. Now, consider another case when the higher ranked cabin is available. The terms and conditions of the option contract provide cancellation charges in this case for higher ranked cabin as $1500 where as there is no cancellation charges for cancelling the lower ranked cabin.
  • the customer will cancel the lower ranked cabin and hence he would be refunded $550. So, the net amount paid by the customer for getting the upgrade (i.e., the higher ranked cabin) is $700 ($1250 minus $550) instead of paying the full price (of $1500) for getting the higher ranked cabin.
  • the assumption here is that customers make a logical decision to choose which cabin to cancel.
  • a UTO VOF may include a right for an airline to upgrade the customer to an Up Cabin before a stated Notify Deadline.
  • the right may include the condition that the airline may notify the customer before, at or after the stated Notify Deadline or any combination thereof.
  • the airline may offer (or allow) the customer to finally choose the Chosen Cabin once the airline notifies the customer about the availability of the Up Cabin.
  • the Initial Transaction i.e., once the option has been granted (and/or sold) to a customer, there may be one or more potential events related to the associated UTO option.
  • the CF (UTO) option there are two related events for the CF (UTO) option, namely, 1) the flight has availability in the first cabin (Up Cabin) for at least one seat (shown in Box 56.250) and 2) the flight has no seat availability in the first cabin (Up Cabin), as shown in Box 56.240.
  • the customer may be given one or more Up Cabins if said Up Cabins are available in Level 2 or higher events related to the UTO option, later on. It may also be possible that even when one or more Up Cabins are available in Level 1 event which may or may not be given to the customer in Level 1 event, still later on, in Level 2 or higher events, if one or more Up Cabins are available, said one or more Up Cabins may be offered (given) to the customers. Said one or more Up Cabins may be given by the airline, another entity and/or by both. The Up Cabins given in Level 2 or higher events may be given in exchange of one or more previously given Up Cabins or in addition to the earlier given Up Cabin(s).
  • the airline may use any method it chooses to allocate the upgrades, such as assigning priority based on time of purchase, Ticket Price paid by the customer, random selection or any other customer priority factors like frequent flyer miles etc.
  • the airline may also award cabin upgrade to a customer in the same flight in which he/she is traveling or may give an option to get an option to get an upgrade in more than one flight or the airline may upgrade the customer to some other flight as well.
  • An airline may choose to bump one or more customers from one or more flights in order to create availability to award one or more upgrades to UTO customers.
  • the airline may inform the customer of the decision related to the upgrade award via any communication channel including, but not limited to, a re-issued ticket sent over email, an email, phone, in-person at an airline counter, or may ask the customer to contact the airline to know the decision.
  • an airline gets to know the relative preferences and utilities for travel in the first cabin (higher ranked cabin) over the coach cabin (lower ranked cabin) as some customers purchase this option and others don't. This may lead to an enhanced revenue benefit for the airline as well as higher travel utility to the customer. There may be some increase in costs for the airline (for example, to carry the customer in the first cabin versus the coach cabin), but generally, the additional revenue generated would be more than sufficient to account for the additional upgrade costs (if any).
  • the airline may better optimize its seat availability in the first cabin and may possibly be able to intake additional customers in coach cabin due to the additional seats created in coach (after a coach customer is upgraded to the first cabin).
  • An airline may estimate the total number of expected upgrades and using the same, may estimate the number of vacated seats (due to potential upgrades) in the coach cabin (or other lower ranked cabins). Using this estimate, an airline may be able to add back these seats to the airline inventory to be used for potential sales and/or other purposes.
  • Fig. 57 provides details on four typical instances of UTO, namely, CB, CF, BF and CBF, that an airline may create in the event there are three cabins (coach (C), business (B) and first (F)) in a flight.
  • a sold UTO may be defined by four parameters such as in the notation MN (I, F),where, M is the Base-Cabin (the current cabin of the customer when the option is purchased), N is the Up Cabin to which the owner of the option may be upgraded, I is the initial price paid by the owner to buy the option, and F is the exercise price which will be paid by the owner if and when he/she is upgraded.
  • a customer booked in the coach cabin may purchase a CF or "coach to first" option to get an upgrade to the first cabin if one becomes available.
  • a CB or "coach to business” option may be purchased by a customer with a coach ticket to get a potential upgrade to the business cabin if one becomes available.
  • a CBF or a "coach to business or first” option may be made available to a customer who purchased a coach ticket, for a potential upgrade to either the business or the first cabin, depending on availability.
  • a BF or "business to first” UTO may be made available to a customer with a ticket for the business cabin, for potential upgrade to the first cabin seat if one becomes available.
  • UTO When a flight has only two cabins, (coach and first), there may be only one instance of UTO, namely, CF. Obviously, the number of cabins within a flight affects the total number of UTO instances. The number of UTO instances typically increases with an increase in the number of cabins within a flight. The number of instances does not have to be equal to the number of cabins, of course. An airline may create additional factors that could increase or decrease the number of product levels and, thus, option instances. Some examples are given below such as to divide a cabin into sections with different legroom or meal service. Other amenities/services might be the basis for another arrangement of UTOs. An airline may choose to create one or more instances of a UTO VOF based on factors including, but not limited to, number of cabins, customer needs, customer ranking across various products, in-flight amenities, other amenities or products offered or any other factors.
  • An airline may choose any set of criteria to create different levels of its product offerings.
  • An airline may choose to subdivide a physically distinct cabin into two or more sections, where each section may act as a separate product level or referred to as an individual 'cabin' with a different level of service and utility to customers.
  • Some airlines divide coach cabins into two sections that offer different legroom to customers.
  • the coach section with greater legroom (Cl) may be priced higher than the section with the smaller legroom (C2). This creates a difference in the utility provided by the two sections to customers.
  • Another example is to subdivide an Up Cabin (for example the business cabin) into two sections, Bl and B2 that provides different meal services, (e.g., Bl has a meal service, whereas B2 does not).
  • Such divisions may enhance the number of product levels. For example, using the above two examples, a flight with three physically distinct cabins (e.g., coach(C), business(B) and first(F)) will have 5 levels of cabins/products to sell (Cl, C2, Bl, B2 and F).
  • UTO Types Creator Algorithm to create UTO Types or instances
  • UTO Types creator algorithm has been explained in detail in the UPO VOF.
  • the implementation of UTO Types Creator Algorithm in the context of the airline industry has been explained through an example given below.
  • the algorithm of Fig. 58 may be used to create UTO instances in the airline industry, as follows.
  • the priority order among the cabins is A>B>C>D, where the cabin A has the highest rank and the cabin D has the lowest rank.
  • a Set of Cabins is input to form the SP, with cabins sorted according to the descending order of priority, A>B>OD.
  • the BP is set to D and the CUP is set to comprise cabins C, B and A.
  • Option_Creator (D, [C, B, A]) is called, the notation (D, [C, B, A]) indicating D is input as the BP and the CUP is input as the set [C, B, A].
  • the OC of the current level is initialized as an empty set. Then, a combination is formed of each Up Cabin in the CUP set [C, B, A] with Base- Cabin D and these combinations are added to the Option_Collection to form OC [DC, DB, DA], per Act 58.150.
  • the current CUP set [C, B, A] is assigned as the new SP and the lowest cabin in the new SP, i.e., C, is the new BP, per Act 58.160.
  • a test is performed to determine if the CUP set is empty.
  • control is at Act 58.200, where C, the BP of the current level Option_Creator (C, [B, A]) is combined with each member of the returned OC[BA] from the lower level and the result [CBA] is added to the OC[CB, CA] of the current level.
  • Control goes to Act 58.210, where the returned OC[BA] is added to the OC of the current level.
  • a financial analysis may be performed on the UTO VOF using the existing airline and customer data to determine the optimal terms and conditions of the UTO VOF. 'What-iP scenarios may be executed to determine the optimal pricing strategy.
  • the airline may want to divide its customers into one or more customer segments, and design UTO VOFs separately for each customer segments.
  • the airline After completing the first stage of the method, the airline has created a UTO framework and specific value options within that framework. The airline has also segmented customers. The airline is fully prepared now to use a structured format consisting of UTO value options to interact with its customers in real time to generate benefits for both customer and airline. The second stage of UTO VOF is now presented.
  • the implementation of the UTO VOF between the customer and the airline takes place through two high level acts, as shown in Fig. 59.
  • the 'Get UTO' process an interactive event between the customer and the airline web server, runs to carry out the Initial Transaction of the UTO VOF.
  • a number of algorithms are executed on the airline's server to optimally calculate the terms and conditions of the UTO VOF (e.g., availability, UTO Price(s) and other conditions) to concurrently benefit both the airline and the customer.
  • an event optimizer process called the UTO Exercise Process (explained later) is executed.
  • the airline may awards the upgrade to the customer based on the terms and conditions of the option contract and the Chosen Cabin is notified to the customer.
  • the process may also consist of one or more event optimizer algorithms that may help to optimally select the Chosen Cabin and/or to optimally use (or reuse) the Released Cabin.
  • the Get UTO process may be implemented via the Sequential (shown in Fig. 63) or the Concurrent (shown in Fig. 65) process.
  • the terms, Leg, Segment and Itinerary correspond to the terms, Product, Set and Order, respectively.
  • a customer may select (or purchase) a Leg/Segment/Itinerary before the Initial Transaction begins. In such situations, said Leg/Segment/Itinerary may be referred to as Initial Leg (Cabin)ZInitial Segment/Initial Itinerary or IL/IS/II, in short, respectively.
  • the Initial Segment is also referred to as Initial Flight Segment (or IFS, in short).
  • IFS Initial Flight Segment
  • a customer may get a UTO, i.e., get one or more UTO Legs (Cabins)/Segments/Itineraries on an IL/IS/II, respectively.
  • a UTO Legs Cabins/Segments/Itineraries on an IL/IS/II, respectively.
  • Option Leg/Option Segment/Option Itinerary or OL/OS/OI
  • An Option Segment is also referred to as Option Flight Segment (or OFS, in short).
  • the two events one for the Initial Flight i.e., cabin, and the other for the Initial Transaction
  • the UTO VOF may be implemented at different levels including, but not limited to, Itinerary, Segment and Leg.
  • An airline may choose to implement the UTO at any level(s).
  • the implementation level should be the same for all the UTO Cabins, Chosen Cabins and Released Cabins. For example, if UTO is implemented at the Itinerary level, then all the UTO Cabins and Chosen Cabins would refer to UTO Itineraries and Chosen Itineraries, respectively.
  • a customer interacts with the airline's server to receive a UTO.
  • the interaction may take place (for example) via phone, in-person or on a website.
  • the Sequential Get UTO Process is presented first along with its detailed algorithms, followed by a short summary of the Concurrent Get UTO Process.
  • the Figures 60, 61 and 62 show a series of web pages that could be displayed in a customer's browser by an airline's web server, providing a practical example of the Get UTO process, consisting of how the interaction may take place, between a customer and an airline, when the customer comes to purchase UTO (during or after the ticket is purchased).
  • the Fig. 60 shows an Itinerary selected and/or purchased by a customer. The customer may click on the marketing banner for Get UTO to be linked to the web page displaying the Get UTO screen (shown in Fig. 61). There, the customer may select to purchase UTO on any flight in his/her Itinerary by clicking the "Get UTO" link in front of that flight (shown in Fig. 61).
  • the Get UTO algorithm (details are presented later) running "behind the scenes" on a server of the airline qualifies the availability, applicability and price conditions on all kinds of UTOs available on the selected flight and display the available UTOs along with the price and other conditions in the screen, as shown in Fig. 62.
  • Fig. 62 three UTOs are displayed. For each UTO, an instant price and an exercise price, which the customer would have to pay if upgraded, are also displayed. The customer may select any UTO by selecting the corresponding radio button and then clicking the 'Save and Go to Summary' button, which would hyperlink the user to a summary page.
  • Sequential Get UTO Process There are several ways to implement the Sequential process. The following presents an example of the Sequential Get UTO Process when a UTO is implemented at the Segment level. It is also assumed here that the customer first purchases an Initial Flight Itinerary with one or more IFS, and then opts to receive a UTO on any of the included IFS.
  • a customer selects an Itinerary (with one or more Flight Legs). It is assumed here that the customer interacts with the airline to Get UTO during the ticket purchase process. However, the Get UTO process may take place at any time including before, during, after the ticket purchase process, or any combination thereof.
  • the customer may need to also select the Base-Cabin and/or flight leg on which he or she wants to get the UTO.
  • the customer reaches an interactive interface of airline's web server to Get UTO, where the customer selects a Flight Leg (referred to as Target_Leg) on which UTO is desired (web illustration shown in Fig. 61).
  • the customer inputs the UTO search criteria (such as desired price range, conditions, Up Cabins and so forth) for the current Target_Leg in Act 63.115.
  • the UTO search algorithm returns a list of valid UTOs along with the associated UTO Price and/or other conditions. The details of the UTO search algorithm are presented later.
  • the search results are displayed for the customer, who then selects the desired UTO (and the associated price and other conditions) in Act 63.130.
  • Act 63.140 a test is performed to determine whether the customer wants to purchase more UTOs on the current Target_Leg or on another Flight Leg in the Itinerary. If the customer wants to purchase UTOs on another Leg, control loops back to the Act 63.110, where the customer selects the desired Target_Leg from the Itinerary, and then the process is repeated again for a new Target Leg. If the customer wants to Get more UTOs on the current Target_Leg, control loops back to Act 63.115, where the customer enters the UTO search criteria and then the process is repeated for the new UTO search criteria.
  • the UTO Search algorithm as shown in Fig. 64 expands the Act 120 of Fig. 63.
  • the UTO Search algorithm for searching UTO at the Leg level has been described. Said algorithm has already been discussed above in a more generic sense along with one of the ways of its implementation along with various information technology and networking tools including, but not limited to, one or more servers, database, load balancers, firewall, routers, Internet, highly secured VPN, Intranet, RAM, hard disk drives, CPUs, monitors as shown by Fig. 13D.
  • UTO Search algorithm for the Segment level has been discussed above in UFO under OFS Search Algorithm.
  • a set of parameters including the number of customers (IC), the Target_Leg and the UTO Search parameters are input to the system.
  • the number of customers refers to those customers for whom this process is being executed.
  • the UTO search parameters include, but are not limited to, Up Cabin, fare class of the Up Cabin, class of service, UTO Price and so forth.
  • control goes to Act 64.1 10, where a list of UTO Types (or upgrade options) for the given Target_Leg is read from the airline's database. All the upgrade options, thus obtained, are added to a list termed LIST Option.
  • a list of UTO validation rules is obtained from the airline's UTO VOF database and applied to validate all the upgrade options in the LIST_Option list. The ones that do not satisfy the rules are discarded.
  • Validation rules may include, but are not limited to, a Maximum Ticket Price Rule, an Availability Rule, a Fare Class Rule, a Day to Departure (DTD) rule and so forth.
  • a Maximum Ticket Price Rule may discard those upgrade options for which the ticket price of the Up cabin related to the upgrade option is more than a specified value.
  • a Day to Departure rule may discard the upgrade options which may not be available until X days to departure of a flight Leg.
  • An airline may implement any of the validation rules to further qualify the options in the LIST_Optton list.
  • the first element in the updated LIST Option list is set as the Current Option.
  • control goes to Act 64.130, where a group of Comb_NDs is computed for the combination of the Target_Leg, all the existing options of the Target Leg and the Current_Option, and added to a set called Comb_ND_Set.
  • Act 64.135 a test is performed to determine whether the Comb_ND_Set obtained in the previous Act is Null. If so, control goes to Act 64.155. If not, control goes to Act 64.140, where the UTO availability and UTO Price for the Comb ND Set are determined.
  • Act 64.150 another test is performed to determine whether the UTO Availability or the UTO Price is Null. If so, control goes to Act 64.155. If not, control goes to Act 64.160.
  • Act 64.155 the Current_Option is discarded from the LIST_Option list, and control goes to Act 64.160, where a test is performed to determine if more elements are left in the LIST_Option list. If so, control goes to Act 64.165. If not, control goes to Act 64.170.
  • An airline may set one or more Notify Deadlines of its choosing for its cabins. It may be noted, however, that a UTO VOF may be run with determining the Notify Deadlines at the Leg level only.
  • the next Act is to create a framework to compute the Notify Deadlines for a group of cabins (such as for Segment, an Itinerary or any other group).
  • the following sections present an example of a framework that may be used to obtain a set of Notify Deadlines applicable to a group of cabins.
  • An airline may use any framework and algorithm of its choosing to obtain the same.
  • a set of Notify Deadlines associated with a cabin for a flight, cabins for a Segment and a combination of two or more Segments is called Leg_ND_Set, Segmentt_ND_Set and Comb_ND_Set, respectively.
  • Each element in the Leg ND Set, Segment_ND_Set and Comb ND Set is termed Leg ND, Seg ND and Comb ND, respectively.
  • the Comb_ND_Set may be computed by combining the Seg ND Sets ofall the given Segments.
  • a Seg_ND_Set may be computed by combining the Leg_ND_Sets of all the cabins under that Segment.
  • the Notify Deadlines may be computed based on various parameters including, but not limited to factors of airline's choosing.
  • One example to compute a Comb_ND_Set is as follows. First compute Seg_ND_Set for all Segments. A Seg_ND_Set is computed by first selecting earliest of the Notify Deadlines of each cabins within the concerned Segment, and then picking the latest of those Deadlines, and noting that as the Target_Deadline. Next step is to pick all those Notify Deadlines that fall after the Target_Deadline. Notify Deadlines thus obtained may be validated using various validation rules based on airline factors such as customer utility, cabin (flight) parameters and so forth. Similarly, the Comb_ND_Set may thus be computed by repeating the above process for Seg_ND_Sets, thus obtained for each Segment.
  • the UTO capacity for an OFS may depend on one or more factors including, but not limited to, Notify Deadline, UTO Prices, expected seat value and so forth.
  • An airline may use any method of its choosing to determine UTO capacity of a cabin. For example, an airline may choose to have a fixed UTO capacity for one or more of its cabins.
  • UTO Capacity is dependent on Notify Deadline.
  • the objective is to determine those Comb_NDs within the Comb_ND_Set on which UTO is available for the given OFS.
  • the UTO Capacity and the Used UTO Capacity (the total number of seats in the cabin on which UTO has been sold but not exercised) may be calculated for each Comb_ND within the Comb ND Set.
  • Available Capacity (AC) would then be the difference of UTO Capacity and Used UTO Capacity for the given cabin. If the AC is greater than or equal to the number of incoming customers desiring a UTO, then the UTO capacity is available at a given Comb_ND for the given OFS.
  • UTO may be made available on a given OFS for a given Comb ND at the individual Leg level, even if UTO is not available on all the cabins (Legs) of OFS for the given Comb_ND.
  • An airline may set UTO Prices for a cabin using any method of its choosing. Once the UTO Prices have been set for each cabin, the next Act may be to create a framework to compute UTO Price for a group of cabins (such as a Segment, an Itinerary or any other group) by using UTO Prices for each cabin in the group. The airline may determine UTO Price for a group of cabins in the case when the airline may want to implement the UTO at Segment or higher level.
  • the parameter Leg_OP refer to UTO Price (and may or may not be corresponding to a Notify Deadline) associated with a cabin (Flight Leg).
  • Seg_OP and Comb_OP refer to UTO Price (may or may not be corresponding to a Notify Deadline) associated with a Segment and a combination of two or more Segments, respectively.
  • a set of Leg OPs, Seg OPs and Comb OPs is termed Leg_OP_Set, Seg_OP_Set and Comb_OP_Set, respectively.
  • the Comb_OP_Set is computed by combining the Seg OP Sets of the IFS and all the OFSs (existing and new).
  • a Seg_OP_Set is computed by combining the Leg_OP_Sets of all the Legs under that Segment.
  • One or more Seg_OP_Rules may be read from the airline's database and applied to calculate Seg_OP_Set for each input Set (IFS and all OFSs) using the Leg_OP_Sets of all the cabins (Legs) of said Set.
  • An airline may use any Seg_OP_Set Rule of its choosing.
  • Seg_OP_Rules may be defined to calculate Seg_OP as the sum, average, highest, lowest or any other function of Leg_OPs of all the cabins at a given Comb_ND.
  • Comb_OP_Set consists of one or more Comb_OPs, and is calculated using one of the pre-determined rules, termed Comb_OP_Rules, to combine the Seg OPs of all the Segments in the combination.
  • An airline may use a Comb_OP_Rule of its choosing.
  • Comb_OP_Rules may be defined similar to the Seg_OP_Rules.
  • a customer receives all UTO Cabins concurrently in one transaction.
  • An algorithmic illustration of the Concurrent Get UTO process is displayed in Fig. 65.
  • the UTO (2, 1) instance is assumed here as an example.
  • the customer desires for UTO are input, including, but not limited to, search criteria for two cabins according to customer's utility (may be similar to the search criteria defined above for the Sequential Get UTO process).
  • the UTO algorithm is run to determine the combinations of two cabins that satisfy inputs.
  • a list of such search results is displayed for the customer along with the associated terms and conditions including, but not limited to, Notify Deadlines, Initial UTO Price, UTO Exercise Price and Ticket Price for each such combination.
  • the UTO algorithm for the Sequential Get UTO process (defined above) may also be used for the Concurrent Get UTO process.
  • Act 65.120 the customer selects a desired combination of two cabins and the associated conditions such as UTO Exercise V ⁇ cdNotify Deadline.
  • Act 65.130 a payment transaction is executed, if needed.
  • the customer may pay the Ticket Price after taking into consideration the Initial UTO Price using a credit card, direct bank account debit or any other payment transaction mechanism.
  • the algorithm ends in Box 65.200.
  • the computation may be performed using a processor that may calculate results in optimal time.
  • the processing goes to the Event Optimizer phase where different acts are executed depending on the trigger event that may occur to make an option to become exercisable.
  • the UTO Exercise Process and Customer Notification (or CN, in short) process
  • Act 59.200 is executed.
  • one or more decisions on the selection of Chosen Cabin(s) is notified to the customer.
  • the event(s) is (are) related to the value option selected in the first act.
  • the airline may use a software application built on the method defined above to optimally award the upgrades to customers who have bought a UTO.
  • Event Optimizer stage with the help of information technology tools has already been discussed above in a more generic fashion wherein said tools include, but are not limited to, one or more servers, database, load balancers, firewall, routers, Internet, highly secured VPN, Intranet, RAM, hard disk drives, CPUs, monitors as shown by Fig. 13E.
  • One of the methods have been described above in the UFO VOF (Buy_N and Upgrade_U algorithm). Another method is described below in detail for the UTO Exercise process.
  • the airline may use UTO Exercise Process as one of the method to create a system and computer-implemented process to optimally award the available seats as upgrades.
  • This method helps to find an optimal upgrade solution to create a win-win situation between the customers and the airline.
  • the method may have two or more Acts.
  • the UTO Exercise Process has two Acts, the Upgrade List and the Upgrade Award.
  • the Upgrade List process may use a set of rules to generate a list of upgrade enabled customers.
  • the Upgrade Award process may award upgrades to one or more upgrade enabled customers based on the defined conditions. It may be noted, however, that technically, the UTO Exercise process may be performed using any rule/method as desired. The following process may help to optimize (increase) the benefits generated.
  • the airline could help to use all the unused seats that become available at the last minute because of a no-show or a last minute cancellation.
  • the airline may help to sell UTO upgrades for a portion of the flight duration.
  • a customer could get upgrade for a portion of a flight duration, thus, allowing multiple customer upgrades using the same seat. For example, one customer could be upgraded to a seat for the first half of the flight duration, and another customer could be upgraded to the same seat for the second half of the flight duration. By doing so, the airline could also charge a lower price for a UTO, thus, attracting more customers.
  • An airline may choose to implement the partial flight UTOs on some or all flights. The flights with longer duration may be more suitable for such (partial flight) UTO implementation.
  • the computation may be performed using a processor that may calculate results in optimal time
  • UTO Type is simply the UTO bought by the customer.
  • UTO Type is simply the UTO bought by the customer.
  • UTO Type is simply the UTO bought by the customer.
  • UTO Type is simply the UTO bought by the customer.
  • UTO Type is simply the UTO bought by the customer.
  • UTO Type is simply the UTO bought by the customer.
  • UTO Type is simply the UTO bought by the customer.
  • UTO Types To determine the UTO Type, one needs to determine all the Up Cabins to which a customer may be awarded an upgrade.
  • the list of such Up Cabins need to be compared with the list of Up Cabins associated with all UTOs.
  • the UTO whose Up Cabins match is the UTO Type for said customer.
  • CBF is the UTO Type for said customer.
  • the UTO Types for other customers may be determined in a similar fashion.
  • the airline may define UTO Type for standby customers.
  • the following describes one of the methods to treat standby customers just like confirmed customers to maintain the uniformity in processing the UTO Exercise algorithm.
  • a standby customer here, may be defined as a customer who currently does not have a confirmed flight, but is waiting to get confirmation for seat on that flight, whereas the confirmed customers have confirmed seats in said flight.
  • a new dummy cabin, Standby (or S, in short) may be assumed in the flight and all the standby customers may be treated to exist in the confirmed dummy cabin (S), which may then be added to the list of cabins for a flight..
  • a flight with C, B and F cabins would have a new list of cabins in descending priority, F>B>C>S.
  • a customer may be on a standby list for one or more cabins for a flight.
  • the customers in the S cabin may be assigned the UTO Types, as follows; SC refers to the UTO Type for a standby for coach (C) only, SB refers to the UTO Type for a standby for business (B) only, SF refers to the UTO Type for a standby for first (F) only, SBF refers to the UTO Type for a standby for business (B) and first (F), SCF refers to the UTO Type for a standby for coach (C) and first (F), SCB refers to the UTO Type for a standby for coach (C) and business (B) and SCBF refers to the UTO Type for a standby for coach (C), business (B) and first (F).
  • an airline wants to employ the above mechanism to create a dummy cabin for standby customers, it may be beneficial to include the virtual standby cabin in the list of cabins when calculating all types of upgrade options.
  • Upgrade Value may be defined as the total value an airline may realize by upgrading a customer from a given Base-Cabin to a given Up Cabin. Upgrade Value may be expressed, as follows,
  • the term 'payment' refers to the price paid by the customer to the airline when he/she is awarded an upgrade from the Base-Cabin to the Up Cabin.
  • 'Soft Value' refers to a combination of any indirect and/or intangible value an airline may generate when a customer is awarded an upgrade from the Base-Cabin to the Up Cabin.
  • 'Upgrade Cost' refers to the marginal upgrade cost (if any) to an airline to upgrade the customer from Base-Cabin to an Up Cabin.
  • Soft value may be based on various factors and parameters including, but not limited to, airline's past experiences with the customer, the number of times said customer has or has not received an upgrade in last 'n' number of attempts, customers who require special attention or care, customers belonging to a certain category, other privileged customers for one or more reasons and so forth.
  • an airline may use the final exercise price as the "payment" portion of the upgrade value.
  • the soft value for the UTO customers may be calculated using a function of the long term value of the customer to the airline, trip parameters and upgrade path and so forth.
  • An airline may use any mechanism or methodology to calculate the upgrade value of the UTO customer.
  • the upgrade value may be calculated for the customers in the 'regular' (non-option) upgrade programs and the standby customers.
  • the 'payment' portion of the upgrade value may be zero, however, their 'soft value' may be high.
  • the payment portion may be calculated as follows,
  • the Ticket Price refers to the total Ticket Price the standby customer is expected to pay to the airline if he/she is awarded the seat in the desired cabin.
  • the term "Recapture Probability” refers to a probability that a standby customer may be assigned another seat in another flight of the same (or different) airline so that the airline, in concern, does not lose the potential revenue from the standby customer if the customer is not awarded a seat in the concerned flight.
  • An airline may calculate recapture probability by any method of its choosing.
  • An airline may choose to use any other mechanism to determine the upgrade value for one or more customers in the input list.
  • the computerized system may also allow manual overrides by the airline user (e.g., an analyst or an agent) to allow the user to allocate special upgrade values to satisfy the customer relations objectives (for e.g. enhance chances for some elite customers to get upgrades over other customers) or for any other reasons, that includes enhancing or reducing the soft values of customers to modify their chances to get upgrades, however, while maintaining the conditions of the options contract executed with the UTO customers.
  • the airline user e.g., an analyst or an agent
  • special upgrade values to satisfy the customer relations objectives for e.g. enhance chances for some elite customers to get upgrades over other customers
  • the customer relations objectives for e.g. enhance chances for some elite customers to get upgrades over other customers
  • any other reasons that includes enhancing or reducing the soft values of customers to modify their chances to get upgrades, however, while maintaining the conditions of the options contract executed with the UTO customers.
  • An upgrade combination consists of one or more members sorted in an order, and needs only one available seat for its topmost member to generate an upgrade for all its members.
  • the topmost member has the highest Up Cabin associated among all the members in the combination.
  • the award of upgrades for an upgrade combination works in a cascading style, where a new available seat allotted to the combination is awarded to its topmost member, the seat vacated by the topmost member (after his/her upgrade) is awarded to the second (next) topmost member and the chain goes on until the seat vacated by the second lowest member is awarded to the lowest member.
  • C-CB-BF where, C refers to a standby customer for the coach (C) cabin, CB refers to a coach customer enabled to be upgraded to business (B) and BF refers to a business customer enabled to be upgraded to first (F).
  • BF is the topmost member with the highest associated Up Cabin, F.
  • the BF customer may be upgraded to first, leaving one empty seat in business, the CB customer may be upgraded to the seat emptied in business by the upgraded BF customer, and the C (standby) customer may be awarded the seat emptied by the upgraded customer CB.
  • B-BF B refers to a standby customer for the business (B) cabin and BF refers to a business customer enabled to be upgraded to first (F).
  • B refers to a standby customer for the business (B) cabin
  • BF refers to a business customer enabled to be upgraded to first (F).
  • C-CBF where, C refers to a standby customer for the coach (C) cabin and CBF refers to a coach customer enabled to be upgraded to either business (B) or first (F).
  • C refers to a standby customer for the coach (C) cabin
  • CBF refers to a coach customer enabled to be upgraded to either business (B) or first (F).
  • C refers to a standby customer for the coach (C) cabin
  • CBF refers to a coach customer enabled to be upgraded to either business (B) or first (F).
  • CBF customer may be upgraded to business, leaving one empty seat in business
  • the C(Standby) customer may be awarded the coach seat emptied by the upgraded customer CBF.
  • the CBF customer may be upgraded to first, leaving one empty seat in coach, and the C (standby) customer may be awarded the coach seat emptied by the upgraded customer CBF.
  • the Upgrade List Algorithm as shown in Fig. 67 has been explained in the UPO VOF at length. In the context of the airline industry, it is explained using an example below.
  • DC-CB-CBA Assume the input list of customers contains 2 customers, DCl and DC2, with the UTO Type DC. Similarly, assume there are 2 customers, CBl and CB2, with the UTO Type CB and 2 customers, CBAl and CBA2, with the UTO Type CBA in the given list of customers.
  • DCl (belonging to DC) is combined with CBl (belonging to CB) and CBAl (belonging to CBA) to form one upgrade combination, DCl-CBl-CBAl.
  • DCl is combined with CBl and CB A2 to form another upgrade combination, DC1-CB1-CBA2.
  • all such upgrade combinations are created, as follows: DCl-CBl-CBAl, DCl- CB1-CBA2, DC1-CB2-CBA1, DC1-CB2-CBA2, DC2-CB1-CBA1, DC2-CB1-CBA2, DC2-CB2-CBA1 and DC2-CB2-CBA2.
  • all the upgrade combinations are created for all the Up Cabins using all the input customers and all the types of upgrade combinations.
  • the BASE is set to C, and then control enters the inner loop.
  • a test is performed to determine whether the current BASE (i.e., C) is same as the current UP (i.e., C). It is same, so control branches to Act 68.150, where the current L(C):[ ] is returned, and control goes to Act 68.160, where the test is performed to determine whether the current UP (i.e., C) is the highest priority cabin within SP. It is not, so the process continues to Act 68.170, where B, the cabin one level higher than C, in terms of priority, is assigned as the new UP. At this point, the process loops back to Act 68.120, where L(B) is initialized as an empty set.
  • BASE is again set to C, per Act 68.130, and the test is performed to determine whether C (the current BASE) is same as B (the current UP), per Act 68.140. They are not the same, so, the process continues to Act 68.142, where L(C): [ ] is assigned to the collection Cl.
  • L(A) is initialized as an empty set.
  • Base is set to C again, per Act 68.130.
  • the test is performed again to determine whether the current Base (i.e., C) is same as the current UP (i.e., A), per Act 68.140. They are not, so, the process continues within the inner loop and L(C):[ ] is assigned to Cl , per Act 68.142.
  • each member of Cl [CB, CBA] is combined with each member of C2 [BA], and all these combinations [CB-BA, CBA-BA] are added to the L(A) to form L(A):[CA, CBA, BA, CB-BA, CBA-BA].
  • the BASE is set to A, one level higher than B.
  • the process loops back again to Act 68.140, where the test finds that the current BASE and the current UP are same (A). Therefore, the L(A) is returned, per Act 68.150, and the process control moves to Act 68.160, where the test is performed to determine whether A is the highest cabin. It is, so, control moves to Act 68.200, where the algorithm ends.
  • An airline may create a data structure (or a computer-readable medium) that may include an ability to store therein an indication of each customer of an airline who maybe eligible to receive an upgrade award and, for each said customer, an indication of each award for which the customer is eligible and one or more values associated with the award.
  • Such said values may include, without limitation, a total upgrade value, a payment value, a soft value and an upgrade cost related to said upgrade; a Base-Cabin value, and an Up Cabin value; and one or more values specifying traits or characteristics of the customer and so forth.
  • Fig. 69 presents an illustrative Upgrade Award process.
  • the algorithm of Upgrade Award has been explained in the UPO VOF above.
  • An airline may use any Upgrade Award rule of its choosing including, but not limited to, to maximize the total upgrade value (monetary or soft value or a combination of both), the number of upgrades or the number of customers in the flight, to balance load across multiple flights, to optimize customer service for all or a selected group of customers, to optimize flight operations and to accomplish any other objectives or combination thereof.
  • the Upgrade Award rule When the Upgrade Award rule is set to maximize the total upgrade value, the upgrade value of each combination member preferably is added together to get the total upgrade value of the entire upgrade combination. Then, all the upgrade combinations from all the upgrade lists (one for each Up Cabin) are combined together to form one list sorted by descending value, and the topmost upgrade combination is selected as the target to be considered first for an upgrade award.
  • the Upgrade Award rule When the Upgrade Award rule is set to maximize the number of customers in the flight, the number of upgrade awards given to standby customers has to be optimized. Hence, an upgrade combination that includes a standby customer should be given preference over the one that does not include it.
  • the Upgrade Award algorithm will allocate seats to the two standby customers since this would increase the customer count in the flight by two as compared to a no increase in the total customer count if the two CFs are upgraded (assuming no SC standby customers are available).
  • the Upgrade Award rule is set to maximize the total number of upgrades, the algorithm would choose those customers (out of 2 standby and 2 CF) that belong to the upgrade combinations with more number of members.
  • An airline may also choose to select the target upgrade combination randomly: to add all the upgrade combinations from all the upgrade lists of a flight to one list and then to randomly select an upgrade combination as the target combination.
  • An upgrade award may be given at any time before the flight arrives at its final destination or before the flight departure. It may also be given at a pre-determined time.
  • an airline may need to iterate over possible solutions.
  • the process to choose the target upgrade combination may involve one or more sub-acts (one or more of which may be iterative) that enable the airline to accomplish the overall objective.
  • the airline may use the Upgrade Award rules mentioned above to optimize the desired objective(s) within one flight or across multiple flights. For example, a CF UTO customer in flight Fl, may be offered an upgrade to the first cabin in flight F2, when doing so would optimize the total upgrade revenue generated or distribute the load more uniformly across the two flights (e.g., the flight Fl may not have a seat available in the first cabin).
  • the airline may use next level (one or more levels as needed) of Upgrade Award rule(s) to further prioritize the upgrade combinations.
  • the next level of upgrade combination could include one or more of the rules defined above.
  • Both the airline and the customer may have the right to enforce the upgrade award on each other as per the terms and conditions of the option contract.
  • the airline may have the right to charge the customer for the upgrade amount if the customer is upgraded.
  • the airline may inform/notify the customer and/or take approval from customer to charge the customer's account before awarding upgrade.
  • the customer may also have the right to enforce upgrade on the airline within the bounds of the terms and conditions of the options contract.

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Finance (AREA)
  • Marketing (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Cash Registers Or Receiving Machines (AREA)

Abstract

La présente invention concerne un système et un procédé mis en œuvre sur un ordinateur pour qu'une compagnie aérienne améliore l'expérience des clients. Un service mis en œuvre sur un ordinateur est utilisé pour fournir à un client une possibilité de mettre à niveau jusqu'à n produits sélectionnés parmi m, où n est inférieur à m. Des informations se rapportant à ladite possibilité sont enregistrées dans un magasin de données. De plus, un système est utilisé pour définir chacun des n produits choisis, de manière qu'une fois défini chacun des n produits choisis, le client peut mettre à niveau avec ledit produit choisi. Les informations se rapportant auxdits produits définis sont enregistrées dans un magasin de données.
PCT/IB2007/002547 2006-06-23 2007-06-23 Système destiné à l'optimisation simultanée de l'économie d'une entreprise et de la valeur d'un client WO2008020307A2 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
AU2007285460A AU2007285460A1 (en) 2006-06-23 2007-06-23 System for concurrent optimization of business economics and customer value
ZA2010/00530A ZA201000530B (en) 2006-06-23 2010-01-22 System for concurrent optimization of business economics and customer value

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US11/474,115 US7472080B2 (en) 2003-10-24 2006-06-23 Methods and associated systems for an airline to enhance customer experience and provide options on flights
US11/474,115 2006-06-23
US11/506,451 US7424449B2 (en) 2003-10-24 2006-08-18 Computer-implemented method to provide options on products to enhance customer experience
US11/506,451 2006-08-18

Publications (2)

Publication Number Publication Date
WO2008020307A2 true WO2008020307A2 (fr) 2008-02-21
WO2008020307A3 WO2008020307A3 (fr) 2016-06-09

Family

ID=42139095

Family Applications (2)

Application Number Title Priority Date Filing Date
PCT/IB2007/002547 WO2008020307A2 (fr) 2006-06-23 2007-06-23 Système destiné à l'optimisation simultanée de l'économie d'une entreprise et de la valeur d'un client
PCT/IB2007/003761 WO2008068594A2 (fr) 2006-06-23 2007-06-23 Système d'optimisation simultanée d'économie d'entreprise et de valeur client

Family Applications After (1)

Application Number Title Priority Date Filing Date
PCT/IB2007/003761 WO2008068594A2 (fr) 2006-06-23 2007-06-23 Système d'optimisation simultanée d'économie d'entreprise et de valeur client

Country Status (4)

Country Link
AU (2) AU2007285460A1 (fr)
SG (1) SG160429A1 (fr)
WO (2) WO2008020307A2 (fr)
ZA (2) ZA201000529B (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2549429A1 (fr) 2011-07-22 2013-01-23 Amadeus S.A.S. Système et procédé pour améliorer le calcul de disponibilité dynamique

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2008021510A2 (fr) * 2006-08-18 2008-02-21 Sachin Goel Système d'optimisation simultanée de l'économie d'entreprise et d'une valeur client

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5237499A (en) * 1991-11-12 1993-08-17 Garback Brent J Computer travel planning system
US5897620A (en) * 1997-07-08 1999-04-27 Priceline.Com Inc. Method and apparatus for the sale of airline-specified flight tickets
US7181410B1 (en) * 1998-08-27 2007-02-20 Travelocity.Com Lp Goal oriented travel planning system
US6850901B1 (en) * 1999-12-17 2005-02-01 World Theatre, Inc. System and method permitting customers to order products from multiple participating merchants
US7599847B2 (en) * 2000-06-09 2009-10-06 Airport America Automated internet based interactive travel planning and management system
US8868448B2 (en) * 2000-10-26 2014-10-21 Liveperson, Inc. Systems and methods to facilitate selling of products and services
EP1433109A2 (fr) * 2001-10-01 2004-06-30 The Boeing Company Systeme de gestion d'itineraires
AU2003258129A1 (en) * 2002-08-06 2004-02-23 Sabre, Inc. System for integrated merchadising and shopping environment
US20050288973A1 (en) * 2004-06-24 2005-12-29 Taylor Steven F System and method for changing a travel itinerary

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2549429A1 (fr) 2011-07-22 2013-01-23 Amadeus S.A.S. Système et procédé pour améliorer le calcul de disponibilité dynamique

Also Published As

Publication number Publication date
ZA201000529B (en) 2010-10-27
SG160429A1 (en) 2010-04-29
ZA201000531B (en) 2010-10-27
AU2007285460A1 (en) 2008-02-21
WO2008068594A2 (fr) 2008-06-12
WO2008020307A3 (fr) 2016-06-09
AU2007330457B2 (en) 2012-08-09
AU2007330457A1 (en) 2008-06-12
WO2008068594A3 (fr) 2009-08-27

Similar Documents

Publication Publication Date Title
US8145536B1 (en) System for concurrent optimization of business economics and customer value
US8165920B2 (en) System for concurrent optimization of business economics and customer value
US7472080B2 (en) Methods and associated systems for an airline to enhance customer experience and provide options on flights
US8145535B2 (en) Computer implemented methods for providing options on products
US7983956B1 (en) System and method for providing options on products including flights
US8140399B1 (en) System for concurrent optimization of business economics and customer value
US7418409B1 (en) System for concurrent optimization of business economics and customer value satisfaction
US20130103438A1 (en) System and method for facilitating the purchase of a travel itinerary subject to destination uncertainty
US20170004590A1 (en) Inventory management system
US20120010910A1 (en) Systems and methods for optimizing the scheduling of resources on an airplane
Wang et al. An option-based hedging mechanism for managing the risk of overbooking in parallel airline alliances
WO2008020307A2 (fr) Système destiné à l'optimisation simultanée de l'économie d'une entreprise et de la valeur d'un client
US20050144030A1 (en) System and method for territory based commission attribution
Vinod The expanding role of revenue management in the airline industry
AU2007284408B2 (en) System for concurrent optimization of business economics and customer value
AU2013260660A1 (en) System for Concurrent Optimization of Business Economics and Customer Value
Luke Determinants of passenger choice in the domestic airline industry in South Africa
AU2013263869A1 (en) System for Concurrent Optimization of Business Economics and Customer Value
Turkmen Revenue management in airline operations: booking systems and aircraft maintenance services

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 07804878

Country of ref document: EP

Kind code of ref document: A2

NENP Non-entry into the national phase in:

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 408/DELNP/2009

Country of ref document: IN

NENP Non-entry into the national phase in:

Ref country code: RU

122 Ep: pct application non-entry in european phase

Ref document number: 07804878

Country of ref document: EP

Kind code of ref document: A2

WWE Wipo information: entry into national phase

Ref document number: 2007285460

Country of ref document: AU

ENP Entry into the national phase in:

Ref document number: 2007285460

Country of ref document: AU

Date of ref document: 20070623

Kind code of ref document: A