CA2339065A1 - Software tool for management of timeshare properties - Google Patents

Abstract

A software method and tool for use in developing, selling, operating and managing timeshare properties. In the marketing and sales stage of managing timeshare properties, timeshare products are created by defining usage type (150) for each product and defining usage rights (155) associated with the usage type (150). The usage type can have a space dimension component, and/or a points based component. A hotel inventory (115) is developed based on resort, room type, and room information.

Description

WO 00/b3794 PCT/US00l10492 SOFTWARE TOOL FOR MANAGEMENT OF TIMESHARE PROPERTIES
This patent application claims priority from ILJ.S. Provisional Patent Application Serial Number 60!130,076 for SOFTWARE TOOL FOR
TIMESHARE PROPERTY MANAGEMENT which is hereby incorporated by reference.
FIELD OF THE INVENTION
The present invention relates to a software tool for use in managing timeshare properties, and more particularly to a property management tool that includes defining usage types, usage rights, products, product inventory, sales inventory, and resolved usage rights.
BACKGROUND OF THE INVENTION
Timesharing generally refers to the proportional use of a piece of property by a plurality of owners. The evolution of the timeshare industry appears to have begun with small groups of perhaps three or four people that would collectively purchase a condominium and proportionally share usage of the condominium. Later on, investors began purchasing condominium or other properties and partitioning the use of the conda into 52 one week segments. The partitioned use of the condo was offered for sale to people interested in regularly using a particular condo for a. particular week each year. For example, a person could purchase a timeshare interest in the third week of each year at a particular condo in Aspen, Colorado. In timeshare parlance this is referred to as a fixed/fixed usage type, i.e., the time aspect, the third week, is fixed and the space aspect, the particular condo in Aspen, is fixed. Timeshare inventory management at this stage in the development of the timeshare industry was relatively simple to perform. Oftentimes, timeshare inventory management was performed with a chalkboard having a

2 , grid with the 52 weeks of the year on one axis and the inventory, i.e., timeshare condos, on the other axis. The intersection of a particular week and a particular unit is a fixed/fixed product. The timeshare owner was simply written into the appropriate box on the grid.
The early timeshare models, however, did n.ot provide enough flexibility for timeshare developers. Oftentimes a perspective timeshare purchaser was more likely to make a purchase if it involved more flexible usage of a particular timeshare property, the ability to use alternative timeshare properties in the same resort, or perhaps the ability to use alternative timeshare properties owned by a particular timeshare manager but in different locations. For example, the concept of floating or flexible usage developed wherein a person purchased a timeshare interest in a particular type of unit, e.g., two bedrooms, at a particular resort, E>.g., Aspen, for a particular season, e.g., ski season. In this example, the usage type the person purchased, a two bedroom unit in Aspen each year during ski season, is referred to as a "floating" usage type. The purchaser/owner would have to call the resort and make a reservation for their timeshare which was based on availability. The person was not guaranteed a particular week or a particular unit. Under the floating model, a person could potentially lose out on their timeshare right for a given year if they waited too late into their season to make a reservation and there were no longer units available. Inventory management under the floating model is much more complicated than for fixed products.
After the floating and fixed usage types, permutations of the two developed and new usage types such as "points" emerged. A "product" as discussed in more detail below, is a function of the; usage type and defines what a times share developer has to sell. The various different models discussed herein are collectively referred hereinafter as "usage types."
Accordingly, a timeshare product is a function of the usage type. Current timeshare management software does not allow user-defined usage types and hence does not provide the timeshare developer with flexibility in defining and selling new products. Rather, the timeshare developer must conform their

3 range of products to the available usage types. This lack of flexibility in creating products significantly limits the ability of timeshare developers to sell their products. Accordingly, an object of the present invention is to allow user-defined usage types to provide timeshare developers with the utmost business flexibility. Moreover, another object of the present invention is to allow timeshare inventory management to take into account the custom products developed by the timeshare developer.
A further object of the present invention is to handle inventory management for mufti-site timeshares, vacation clubs and complicated organizational structures. Mufti-site timeshares and vacation clubs are similar in that they both give participants access to more than one property. For example, a vacation club allows a club participant to use various properties with the club. Oftentimes the club properties are i.n different locations such as Florida and Las Vegas. Accordingly, the timeshare owner can go to the club's IS property in Florida or Las Vegas. To facilitate the vacation club concept and the mutli-site timeshare concept, a product has been created referred to as "points." Each piece of inventory that is sold, such as a unit in Florida, is assigned a points value. Numerous factors are involved in assigning a points value to piece of inventory, such as season; view, size of unit and location.
The various pieces of inventory in the club may have different points values.
Accordingly, an owner of 15,000 points might be able to use a unit in Florida that has a points value of 7,500 two times or use a unit in Las Vegas that also has a points value of 5000 three times. Numerous permutations of the vacation club have evolved. The most common are "pure points" clubs, "inventory backed points" and hybrids of the two. In a pure points club the owner does not have an interest in a particular piece of property. Rather, an overall points value is assigned to all inventory and points are sold that gives the buyer access to all inventory in the club. In an inventory backed points club the owner has an interest in a certain unit that is assigned a points value that allows the owner to use other properties in the club. Accordingly another

4 PCTIUS00/10492 object of the present invention is to provide inventory management for the various current and yet to be defined points based products.
In the timeshare industry, complicated organizational structures arise when a single timeshare developer obtains financiial support from different sources to develop different properties. Oftentimes, a timeshare developer starts a company to develop and manage a timeshare property and enlists investors for the property development. For the next timeshare property that the developer wishes to develop some or all of the original investors may be uninterested in the second development. Accordingly, a second company is formed to develop and manage the second timeshare property. The timeshare developer than has the task of managing the various properties, marketing the various properties, and directing the revenue from. the various properties which may be organized differently from one anoi:her. Accordingly, a further object of the present invention is to provide inventory management for timeshare owners with complicated organizational'. structures.
Another problem with time share property management relates to determining the rights an owner has when the owner calls in to make a reservation. Current systems rely on a human agent to determine what rights are available to a particular timeshare owner at a particular time. For example, a timeshare owner may not have the right to reserve a particular room at a certain time of the year. If that person calls to reserve a particular room at that time of the year, current systems do not automatically notify the agent of the person's rights.
A further object of the inventory management capabilities of the present invention is to minimize or eliminate the number of room switches a particular timeshare owner would have to endure during a given stay - room switching is highly undesirable for timeshare owners and oftentimes is contractually prohibited.
It is against this background that the software tool for managing timeshare properties of the present invention was developed. A description of the invention follows.

WO 00/63794 PCTIUS00l10492 SUMMARY OF THE INVI~NTION
The present invention relates to a computer based method used in timeshare development and management for defining a timeshare product.
The method includes dei~ining a usage type basedf on the arrangement of a set

5 of usage type variables and defining a usage right associated with the usage type. The usage right is based on the arrangement of a set of usage right variables. The characteristics of the product are a function of the usage type and the associated usage right.
The usage type may include a space dimension component and a time dimension component. The usage type may include a point-based usage type.
The usage type may include a space dimension component, a time dimension component, and a points-based component. The set of usage type variables may include a sales time unit variable, a sales tune unit count variable, a sales increment variable, a sales points variable, a pricing unit allocation variable, a pricing time allocation variable, a contract unit alllocation variable, and a contract time allocation variable.
The space dimension component may include one of a fixed space dimension component and a floating space dimension component. The time dimension component may include one of a fixed time dimension component, a floating time dimension component, and a fractional time dimension component. The usage type may include a whole ownership usage type and a pure points usage type.
The method may further include the operation of defining a time unit.
The time unit may be a function of a day. The time unit may include a baseline factor, the baseline factor defining the time unit as an even multiple of a day. The time unit may include a baseline factor, the baseline factor segmenting the time unit into discrete portions of a day. The operation of defining a usage right rnay include the operations of defining a reservation start date and a reservation end date for each usage right, the reservation start date and end date together defining a reservation window in which a

6 reservation can be made for the product being defined, the reservation start date defining the first day of the reservation window that a reservation can be made and the reservation end date defining the last day of the reservation window that a reservation can be made.
The operation of defining a usage right may include the operations of defining a usage start date and a usage end date for each usage right, the usage start date and the usage end date together defining a usage window in which the product being defined may be used, the usage start date defining the first day of the usage window that the product may be used and the usage end date defining the last day of the usage window that the product may be used.
The operation of defining a usage right further may include the operation of defining an accommodation for each usage right, wherein the accommodation includes unit, unit type and resort. The operation of defining a usage right may include the operation of defining a Boolean operator, wherein the Boolean operator determines the interaction between each usage right defined. The operation of defining a usage right may include the operation of defining a policy associated to the usage right wherein the policies include rental and exchange.
The method may further include adding a membership to the product wherein the membership includes additional usage rights. The method may further include defining a points package for the product, the points package including a points increment representing the number of points that the points package represents.
The present invention also relates to a computer based method used in timeshare development and management for developing and managing timeshare inventory. The method includes defining; a timeshare product, each product having space and time characteristics, and defining a sales inventory.
The sales inventory includes a set of sales inventory entities available for association with the timeshare product, the sales inventory entities defining a plurality of particular spaces. The method also includes linking the timeshare product with the sales inventory to create a product inventory. The product

7 inventory includes a set of product inventory entities available for sale as a timeshare interest, the product inventory entities including particular rights to space and time that can be used by a purchaser of the timeshare interest.
The operation of defining a sales inventory may include the operation of defining a resort, defining a unit type, and defining a unit. The method may further include defining a hotel inventory and mapping the hotel inventory to the sales inventory. The operation of defining a hotel inventory may include the operations of defining a resort, defining a cluster, defining a room type, and defining a room. The operation of linking a product to a sales inventory may include selecting the product, defining a search criteria that describes a particular entity within the set of sales inventory entities, searching the sales inventory according to the search criteria, and displaying any matches between the search criteria and the sales inventory found in the search.
i5 The product may include a non pure points praduct. The operation of linking the product to the sales inventory for the n.on pure points product may include defining a product calendar, defining a maintenance increment, initializing a pricing attribute, initializing a points. attribute, initializing an inventory dates attribute, and initializing a business entities attribute. The product may include a pure points product. The operation of linking the product to the sales inventory for the pure points product may include defining a price for the pure points product and initializing a business entities attribute.
The present invention also relates to a computer based method used in timeshare development and management for developing and managing timeshare inventory. The method includes selling a timeshare interest, the timeshare interest including a usage right defining how the timeshare interest may be used. The method also includes resolving the usage right to generate a resolved usage right wherein the resolved usage right defines how the timeshare interest may be used at a particular time.
The present invention also relates to a computer based method used in timeshare development and management for developing and managing

8 timeshare inventory. The method includes defining a timeshare product including a usage right, defining a sales inventory;, and defining a hotel inventory. The method also includes linking the tiimeshare product to the sales inventory to define a product inventory including a set of product inventory entities available for sale, each of the product inventory entities including the usage right. The method also includes selling a product inventory entity, resolving the usage right to generate a resolved usage right, and allowing a reservation to be made for the product inventory entity based on the resolved usage right.
The operation of selling a product inventory entity may further include selecting a product inventory entity, defining a search criteria for the product inventory entity including a space dimension search criteria and a time dimension search criteria, searching for the product inventory entity matching the search criteria, and selecting a product inventory entity from a set of product inventory entities that match the search criteria. The operation of defining a sales inventory may include defining a resort, defining a unit type and defining a unit. The operation of defining a hotel inventory may include defining a resort, defining a room type, and defining a room. The operation of defining a product may include defining a time unit and defining a usage type using the time unit, wherein the usage right is associated to the usage type.
The present invention also relates to a software system for timeshare development and management. The system includes a usage type definition module including a set of definable usage type variable fields, a usage right definition module including a set of definable usage right variable fields, and a timeshare product definition module including a set of definable timeshare product variable fields. The usage type module, the usage right module, and the timeshare product definition module can be utillized together to define a timeshare product. The system may further include a time unit definition module.
The present invention also relates to a computer program product embodied in a tangible media. The product includes a set of program code to

9 implement a usage type definition module, wherein the usage type definition module includes a set of definable usage type variable gelds. The product also includes a set of program code to implement a usage right definition module, wherein the usage right definition module includes a set of definable usage right variable fields. The product further includes a set of program code to implement a timeshare product definition module, wherein the product definition module includes a set of definable timeshare product variable fields.
The usage type module, the usage right module, and the timeshare product definition module can be utilized together to define a timeshare product.
The tangible media may include a magnetic; disk. The tangible media may include an optical disk. The tangible media may include a propagating signal.
The present invention also relates to a system used in timeshare development and management for developing and managing timeshare inventory. The system includes a timeshare product definition module including a set of time unit definition fields, a set of usage type definition fields, and a set of usage right definition fields, the product definition module operative to create a timeshare product. The system also includes a sales inventory definition module including a set of resort definition fields, a set of unit type definition fields, and a set of unit definition fields. The sales inventory module is operative to create a sales inventory that includes a set of sales inventory entities. The system further includes a product inventory definition module including a product field, a set of sales inventory entity fields, and a linking module. The linking module is operative to link the timeshare product with the sales inventory entity to create a product inventory that includes a set of product inventory entities that are available for sale as a timeshare interest.
The foregoing and other features, utilities and advantages of the invention will be apparent from the following more particular description of a preferred embodiment of the invention as illustrated in the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS
Figure I is a high level block diagram illustrating the exemplary interactions between an exemplary hotel inventory, an exemplary sales inventory, an exemplary set of product configurations, an exemplary product S inventory, and an exemplary hotel inventory control of the present invention;
Figure 2 is a flowchart illustrating high level operations of the present invention;
Figure 3 is a flowchart illustrating high level operations of the product definition operation of the present invention;
I0 Figure 4 is a flowchart illustrating time unit definition operations;
Figure S is a flowchart illustrating resort season calendar definition operations;
Figure 6 is a flowchart illustrating usage type definition operations;
Figure 6a is a table illustrating exemplary usage types and associated 1S attributes utilized in the configuration of the usagE; types;
Figure 6b is a table illustrating exemplary fractional products;
Figure 7 is a flowchart illustrating usage ri~;hts definition operations;
Figure 8 is a flowchart illustrating timeshare product definition operations;
Figure 9 is a flowchart illustrating membership definition operations;
Figure I O is a block diagram illustrating an exemplary representative configuration of hotel inventory;
Figure 1 I is a block diagram illustrating an exemplary representative configuration of sales inventory;
2S Figure 12 is a flowchart illustrating the high level operations of defining hotel inventory and defining sales inventory;
Figure 13 is a flowchart illustrating the fields and operations involved in defining a resort;
Figure 14 is a flowchart illustrating the fields and operations involved in defining a room type;

Figure 15 is a flowchart illustrating the fields and operations involved in defining a room;
Figure 16 is a flowchart illustrating the fields and operations involved in defining a unit type;
Figure I7 is a flowchart illustrating the fields and operations involved in defining a unit;
Figure 18 is a flowchart illustrating product to sales inventory association operations;
Figure 19 is a flowchart illustrating non pure points product to sales inventory association operations;
Figure 20 is a flowchart illustrating pure points product to sales inventory association operations;
Figure 21 is a flowchart illustrating contra<;t inventory selection operations;
Figure 21 a is an exemplary window illustrating the inventory selection fields;
Figure 22 is an exemplary window illustrating the main menu screen of the Tool;
Figure 22a is an exemplary tool bar of the inventory management navigation module;
Figure 22b is an exemplary drop down menu of the inventory management portion of the inventory management navigation module;
Figure 22c is an exemplary window illustrating the hotel inventory window;
Figure 22d is an exemplary window illustrating the sales inventory window;
Figure 22e is an exemplary window illustrating the sales product window;
Figure 22f is an exemplary window illustrating the product drop down menu of the product portion of the inventory management navigation module;

WO 00!63794 PCT/US00/10492 Figure 22g is an exemplary window illustrating the inventory drop down menu of the inventory management navigation module;
Figure 23 is an a flowchart illustrating the 'usage right resolution operations;
Figure 23a is a table illustrating the resolved usage right logical relationships between sales time allocation attributes and contract time allocation attributes;
Figure 24 is a table illustrating sustained availability;
Figure 25 is a flowchart illustrating overbooking operations;
Figures 25a - 25e are tables illustrating overbooking;
Figure 26 is an exemplary window illustrating a set of blocking fields;
Figure 27 is a flowchart illustrating member call processing operations;
Figure 27a is a flowchart illustrating fixed product reservation operations;
Figure 27b and 27c are flowcharts illustrating floating product reservation operations; and Figures 27d and 27e are flowcharts illustrating point product reservation operations.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT
The software tool for managing timeshare properties (hereinafter "Tool") of the present invention is a comprehensive system and method that allows a timeshare developer or manager (hereinafter "user") to create and manage three distinct but interrelated types of inventory - product inventory, sales inventory, and hotel inventory. Figure 1 is an exemplary block diagram illustrating product inventory 105, sales inventory 110, hotel inventory 115, hotel inventory control I20 and their interrelationships. Figure 1 is referred to throughout this document for illustrative and exerrrplary purposes.
Product inventory I05 comprises what may be sold as a timeshare. For example, a particular piece of product inventory, i,.e., a widget 125, may be the right to use a two bedroom unit 130 at the SurAbay Resort135 between January 1 and January 7 of each year. Sales inventory I 10 comprises the logical space that may be sold as a part of the product inventory I05. For example, the two bedroom unit 130 at the Sunbay Resort 135 is a piece of sales inventory. Finally, hotel inventory 11 S comprises the space that may actually be used when a reservation is made. In the examples provided above, a piece of hotel inventory may be Room 101 (140) (a particular two bedroom unit) at the Sunbay Resort 135.
Product Inventory I05 (hereinafter "PI"), sales inventory 110 (hereinafter "SI") and hotel inventory I 15 (hereinafter "HI") are both created and managed by the Tool. The creation of PI 105 involves the definition of products 145. A product 145, as mentioned above., is the set of parameters that define the timeshare rights. A product includes usage types 150 and usage rights i 55. Exemplary usage types 150 include the type of unit that a timeshare owner may use (e.g., two bedroom) and the particular time of the year that the unit may be used (e.g., Jan. 1 - Jan. T}. An exemplary usage right 155 is the time when the owner may make a reservation for the timeshare (e.g., 6 months before Jan. 1). The creation of PI 105 also involves the association of products to SI 160.
The creation of SI 110 involves, essentially, the definition of the details of a particular property into pieces that may then be associated to a product and together sold. For example, the SI far the Sunbay Resort 135 may include two types of units 162, a 3 bedrooW unit type 164 and a two bedroom unit type 166. There may be one three bedroom unit, omit 105 (168); and four two bedroom units, unit 101 (I70), unit 102 (I72), unit 103 {174), and unit 104 (176}. The SI is defined as resort (Sunbay), unit type (three bedroom, two bedroom) and unit (3BR) (105), Unit (2BR) (101, 102, 103,.and 104).
Accordingly, in a simplistic example of the association of a product to SI, if the product is a fixed 2 bedroom at the Sunbay Resort far Jan. 1 to Jan. 7 (hereinafter "week l "), then four two bedroom/week l widgets i 78, i. e. , pieces of product inventory, are created that may each be sold. The timeshare owner would have the right to use one of the two bedroom units during weekl. In a second simplistic example of the association of a product to SI, if the product is Unit 101 at the Sunbay Resort during weekl, then one Unit 101/weekl widget 180 is created that may be sold. The timeshare owner has the right to use Unit 101 at the Sunbay Resort during weekl.
In addition to providing for the creation and management of each one of the above exemplary widget types, the tool provides for the creation and manage of a plurality of widgets at one time. Referring to the example above, if the four two-bedroom/weekl widgets I78 and the unit 101/weekl 180 widget are both created for the Sunbay Resort and the unit 101/weekl widget is purchased, then the PI automatically removes the unit I OI from availability for the two-bedroom/weekl widgets 178. Accordingly, there would only be three two-bedroomlweekl widgets available for sale.
The creation of HI 1 I S involves, essentially, the set-up of the details of a particular property into pieces that may then be used by both timeshare owners and transient guests. Transient guests refers to anyone, other than a timeshare owner, that stays in a room in a hotel, e.g., business travelers.
For example, still referring to the Sunbay Resort 135, the HI l I5 for the Sunbay Resort may be defined as three clusters 182 (three bedroom, two bedroom and studio}, four room types 184 and associated rooms 186 (three bedroom ocean view (105, 106), two bedroom ocean view (101, I03 and IOSA), two bedroom golf view (102, 104, 109), and studio {105B, 108, 110)). Note, the SI is a subset of the HI because only a portion of the Sunbay Resort is meant for sale as timeshares.
The actual ability of a timeshare owner to use their timeshare requires the generation of resolved usage rights 188. Resolved usage rights 188 involves, generally, the reduction from a plurality of usage rights 155 associated with a particular widget into a set of resolved usage rights that define what rights the timeshare owner has at a particular time: Usage rights are defined during the product definition operations. For example, two usage rights for a particular widget may be: "Right 1" the right to make a reservation for Unit I01 at the Sunbay Resort during Weekl, if the reservation is made more than 365 days before Weekl, and "Right 2" the right to make a reservation for a two bedroom unit at the Sunbay Resort during Weekl, if the reservation is made between 365 days before Wee;kl and the first day of 5 Weekl. Accordingly, the resolved usage right at 400 days before Weekl is usage Right l, and the timeshare owner may therefore reserve unit 101 for weekl. Hotel inventory control 120 accounts for this resolution and allocates the appropriate space 190 - unit 101 during week 1 - to the timeshare owner.
The following discussion provides a more detailed description of the

10 Tool. The operations associated with Figures 2 - X, as discussed below, are presented in a particular order for ease of discussion and understanding. The order of the operations associated with the various flowcharts below, however, is not a requirement of the present invention. Moreover, many of the operations discussed in the following, flowcharts include operations that may 15 be executed discretely. The user input and manipulation mechanism for the Tool is preferably implemented using graphical user interfaces (hereinafter "GUI") as provided by the WindowsTM operating system. Any suitable interface including command driven interfaces as ;provided by DOS, and GUIs as provided by the Apples operating system, however, may be utilized. The tool preferably runs on a Windows NT~ server or Unix ~'~''server and utilizes an Oracles database. Preferably, the software code for the Tool is implemented using Power Builder'T'I by SybaseTT'.
Figure 2 is a flowchart illustrating the exemplary hierarchical or main operations involved in the use of the Tool. In main operation 205, the user defines a set of products. A product is the set of parameters that define the timeshare rights that eventually can be sold. Product definition includes defining usage types and usage rights. Usage types generally define what may be used and when it may be used. Referring to Figure 1, an exemplary usage type 150 is "fixed/fixed" which is a fixed unit, e.g., unit 101, for a fixed time, e.g., weekl. Usage rights generally define how the usage type may be used.

i6 Two exemplary usage rights 155 include the right to reserve a specific unit or the right to reserve a type of unit.
In main operation 210, the user defines a set of SI and a set Hi. The SI
represents the logical inventory at a resort, e.g., a particular unit at a particular resort, that may be sold as part of a timeshare. All of the particulars of a resort that will be sold as a timeshare are defiined in the SI. Referring to Figure l, the SI 110 definition includes the resort 135, the unit types 162 and the particular units 168-170. The HI represents the usable inventory at a resort, e.g., room 101 (140), that is used by bath timeshare owners and transients. "Transients'_' refers to non-timeshare owners, e.g., hotel guests.
The HI definition includes the resort 135 and associated resort entities including clusters 184, buildings, floors, room types 184 and rooms 186 along with details about them that define the characteristics of the resort entities that may be used by timeshare owners and transients.
In main operation 215, the products are associated to the Sl to create product inventory 105. Each discrete component ~pr "widget" 125 of the product inventory 105 is available for sale as a timeshare. The term widget is used because the Tool may be used to create and manage timeshare interests in items other than units.
In main operation 220, a widget is sold. As part of the selling operation, the buyer goes through a contract inventory selection operation that includes: selecting a-particular widget to purchase, optionally becoming a member which provides enhanced rights in the widget, optionally having a points value associated with the widget which provides alternative uses for the widget.
After the sale of a widget, in operation 225., the Tool generates resolved usage rights 188. This operation is done periodically and provides the mechanism by which the owner may use the widget. During product definition, usage rights and policies are defined for each product. The usage rights and policies define how a product may be used by the timeshare owner.
Oftentimes, usage rights and policies are a function of time. For example, a usage right associated with a product may provide rights to a particular unit at time X (such as between 6 and 12 months in advance) while another usage right associated with the product may only provide rights to a particular unit type at time Y (such as between 3 and 6 months in advance). These two usage rights are resolved in operation 225 to determine how, at a particular time, the widget may be used. For example, at time X the timeshare owner may reserve the particular unit whereas at time Y the owner may only reserve a particular unit type.
In main operation 230 a reservation is made at a resort. The reservation operation utilizes HI 115, a member servicing module 235, hotel inventory control 240, resolved usage rights 225 and points rates information 245. In main 250, the Tooi updates inventory availability based on the reservation made in operation 230 After the sale of a widget in main operation 220, the Tool may also be used to predict future resort availability in main operation 255 and set aside blocks in main operation 260. Prediction of future resort availability and blocking is discussed in more detail below. This can include blocking out certain weeks from general availability to persons seeking to stay at a property who are not timeshare owners.
The operations discussed in conjunction with Figure 1 are discussed in detail below. The present invention is not limited to managing timeshare properties. Rather, the present invention is robust enough to define products, sales inventory, and sell widgets that are not property based and then manage their use. For example, a timeshare product may be defined to create an interest in sunset cruises on a particular yacht. Or, for example, a timeshare product may be defined to create an interest in golf' course tee times or racquetball court times. For ease of understanding" however, the description herein will primarily use property based examples i:o describe the present invention.

WO 00!63794 PCTIUSOO/I0492 PRODUCT DEFINITIO1~1 Figure 3 is a flowchart illustrating an exerriplary hierarchical or main operations by which a timeshare product is defined. In main operation 300, the product definition operations begin. Product definition allows a user to define a customized set of timeshare products. Generally, defining a timeshare product is a preliminary operation in creating a widget which is typically a customized interest in a given piece of property, e.g., unit 1 O1 (140), typically located at a resort, e.g., Sunbay (1.35), meant for reoccurring use by the eventual timeshare owner, e.g., week! of each year. As described in further detail below with respect to Figures 18-20, SI is associated with a product to create PI, a set of timeshare widgets, that may be sold.
In main operation 310, the user may define a customized time unit.
The majority of the timeshare industry currently operates on a week-centric schedule, meaning that each timeshare property is typically divided into 52 one week blocks or "increments" wherein each increment may be owned by a timeshare owner. The dynamic nature of the timeshare industry, however, demands that any inventory management tool be alble to support a plurality of customized time units. Accordingly, the Tool includes operations that define a customized time unit.
The system predefines a "day" and a "year" (i.e., 365 days) as the base time units for further defining a customized time unit. A customized time unit that is greater than a day is composed of multiple predefined days. -For example, a customized time unit named "month" may be defined as 28 days.
A customized time unit that is less than a day may be partitioned in terms of a standard hour, minute or second. Each customized time unit that is defined is saved and is available for later use in defining products.
In main operation 320, the user defines a resort season calendar. The resort season calendar is a compilation of time uniia. Generally, the resort season calendar breaks down a particular resort's use year into a set of seasons that are composed of time units. The resort season calendar is used by many of the other modules discussed below. In addition, for every time unit defined WO 00!63794 PCT/IJSOOI10492 a corresponding resort season calendar must also be defined. The resort season calendar for a particular time unit must be created prior to selling a widget that includes the time unit.
In main operation 330, the user may define a customized usage type.
The usage type is a template that is used to determine how a given product's inventory is controlled, priced and sold. Generally, a usage type relates to both the space and time dimension for the ultimate; product. The space dimension refers to the physical space of the item designed to be associated with the product, e.g., a condominium unit or a seat on the yacht. The time dimension refers to the time the.product is meant t~o be used, e.g., "week!"
the first week of each year. Preferably, the Tool includes fixed, floating and points usage types for both the space dimension and the time dimension.
A fixed usage type for the space dimension preferably refers to a fixed unit, e.g., unit I01. A fixed usage type for the time dimension preferably refers to a fixed time, e.g., the first week of High Season. Note, High Season is an exemplary season that is defined in the resort season calendar, discussed herein in conjunction with main operation 320, thavt represents a plurality of associated time units generally encompassing a particular season, such as ski season at a ski resort. A floating usage type for they space dimension preferably refers to a type~of unit, e.g., a two bedroom unit. A floating usage type for the time dimension preferably refers to a particular season, e.g., all of High Season. A points usage type provides space dimension and time dimension flexibility to the product. With a pure points usage type the timeshare owner may reserve any unit at any resort during any time with an equal or lesser point value as Iong as the unit, resort and unit are included in the timeshare. As discussed in more detail below, points may be included with any product to give increased flexibility to the timeshare product.
In main operation 340, the user defines usage rights and policies for a given product which is associated with a usage type:. Each product will have at least one associated usage right and may have more. Additionally, each product may have multiple associated usage rights and the eventual buyer may select to purchase a product having some subset of the available rights. An exemplary usage right defines what type of reservation may be made as a function of the time when the timeshare owner attempts to make the reservation. For example: Right 1 provides that if' a reservation is made more 5 than one year from the start of High Season, then unit 101 / weekl of High Season is guaranteed; and, Right 2 provides that if' a reservation is made less than one year from the start of High Season, then a two bedroom unit during High Season is guaranteed. Note, the exemplary Psight 1 and Right 2 would not apply to a pure fixed/fixed product wherein a particular unit at a particular 10 time is purchased. An exemplary policy defines what alternative uses may be made of a particular usage right: For example, the policy may provide that a timeshare interest in unit 101 during weeks may b~e released into a rental program. The rental program generally that coordinates the rental of the unit, and the timeshare owner is provided with a percentage of the rental proceeds 15 instead of using the unit that year.
In main operation 350, the time unit defined in main operation 310 and the usage type defined in main operation 330, along with associated usage rights defined in main operation 340, are utilized to define a particular timeshare product. A product is a function of a usage type and a time unit and 20 defines what is eventually associated with SI to create widgets that are sold.
In main operation 360, add-on memberships. are supported.
Membership is an optional or mandatory enhancerrient sold with a widget that typically expands the usage rights associated with a particular product.
Time Unit Figure 4 is a flowchart illustrating the exemplary operations associated with defining a time unit. In operation 402, the user determines whether a new time unit will be added to the Tool and hence made available to define a usage type. If the user chooses to add a time unit, in operation 404, the user selects whether the new time unit is greater or less than a "day." Recall, that each defined time unit is based on a predefined "da.y" and "year." If the user chooses to define a time unit that is less than a day operation 406 follows.

In operation 406, the user inputs a name for the time unit. The name selected will then be used to identify the defined time unit throughout the Tool. In operation 408, the user defines a baseiime factor. The baseline factor for time units less than a day defines the number of subdivisions in the day that the time unit equals. For example, if the baseline factor selected is 4, a day is subdivided into four, six hour blocks of time. Accordingly, the time unit is six hours long. In operation 410, the user names the subdivisions.
Referring to the previous example, four subdivision names would be required, e.g., "Sub 1," "Sub2," "Sub3," and "Sub 4." In operations 412 and 414, the user defines the start time and end time for each subdivision. For example, the start time and end time for Subl may be Midnight and 6 a.m. If the user is satisfied with the time unit defined, the user saves the time unit in operation 416. In operation 418, the user may activate the newly defined time unit and hence make it available for usage type definition and resort season calendar definition as discussed in more detail below. The newly defined time unit may alternatively, however, be activated at a later time.
If, in operation 404, the user selects to define a new time unit that is greater than a day, then operation 424 follows. In operation 424, the user inputs a name for the new time unit. The name selected will then be used to identify the defined time unit throughout the Tool. In operation 426, the user defines a baseline factor for the new time unit. The baseline factor, for time units greater than a day, deFnes the number of days to assign to the time unit.
For example, a newly defined time unit named "month" with a baseline factor of 28 is composed of 28 days. Preferably, the Tool already includes a "week"
time unit that is defined with a baseline factor of seven. If the user is satisfied with the time unit defined, the user saves the new time unit in operation 428.
In operation 430, the user may activate the newly dlefined time unit and hence make it available for usage type definition and resort season calendar definition as described below. The newly defined time unit may alternatively, however, be activated at a later time.

If, at operation 402, the user had not selecl:ed to add a new time unit, the user may choose to delete an existing time unit in operation 434, activate an existing time unit in operation 426, or inactivate an existing time unit in operation 440. Deleting a time unit in operation 435 will remove the deleted time unit from the Tool. A previously defined time unit may be activated in operation 438 and hence made available for usage: type definition and resort season calendar definition. A previously activated time unit may be inactivated in operation 442 and hence made unavailable for usage type definition and resort season calendar definition.
Preferably, the time unit definition operations are implemented in a window, not shown herein, and preferably the workflow of the time unit definition window is left to right. The time unit dlefinition window and associated datawindow fields, i.e., operations 400 - 442, however, do not enforce the workflow. Accordingly, the operations 400 - 442 may be performed in any order the user of the tool desires.
Resort Season Calendar The resort season calendar structures the layout of a use year within a resort. Generally, a resort's use year is the entire year. However, some resorts may only be open for particular times of the year, e.g., a ski resort may only be open during ski season. A resort's use year is decomposed into seasons which are a set of increments of time units. An increment is a single representation of the time unit defined by the user. For Example; a time unit of 7 days, i.e., a "week" time unit as discussed above in conjunction with Figure 4, is represented by 52 increments. The increments are grouped together in seasons. Every increment must be assigned to a season. Once completely defined, the resort season calendar series as the default season calendar for the specified time unit for the specified resort.
Figure 5 is a flowchart illustrating the exemplary operations associated with defining a resort season calendar. Defining the resort season calendar includes preliminary resort season calendar main operation SOOa, increment one start date main operation SOOb, seasons main operation SOOc and swap WO 00/b3794 PCT/IIS00110492 increment main operation 500d. The preliminary resort season calendar main operation 500a includes selecting the resort and selecting a time unit. In operation 502, the resort that the calendar is being defined for is selected from a set of previously defined resorts. In operation 504, the time unit that the calendar is being defined for is selected from a set of previously defined time units.
In main operation SOOb, the start dates for the first increment are defined. These are known as increment one start dates (hereinafter "IOSD") The IOSD definition determines the starting point from which ail calendars of the selected time unit in the specified resort will begin. The IOSD is the first day of the first time increment in the use year for the specified time unit.
The check-in day for each increment of a week-based product is the same day.
This allows the user to set up a distinct calendar far each check-in day. For non-week based time units, e.g., 4 days, the check-in days are a function of the IOSD.
In operation 506, the user selects the year that the IOSD is being specified for. In operation 508, the user selects the start date of a "week"
based time unit's increment with a Sunday check-in, i.e, the IOSD with a Sunday check-in. In operation 510, the user selecta the IOSD with a Monday check-in. In operation S 12, the user selects the IOSD with a Tuesday check-in. In operation 514, the user selects the IOSD with a Wednesday check-in.
In operation 516; the user selects the IOSD with a Thursday check'-in. In operation 518, the user selects the IOSD with a Friday check-in. In operation 520, the user selects the IOSD with Saturday check-in. And, in operation 522, the user selects the Start Date of the first day in the non-week based time unit's increment One. Based on the IOSD the start. day for any increment of the time unit or the start of any season may be derived from the following formula: IOSD+((week#-1)*time unit).
In main operation SOOc, the seasons for the resort season calendar are defined. The seasons operations allow the user to associate each time increment for the time unit's use year to an organi~;ation's defined season.
An "organization" represents a high level entity such as MarriotT~ or HyattTM
that has a plurality of resorts. The organization defines all possible seasons and the resort season calendar includes these organization defined seasons for selection. The season definition results in groupings of time increments. For example, the first 13 "week" increments may be grouped together to create a "High Season." High season may equate, for example, to what is typically referred to as "ski season" at a ski resort.
In operation 524, the user defines a code for the season. The code allows other modules to access the season definition. For example, the code 20 may be "highseason." In operation 526, the name for the season is selected.
For example, referring to the example above the season may be named "High Season." In operation 528, the color (for display purposes) for the season is selected. The resort season calendar will display all dates encompassed by the "High Season" with the same color. And, in operation 530, the increments that the season represents are defined. Referring again to the example above, increments 1-13 of the "week" time unit may utilized to populate the High Season.
In main operation SOOd, the user defines "swap increments." When a widget is sold that includes an increment of a time unit with a guarantee that a specific day, e.g., Easter Sunday, will always be included with the widget, then an adjacent increment may need to be swapped with the original increment so as to ensure that Easter Sunday is alv~~ays included with the widget. The adjacent increment is the "swap" increment.
In operation 532, the user selects the year far the swap increment operations. The year dictates what potential values are presented for the subsequent swap increment operations. In operation 534, the user selects the time increment from the specified year for the swap. In operation 536, the user is presented with the use year associated with the specified time increment. In operations 538 and 540, the user is presented with the start date and the end date for the specified time increment. In order to swap increments the user is presented with all of the available time :increments for the year in two side-by-side lists. The user selects the increments that are two be swapped from the two lists and executes the swap operation preferably by hitting a swap button. The two increments are the;n swapped.
Preferably, the resort season calendar definition operations are 5 implemented in a window, not shown herein, and preferably the workflow of the resort season calendar definition operations is left to right. The timeshare product definition window and associated datawindow fields, i.e., operations 500 - 590, however, do not enforce the workflow. Accordingly, the operations 500 - 590 may be performed in any order the user of the tool desires.
10 Usage Type Definition Figure 6 is a flowchart illustrating the exemplary operations associated with defining a usage type. A usage type defines how PI is controlled, priced, and sold. PI, as discussed herein, comprises a set of widgets that may be sold as timeshares. Usage type definition includes main operation 600a wherein 15 sales attributes are defined, main operation 600b'wherein pricing attributes are defined and main operation 600c wherein contract attributes are defined. The sales attributes determine how PI is controlled, the pricing attributes determine how PI is priced and the contract attributes determine how PI is sold.
20 Figure 6a is a table illustrating eight exemplary usage types and their associated sales attributes 620, pricing attributes 622 and contract attributes 624: The exemplary usage types illustrated in Figure 6a include a space dimension component and a time dimension component, e.g., "fixed/fixed"
626 representing a fixed unit (space dimension) and fixed time (time 25 dimension). For timeshare interests in property, the space dimension represent the actual space, e.g., the unit, that is associated with the usage type and the time dimension represents the time in which the associated space may be used. The space dimension, however, may represent interests in items beside property such as use of a racquetball court. Preferably, the usage types described in Figure 6a are predefined in the Tool and available to the user of the Tool in a pulldown window when the user initially begins the usage type definition operations.
Still referring to Figure 6a, a fixed unit (space dimension) / fixed week (time dimension) usage type 626 is used to create a widget that includes an interest in a particular unit at a particular time, e.,g., unit 101 during weekl . A
fixed unit / floating week usage type 628 is used ~to create a widget that includes an interest in a particular unit during a particular season, e.g., unit 101 during High Season. The High Season is defined in the Tool, as discussed above in regard to the resort season calendar, and may, for example, represent skiseason.
A fixed unit / fraction usage type 630 is used to create a widget that includes an interest in a particular unit for an amount of time that includes a plurality of increments of the selected time unit. Figure 6b provides an example of products using usage types with a fractional time dimension. The fractional usage types illustrated in Figure 6b are based on the "week" time unit provided for example above. The fractional usage types include both fixed and floating time dimensions. The fractional time dimension for Fraction 1 (632) includes weeks I-6 (634), four weeks during High Season and three weeks during Low Season (636). Like the Ffigh Season provided for example herein, the Low Season is defined in the Tool and might represent the off season at a particular resort. The fractional time dimension for Fraction (638) includes weeks 14-19 (640), four weeks during High Season and three weeks during Low Season {642). The fractional time dimension for Fraction 3 (644) includes weeks 27-32 (646), four weeks during High Season and three weeks during Low Season (648). Finally, the time dimension for Fraction 4 (650) includes weeks 40-45 (652), four weeks during High Season and three weeks during Low Season (654). Note, the Tool allows fractions to include a mix of fixed, floating and points time dimensions. With a fixed space dimension, each fraction illustrated in Figure 6b is associated with a particular unit.

A floating unit / fixed week usage type 656 is used to create a widget that includes an interest in a particular type of unit at a particular time, e.g., a two bedroom unit during weekl. A floating unit / floating week usage type 658 is used to create a widget that includes an interest in a particular type of unit during a particular season, e.g., a two bedroom unit during High Season.
A floating unit / fraction usage type 660 is used to create a widget that includes an interest in a particular type of unit for an amount of time that is a function of the selected time unit. Figure 6b illustrates a set of products based on usage types with a fractional time dimension. WVith a floating unit space dimension, each fraction illustrated in Figure 6b is associated to a particular type of unit.
A whole ownership usage type 662 is used t:o create a widget that includes an interest in a particular unit in perpetuity. A pure points usage type 664 is used to create a widget that is simply a quantity of points that represent the ability to use at least one unit at least one particular time that has the same or a lesser point value. Preferably, a pure points widget allows the usage of a plurality of rooms, at a plurality of resorts and at a plurality of times with the same or lesser point value.
In further describing the operations associated with defining a usage type the various values used to define the usage types described above in regard to Figure 6a are referred to where appropriate below.
Referring to Figure 6, the sales attributes definition operation 60Oa preferably includes: operation 602, defining a sales time unit; operation 604, defining a sales time unit count; operation 606, defining a sales increment;
operation 608, defining sales time allocation; and operation 610 defining sales points. Generally, the sales attributes determine how PI is controlled. Like many of the operations discussed herein, the sales attribute definition operations may be performed at any time. Preferably, however, the sales attributes cannot be modified once the usage type is used to define a product.
In operation 602, the user defines the sales tame unit 666. The sales time unit defines the length of time for usage of the. inventory that the WO 00!63794 PCT/US00/10492 prospective purchaser may be purchasing. For example, referring to Figure 6a, if the user is creating the fixed unit / fixed weE;k usage type 626 the user selects the "week" sales time unit. The user would have previously defined a "week" time unit in the operations associated with. the time unit definition discussed above with regard to Figure 4. Preferably, a set of sales time units that is the same as the set of previously defined time units is available to select from.
If the sales time unit defined is "points," then the usage type being defined is "pure points." The remaining applicable attributes, described below IO in operations 604-618 are defaulted to "points." IiF the sales time unit is changed to something other than "points" then the defaulted attributes will be cleared of their "points" value.
In operation 604, the user defines the sales time unit count 668. The sales time unit count defines how many sales time units are defined for a IS given use year. Referring to the fixed unit / fixed week usage type 626, the wiser could select 52 for the sales time unit count, representing 52, one "week,"
time units for a given year. The sales time unit count 668 defaults to a value based on the sales time unit 666 and the user may not select a value greater than the defaulted value. Preferably, the sales time unit count 668 defaults to 20 its maximum allowed value when the sales time unit 666 is selected. For example, if the sales time unit 666 is "week" then the default sales time unit count 668wvalue is 52. The defaulted sales time unit count 668 will be determined by how many whole sales time units 666 fit into a use year (typically, 365 days). If the sales time unit 666 is greater than a day, than the 25 sales time unit count 668 is (365/x) where x is the sales time unit's baseline factor (defined in operation 326). If the sales time unit 666 is less than a day, then the sales time unit count is (365*x) where x is the sales time unit's baseline factor (defined in operation 308).
In operation 606, the user defines the sales increment 670. The sales 30 increment 670 defines how many widgets are ultimately generated for the Pl, as discussed below. . A "widget" represents a discrete item in the product inventory. Typically, a widget represents a timeshare interest in a piece of property, i.e., SI, as defined by the operations of this invention. However, a widget may represent timeshare interests in items besides property, e.g., a 4 p.m. racquetball court time every week.
Preferably, the sales increment 670 is defaulted to the same value that the sales time unit count 668 is defaulted to when the sales time unit 666 is selected. Preferably, the sales increment 670 is defaulted again to the value of the sales time unit count 668 if the user changes the value of the sales time unit count in operation 604. Preferably, the sales increment 670 cannot be a value that is greater than the sales time unit count 668.
Preferably, if the sales increment 670 is modified to a value less than the value specified for the sales time unit count 668, then the user has set up a fractional product. When this occurs; then the sales time allocation 672 will be defaulted to "fraction", the pricing time allocation 678, described below in operation 614, is defaulted to "increment," and the contract time allocation 682, described below in operation 618, is defaulted to "increment." The details of the time dimension for a fractional product, e.g., Fractions 1 -4 of Figure 6b, are defined in operations 1940 - 1944, as discussed below.
Preferably, under any circumstance, the sales incrf;ment 670 must be greater than 0.
In operation 608, a sales time allocation field 672 displays the usage types sales time allocation as defined by the sales time unit 666, sales time unit count 668 and the sales increment 670 attribui:es defined in operations 602-606. Preferably, the valid values for the sales time unit allocation 672 are "fixed or floating," "fraction" or "points."
Preferably, the sales time allocation 672 is defaulted to a value that is a function of the value specified in the sales time unit count 666 and the value specified in the sales increment 670. Accordingly, if the sales time unit count 668 is equal to the sales increment 6760, then the sales time allocation 672 is defaulted to "Fixed or Floating." And, if the sales time unit count 668 is greater than the sales increment 670, then the sales time allocation 672 is w0 00/63794 PCTIUS00l1049.2 defaulted to "Fraction." As mentioned above, if the sales time unit 666 is "points" then the sales time unit allocation 672 is defaulted to "Points." The sales points attribute is not applicable if the sales time unit specified is "Points."
5 in operation 610, the user defines whether the widgets, that will eventually be generated for the usage type, will have a points usage conversion. "Points" generally refers to a value that the usage type is accorded. For example, if a usage right, as discussed below, provides sales points 674 in certain circumstances for the product, then the owner of the 10 timeshare interest is able to exchange points for the use of a variety of units provided that the units have an equal or lesser point value.
The pricing attribute definition main operation 600b, preferably includes: operation 612, defining a pricing unit allocation 676; and operation 6I4, defining a pricing time allocation 678. Generally, the pricing attributes 15 determine how product inventory is priced.
In operation 612, the user defines the pricing unit allocation 676. The pricing unit allocation 676 determines the pricing attributable to the space dimension. Preferably, the valid values for the pricing unit allocation 676 are unit, type and points. Any usage type with an "unit" pricing unit allocation 20 676 will create a usage type with a "fixed" space dimension. Any usage type with a "type" pricing unit allocation 676 will create a usage type with a "floating" space dimension. And, any usage type with a "points" prici-ng unit allocation 676 will create a usage type with a "points" space dimension.
In operation 614, the user defines the pricing time allocation 678. The 25 pricing time allocation 678 determines the pricing attributable to the time dimension. Preferably, the valid values for the pricing time allocation 678 are increment, season and points. Any usage type witlh an "increment" pricing time allocation 678 will create a usage type with a "fixed" time dimension.
Any usage type with a "season" pricing time allocation 678 will create a usage 30 type with a "floating" time dimension. And, any usage type with a "points"

pricing time allocation 678 will create a usage type with a "points" time dimension.
The contract attribute definition main operation 600c preferably includes: operation 616, defining contract unit allocation 680; and operation 618, defining contract time allocation 682. Generally, contract attribute definition determines how product inventory is sold.
In operation 616, the user defines the contract unit allocation 680.
Preferably, the valid values for contract unit allocation 680 include unit, type and points. The contract unit allocation 680 determines what space dimension the widget will encompass. In operation 620, the user defines the contract time allocation 682. Preferably, the valid values for contract time allocation include increment, season and points. The contract time allocation determines what time dimension the widget will encompass.
Preferably, in practical use of the Tool, only trained Tool users will define usage types in the Tool, such as those trained Tool users working for the Tool supplier. Representatives of the Tool supplier may Learn, from the timeshare developer/manager, the desired functional requirements, will then define usage types based thereon. The set of usagE; types that a particular timeshare developer or manager wants to implement are defined functionally and then the Tool user defines those usage types in the Tool by defining the usage type attributes described in operations 600 - 620. This methodology is considered preferable because of the necessity to correctly define the attributes described in operations 600 - 620. Clearly, however, any user that is trained in operation of the Tool could potentially define usage types in the Tool.
A particular usage type, defined in operations 600 - 620 may be deleted from the Toot at any time so long as it is not currently used in the definition of a timeshare product. In addition, a usage type may be activated or inactivated at any time. Activation of a usage type means that the usage type is available for the definition of a timeshare product. An inactivated usage type that was previously used in the definition of timeshare product does not effect the previously defined timeshare product.
Preferably, the usage type definition operations are implemented in a window, not shown herein, and preferably the workflow of the usage type S definition window is left to right, similar to that shown in Figure 6a. The usage type setup window and associated datawinclow fields, i.e., operations 600 - 620, however, do not enforce this workflow. Accordingly, the operations 600 - 620 may be performed in any order the user of the Tool desires.
Usage Right and Usage Policy Each product 145 will have a set of usage rights and usage policies 155.
A usage right defines how a widget may be used once it is purchased. A usage policy defines how a particular right may be exercised by the purchaser. In prior art systems, usage rights and policies are managed on an ad hoc basis -it is up to a particular agent to check a timeshare owners contract or simply remember what rights the timeshare owner has. Z'he present invention provides for user definable rights and policies which are associated with a particular product in the Tool. Accordingly, when the user is operating the Tool for inventory management the usage rights a.nd policies associated with a particular product are part of the product and fully accessible by the Tool.
As discussed below in conjunction with Figure 23, the rights are.resolved periodically to provide the inventory manager with a current status of the rights available to a particular timeshare owner at a particular time and to automatically account for resolved rights in hotel availability.
Preferably, the Tool includes a set of usage. rights that may be customized for a particular product by the user. Llsage rights and policies refers to a user-defined set of parameters that are defined in general terms to express "what," e.g., a points amount, a specific unit, or a unit of a specified unit type, "when," e.g., two months after contract closing, or in the High Season, and "where," e.g., a specific resort, an owner may exercise their "rights," Preferably, the set of usage rights irrcludfes: the reservation start and end date, the usage start and end date, the length of stay, and the accommodation. The usage rights definition includes a Boolean relationship, i.e., AND or OR, between different rights that allows the user to establish relationships between different rights for a given product. In addition, the usage rights definition operations allow the user to define a probability factor for each right that is useful in market planning and future availability planning in conjunction with blocking, discussed in more detail below.
The following operations are described to create two exemplary rights for a particular product. "Right 1" is the right to a~ particular unit in a particular week. The definition of High Season was provided above as an example in the resort season calendar section. "Right 2" is the right to a particular type of unit in the High Season. Each right is defined separately.
Accordingly, the following operations would have to be performed for each right.
Figure 7 is a flowchart illustrating the exemplary operations involved in defzned a usage right. In operation 700, the user selects a product for which they desire to define a usage right and policy for. In operation 710, the user selects whether they wish to add a new usage right to the product. If so, the user names the new usage right in operation 715. 'the names, by way of the example outlined above, are "Right 1" and "Right :2."
In operation 720, the user selects the reservation start date. The reservation start date determines when an owner may request a reservation according to a particular right. Right 2 may allow the timeshare owner to make a reservation for a unit type during High Season one year prior to High Season. This means that the owner may first reserve the particular unit type for High Season starting one year prior to High Season. In operation 720, this is achieved by entering a formula that consists of a defined keyword and an expression -- @seasonstart-365. The keyword for the reservation start date is @seasonstart wherein @seasonstart is defined as January 1 of the particular year. The expression is (-365) which represents 365 days before @seasonstart. Therefore, with @seasonstart-365 entered as the reservation start date the owner has the right to make a reservation for his particular timeshare product 365 days before the first day of High Season. The keywords, starting with "@," are reserved in the Tool.
In operation 725, the user selects the reservation end date. The reservation end date determines the last day in which an owner may request a reservation according to a particular right. Right :? may allow the timeshare owner to make a reservation for a unit type during High Season up to 7 days before the end of High Season. Like operation 720; the reservation end date is entered by way of a formula that consists of a defined keyword and an expression. For Right 2 the keyword and expression is @seasonend-7. The keyword for the reservation end date is @seasonend wherein @seasonend is defined as March 31 of the particular year. The expression is (-7) which represents 7 days before @seasonend. Therefore, 'with @seasonend-7 entered as the reservation end date the owner had the right to make a reservation for his particular timeshare product 7 days before the end of High Season.
Right 1 may allow the timeshare owner to make a reservation for unit 101 during weekl of High Season between I3 months and I year before High Season. In operation 720, this is achieved by way of entering @seasonstart -395 for the reservation start date. And, In operation 725, @seasonstart-366 is entered for the reservation end date. Therefore, the owner has a right to reserve a particular unit at a particular time between 395 days before High Season and 366 days before High Season.
In operation 730, the user selects the usage start date. The usage start date determines the start of when the owner has aright to occupy. Referring to the example above the owner has a right to occupy a particular unit type during High Season for Right 2 and the owner has a right to occupy unit l0I
during weekl for Right I. Accordingly, for Right :2 the usage start date, in operation 730, is defined as @seasonstart. And, for Right 1 the usage start date, in operation 730, is defined as @deedstart wherein @deedstart is defined as the beginning of week 1.

WO 00/63794 PCTlLTS00/10492 In operation 735, the user selects the usage end date. The usage end date determines the end of when the owner has a right to occupy. For Right 1 the usage end date, in operation 735, is defined as @seasonend. And, for Right 1 the usage end date, in operation 735, is defined as @deedend wherein 5 @deedend is defined as the end of weekl.
In operation 740, the user defines the length of stay. As the name implies, the length of stay represents how long the owner may stay at the particular unit type for Right 2 or at the particular unit for Right 1.
Preferably, this value defaults to the time unit, e.g., "week", selected for the 10 particular product.
In operation 745, the user defines the probal'oility that the member will exercise the specified usage right within the reservation window defined.
Preferably, the sum of all probabilities for the rights associated with a product must equal 100%. The probability is a variable that rnay be used in 15 conjunction with market planning to forecast future product inventory needs and to forecast future availability blocking requirements.
In operation 750, the user defines the accommodation for the rights.
For Right 2, the accommodation would be "unit type" and for Right 1 the accommodation would be unit. The particular unit type of Right 2 or the 20 particular unit of Right 1 is defined during contract inventory selection discussed in conjunction with Figure 21 below. Preferably, the set of available accommodation values is unit, unit type and points.
In operation 755, the user defines the Boolean operator which determines the interaction of various rights associated with the product. For 25 example, Right 1 would be associated with a number, e.g., "1," and Right 2 would be associated with a number, e.g., "2." The operator might be OR.
Accordingly, the product includes 1 OR 2. This means that the product includes Right 1 or Right 2. So, if Right 1 is exercised the owner may not exercise Right 2. In contrast, if Right 2 is exercised the owner may not 30 exercise Right 1.

In operation 760, the user rnay elect to edit an existing usage right or define another~new usage right for the product. After which the user may edit or define the reservation start date in operation 720, edit or define the reservation end date in operation 725, edit or define the usage start date in operation 730, edit or define the usage end date in operation 735, editor define the length of stay in operation 740, edit or define the probability in operation 745, edit or define the accommodation in operation 750, and/or edit or define the operator in operation 755. In operation 765, the user may save the usage right that was edit or defined.
If, in operation 770, the user does not choose to modify an existing usage right, then the user may choose to delete an existing usage right in operation 780. The user selects the usage right to delete in operation 785 and then deletes the usage right selected in operation i'90. The user, in operation 795, may choose to edit an existing usage right, delete an existing usage right, or create a new usage right. If so, the user starts the usage rights definition process from the beginning at operation 700. Otherwise, the user may end the usage rights definition operations at operation 79f.
A policy defines how a particular right rnay be exercised. For example, referring to Right 1 and Right 2 presented for example above, the owner may have a Policy 1 that allows occupation and a Policy 2 that allows the product to be placed in a rental program. A rental program, for example, allows the timeshare owner to rent out his interest for a particular year. Referring again to operation 710, if the user does not elect to add a new usage right, then the user may modify an existing usage right in operation 770. Policies are defined for each right associated with a product in substantially the same way as usage rights are implemented as discussed above. The policies, however, axe defined in a business rules engine that is associated with the Tool.
Preferably, the usage rights and policies definition operations are implemented in a window and preferably the workflow of the usage rights and policies widows, not shown herein, is left to right. The usage rights and policies windows and associated datawindow fields, i.e., operations 700 - 799, however, do not enforce the workflow. Accordingly, the operations 700 - 799 may be performed in any order the user of the tool desires.
Timeshare Product Generally, timeshare product definition refers to adding or modifying a product in the tool and is one of main operations 350 of the overall product definition operations. The timeshare product definition operations utilize the usage types and usage rights discussed above to define particular products.
Figure 8 is a flowchart illustrating the exemplary operations involved in timeshare product definition. In operation 805, the user determines if a new IO product will be created. If so, in operation 805, the user selects a previously defined usage type for the new product. In operation 815, the user names the product. In operation 825, the user determines if the product will have a perpetual life.
If the product will not have a perpetual Life, the user sets the use term start date in operation 860. Preferably, the use term start date must be specified. The use term start date determines the first possible day that any piece of inventory defined by this product can be used by the timeshare owner or member. In operation 865, the use term expiration date is set. The use term expiration date determines the date the product expires on. In operation 867, the use term in years is defined. The use term in years determines the use term of the product in years starting in the year of the owner first use date.
The owner first use date is defined during contract inventory selection as discussed below in conjunction with Figure 21.
If the use term is perpetual, then the use term of the product being defined has no expiration and will exist in perpetuity. As a result, the use term years field, in operation 867, and the use term expiration date field, in operation 865, will be disabled: Preferably, if values are already specified for the use term years field and the use term expiration date field, then the user may only check the use term never expires attribute in operation 825 as long as no product inventory widgets derived from this product are sold yet. If no widgets are sold, then the values from the use terrra years and use term expiration date fields will be cleared. However, i:f a widget has been sold the use term never expires cannot be redefined to "never expires." Product inventory for these non-expiring products in never reset.
If the use term is not perpetual, then use team years, in operation 867, and/or the use term expiration date, in operation 865, must be specified. If only the use term years is specified, then the product inventory will be reset every 'n' years for perpetuity. The owner of the widget will have rights to that product inventory for the 'n' years determined by the use term years attribute starting on the owner first use date specii~ed at contract sales time for the widget. After 'n' years from the owner first use date, the product inventory is available for use by another owner. However, the next owner does not have to use the product as soon as it is available for use again. The next owner may choose to specify an owner first use date that leaves a gap between the previous owner's usage term and the new owner's usage term.
This time may be lost if another product does not use the gap in time.
If only the use term expiration date, in operation 865, is specified, then the product inventory widget is sold once and never reset. The owner of the widget will have rights to that widget until the use: term expiration date. If both the use term expiration date, in operation 865, and the use term years, in operation 867, is specified then the product inventory widget will reset every 'n' years until the use term expiration date. The owner of the widget will have rights in that widget for 'n' years until the use term expiration date.
After 'n' years the product inventory is reset and the widget is again available for sale.
If the product is defined as perpetual in operation 825 or after the use term start date, use term end date, and use term in years are defined in operations 860, 865 and 867, then the user determines if the frequency for the product is annual. The frequency determines how often an owner of a product inventory widget has rights to use the widget. For example, an annual frequency gives the owner rights for every year. Ii" the product does not have an annual frequency, then the user defines the frequency in operation 853. For WO 00!63794 PCT/US00/10492 example, the frequency may be set to biennial which means that the owner has rights every other year. In operation 855, the user sets the frequency start year. The frequency start year determines the start year for the selected frequency other than "annual." In addition, it is the starting point for the determination of each occurrence of a product's use year which is used in the resort season calendar. Preferably, the valid values for the frequency attribute defined in operations 830, 853 and 855 are annual (every year), biennial (every other year), triennial (every three years) and quadrennial (every four years).
In operation 835, after determining the frequency in operations 830, 853 and 855, if a points usage type is selected in operation 810 or the sales time unit, defined in operation 610, is defined as "points," then the user may add or delete a points package in operation 840. If the user chooses to add a points package in operation 840, then the user can define a points package.
To define a new points package, in operation 845, the user sets the point increment. The points increment is the number of points that the specific paints package represents. Points packages may only be sold in valid increments defined by one or many points packages. If the user deletes a points package then the currently selected points package is deleted.
A points product is any product that is associated with SI that include an equivalent points value. A pure points product is a type of product that allows simple("pure") point amounts to be sold without having to back the points with physical inventory or without linking any other requirement in any way to the product. A resort is assigned an overall amount of pure points to divide up and sell as pure points products. A points package is the increments via which a points product can be sold. Every points product needs at least one package (standard) defined in order to allow selling. Points can be bought as multiples of the standard points package or as individual non-standard points packages. In addition, an extra points package can be defined to allow selling of extra points above and beyond a package. For example, if the standard is defined as 1000 points and an extra is defined as I00 points, a buyer could purchase 1200 points (1 standard + 2 extras); if no extra is defined, buyers are limited to purchasing 1000 points, 2000 points, etc., which are increments of the standard points product of 1000 points.
Finally, in operation 850, the user may add comments to the product 5 The comments operation 850 allows the user to describe product attributes that may not be described elsewhere. The comments may include the distribution for the product 850a and a general description of the product 850b.
If, in operation 805, discussed above, the u;cer is not creating a new 10 product, then the user may modify an existing product in operation 870. In operation 875, the user selects the product to modify. Afterward, the user moves to operation 825. Operation 825 and the following operations are described in detail above.
Preferably, the product definition are impIe:mented in a window and 15 preferably the workflow of the timeshare product definition window, not shown herein, is left to right. The timeshare product definition window and associated datawindow fields, i.e., operations 800 - 850, however, do not enforce the workflow. Accordingly, the operations 800 - 850 may be performed in any order the user of the tool desires..
20 Membership Membership is an optional or mandatory enhancement sold in conjunction with a widget. Memberships alter the usage right of the stand-alone widget. For example, the widget purchased alone may have usage rights at resort A exclusively. However, the same widget purchased with a gold 25 membership expands the usage rights to cover rights in Resorts A, B and C.
Memberships are preferably renewed by the buyer within some time period, typically a year.
Figure 9 is a flowchart illustrating the exemplary operations associated with adding a membership to a product. In operation 900, the user selects the 30 add-on membership icon from the main menu to start the operations of adding on a membership to a product. In operation 905, the user selects a product to add a membership to. In operation 910, the user determines if a new membership will be added to the product. If a nevv membership will be added, then the user sets the renewal frequency in operation 915. The renewal frequency determines the recurring frequency of the membership in sales years. For example, if the frequency is "annual," then the membership can be renewed every year; if the frequency is "biennial," then the membership can be renewed every other year.
In operation 920, the user sets the membership price. The membership price is the price of the membership for the specified renewal frequency. In operation 925, the user may set the membership required flag. The membership required flag determines whether the defined product requires membership selection during contract inventory selection, as discussed below in conjunction with Figure 21. If the flag is set, then only one membership must be associated for the defined product in the contract.
Each add-on membership for a particular product includes its own set of usage rights. Accordingly, operations 930-945 allow the user to define a set of usage rights for the particular product and associated add-on membership. In operation 930, the user may choose to add a new usage right to the membership. Operation 930a, takes the user to the start of the usage right definition operations associated with Figure 7, as described above. In operation 935, the user may select to delete a usage right in which case the user selects a usage right that-is deleted in operation 935a. In operation 940, the user may select to modify an existing usage right in which case the usage right definition operations, as discussed above in conjunction with Figure 7, are accessed in operation 940a. The newly defined membership and usage rights may be save in operations 945 and 945a. Or, the user may select to end the add-on membership definition process in operations 950 and 950a.
If, in operation 910, the user does not choose to add a new membership to the product, then the user may select a previously defined membership for the product in operation 955. Then, the user may choose to delete the membership in operation 960 or modify the membership in operation 965. If deletion is selected, then the previously selected .membership is deleted in operation 960a arid the user may start the add-on membership process anew at operation 900. If the user chooses to modify the membership, then the user performs operations 915-945 as discussed above.
HOTEL AND SALES INVENTORY (DEFINITION
Hotel Inventory ("HI") preferably includes resorts, clusters, room types; and rooms and buildings, locations and attributes. HI represents all of the inventory that can be used by both timeshare owners and transient guests.
An exemplary block diagram illustrating the HI for the Sunbay Resort is shown in Figure 10 and discussed in more detail below. Note, the HI
illustrated in Figure 10 is the same HI illustrated at reference numeral 1 i 5 in Figure 1.
Sales Inventory ("SI") preferably includes resorts, unit types, and units along with associated phases, buildings, and attributes and is the space dimension of product inventory. The entities that populate SI are the logical entities that can be sold as part of a product. The entities of SI are "logical"
because they represent what may be sold as opposed to what may be used, i.e., HI. A block diagram illustrating the SI for the Sunbay Resort is shown in Figure 11 and discussed in more detail below. Note, the SI illustrated in Figure 11 is the same SI illustrated at reference numeral 110 in Figure 1.
The following is one example of the difference between SI and HI. For example, a three bedroom unit may be composed of a two bedroom unit and a one bedroom unit with a door in between. This arrangement is referred to as a "lock-out." The three bedroom unit is sold, however, the owner may choose to only use the two bedroom unit and do something else with the one bedroom unit, e.g., rent or place in exchange program. The; three bedroom unit for sale comes from SI and the two bedroom unit and one bedroom unit for use come from HI.
Figure I2 illustrates the exemplary hierarchical operations involved in defining HI and SI. The HI and SI definition operations include: defining a resort or hotel in operation 1210; defining room types in operation 1220;

defining rooms in operation 1230; defining unit types in operation 1240;
defining units in operation 1250; and defining locations of interest that are near the resort, in operation 1260. HI is primarily defined in operations 1210, 1220 and 1230 and SI is primarily defined in operations 1240, 1250 and 1260.
However, many of the attributes defined in the operations, especially those associated with operation 1210, are related to both HI and SI.
Figure 10 is a block diagram illustrating an exemplary HI for the Sunbay Resort 1002. The Sunbay Resort 1002 HI has three exemplary clusters: three bedroom rooms 1004, two bedroom rooms 1006 and standard rooms 1008, i.e., one bedroom. Clusters are generally groupings of rooms with a shared characteristics such as the number ovrooms. The clusters each include associated room types. The three bedroom cluster 1004 includes a three bedroom ocean view room type 1010. The two bedroom cluster 1006 includes a two bedroom ocean view room type lOl~2 and a two bedroom golf course view room type 1014. The standard room type cluster 1008 includes a one bedroom studio room type 1016. Additionally, the room types have associated rooms. The three bedroom ocean view room type includes two rooms, 105 (1018) and 106 (1024), that have three bedrooms and an ocean view. Note, room 105 (1018) is composed of two rooms, a two bedroom lOSA
(1020) with an ocean view and a one bedroom 105B (1022) that are locked-off from each other. The two bedroom ocean view room type includes three rooms, 101 (1026), 103 (1028) and lOSA (1030) that have two bedrooms and an ocean view. The two bedroom golf course view room type includes three rooms, 102 (1032), 104 (1034) and 109 (1036), that have two bedrooms and a golf course view. Finally, the studio room type includes three rooms lOSB
(1038), 108 (1040) and 110 (1042).
Figure 11 is a block diagram illustrating an exemplary SI for the Sunbay Resort. The Sunbay Resort 1002 SI has two unit types: three bedroom I I04 and two bedroom 1106. The unit types each include associated units. The three bedroom unit type includes unit 105 ( 1 I08). The two WO 00!63794 PCT/US00I10492 bedroom unit type includes unit 101 (1110), unit 102 (11 I2), unit 103 (1114) 'and unit I04 (1116).
The following discussion provides a preferable set of operations to define the HI and the SI for a resort such as the Su.nbay Resort 1002. The definition of HI results in, for example, a representation in the Tool of the Sunbay Resort 1002 as illustrated in Figure 10. Tlhe definition of SI results in, for example, a representation in the Tool of the Sunbay Resort 1002 as illustrated in Figure 11. However, both HI and SI typically include more attributes, as discussed below, than is shown in Figures 10 and 11.
Figure 13 illustrates the exemplary operations involved in defining the Resort or Hotel portion of HI and SI, such as the Sunbay Resort 1002, including: providing Resort information in main operation 1300a, defining clusters in main operation 1300b, defining phases in main operation 1300c, defining buildings in main operation 1300d, defining floors in main operation 1300e, defining proximity in operation 1300f and defining resort attributes in operation 1300g. Main operations 1300a-130Og create database "tables."
Each table is comprised of a defined set of attributes that define the components, e.g., a "cluster" or a "phase," of a resort or hotel.
In main operation I300a, the user defines general information pertaining to the resort or hotel being setup. Note., this document generally refers to "resorts" or "hotels," however, the Tool :is not limited to resort or hotels. Rather, the Tool may be used to manage a.ny entity with a timeshare interest. In operation 1302, the table includes a resort Id. This is the primary key of the resort table. The resort Id is what other tables link to when setting up the entire resort. In operation 1304, the table includes an organization Id.
This is the foreign key (hereinafter "FK") to the organization table. As discussed above the organization is the high level entity that includes the resort. An FK is a database implementation parameter. In operation I306, the user defines a resort number. The resort number its a unique number to identify the resort within the organization. In operation 1308, the user defines a resort code which is a unique code to identify the resort within the organization. In operation 1310, the user defines a resort name, e.g., "Sunbay." In operation 1312, the user provides a description of the resort. In operation 13I4, the user defines a planning horizon for the resort. The planning horizon is the number of days in the planning horizon of the resort.
5 The planning horizon number is only used for hotel resorts and it is used in calculating how far in advance to create resolved usage rights and availability, as discussed in more detail below. A hotel resort has both timeshares owners and transient guests. In operation 1316 the user defines a historic horizon which is the number of days to hold historic hotel resort information.
10 In operation 1318 the user defines a type. JPreferably, the values for type include sales, hotel and both. A "sales" value for the type means the resort is strictly a timeshare resort - there will not be any transient guests. A
"hotel" value for the type means the resort is stricltly a hotel - there will not be any timeshares. Finally, a "both" value for the type means the resort is 15 both a timeshare property and that it will also havE: transient guests.
In main operation 1300b, the user defines the clusters associated with the resort defined in main operation 1300a. In operation I020, the table includes a cluster Id. This is the primary key of the cluster table. The cluster Id provides a linking mechanism to associate with other tables. In operation 20 1322, the table includes a resort Id. This is the FK. to the resort table.
If the Sunbay Resort 1002 is being defined, then the resort Id included in operation 1322 would be the same resort Id used to identify t:he Sunbay Resort defined in operation 1302. Note, clusters are not defined for sales only resorts.
In operation 1324, the user defines the cluster code which is a unique 25 code to identify the cluster within the resort. In operation 1326, the user defines a cluster name, e.g., "three bedroom." In operation 1328, the user provides a description of the cluster being defined. For example, the description may be "three bedroom units." In operation 1330, the user provides a display order which is the order to display values in a drop down 30 window. For example, if unit 101, 103, 102 and 104 are going to be presented in a window, then the display order presents them as 101, 102, 103 and 104 or as 104, 103, 102 and 101.
In main operation 1300c, the user defines any phases associated with the resort. A phase is simply a phase in a development. For example, phase 1 may include 20 units and is built first. Phase 2, includes 10 units and is built after phase I is complete. In operation 1332, the phase table includes a phase Id. This is the primary key of the phase table. The phase Id provides a linking mechanism to associate with other tables. In operation 1334, the phase table includes a resort Id. This is the FK to the resort table. If the IO Sunbay Resort is being defined, then the resort Id included in operation would be the same resort Id used to identify the Sunbay Resort defined in operation 1302.
In operation 1336, the user defines a phase code which is unique code to identify the phase within the resort. In operation 1338, the user names the IS phase currently being defined. In operation 1340, the user provides a description of the phase. In operation I342, the user provides the display order which is the order to display values in a drop down window.
In main operation I300d, the user defines the buildings associated with the resort. In operation 1344, the table includes a building Id. This is the 20 primary key of the building table. The building Id provides a linking mechanism to associate with other tables. In operation 1346, the table includes a resort Id. This is the FK to the resort table. If the Sunbay Resort"is being defined, then the resort Id entered in operation 1346 would be the same resort Id used to identify the Sunbay Resort defined in operation 1302.
25 In operation 1348, the user defines a building code which is a unique code to identify the building within the resort. In operation 1350, the user defines a building name. In operation 1352, the user provides a description of the building.
In main operation 1300e, the user defines the; floors associated with the 30 buildings defined in operation I300d. In operation 1354, the user defines a floor Id. This is the primary key of the floor table. The floor Id provides a linking mechanism to associate with other tables. In operation 1356, the user selects a building Id. This is the FK to the building table. In operation 1358, the user defines a floor code which is a unique code to define the floor within the building. In operation 1360, the user defines a floor name. In operation 1362, the user provides a description of the floor. In operation 1364, the user defines a display order which is the order to display values in a drop down window.
In main operation 1300f, the user defines a proximity which is used to determine points of interest that are located near tlhe resort. In operation 1366, the user defines a location which is a particular site or point of interest that is located near the resort, e.g., "Joe Louis Arena - the home of the Red Wings." In operation 1368, the user inputs a proximity which is a description that references the distance in miles to the specified location from the resort, e.g., "10 miles."
IS In main operation 1300g, the user defines a resort attribute. Exemplary resort attributes include a swimming pool and a gold course. In operation 1370, the user defines a code which is a unique code associated with the attribute. In operation 1372, the user names the attribute being defined, e.g., "swimming pool." And, in operation 1374, the user provides a description of the attribute.
Figure I4 illustrates the exemplary operations involved in setting up a room type for a HI resort. In operation 1405, the user defines a room type Id-which is the primary key of the resort table. In operation 1410, the user specifies the resort Id of the resort that the room type is being defined for.
In operation 1415, the user names the room type, e.g., "3 Ocean" 1010. In operation 1420, the user specifies the cluster Id for the cluster that the room type being defined belongs to, e.g., "3 bedroom" 1004. In operation 1425, the user provides a room type code which is a unique code that used to identify the room type. In operation 1430, the user provider a description of the room type, e.g., "three bedroom with a master suite and an ocean view."

In operation 1435, the user sets a flag that determines if the room type should be included in run of the house operations. Run of the house is a type or reservation that includes any room in the resort. The flag allows the room type to be included in ROH. In operation 1440, th.e user defines the lock-off status of the room type. Preferably, the allowable values for the lock-off status include non-lock-off, lock-off type, or part of a lock-off. A lock-off refers to a room that includes a door directly to an adjacent room wherein the two rooms may be sold or rented separately or together.
Figure 15 illustrates the exemplary operations involved in defining a room for HI, including: providing general room information in main operation ISOOa, providing the sleeping arrangements for the room in main operation 1500b, associating the room to sales inventory in main operation 1500c, providing occupancy dates for the room in main operation 15004, defining lock-off rooms in main operation 1500e, and providing room attribute information in main operation 1500f.
In main operation 1500a, the user defines general room information for the room being defined. In operation 1502, the user selects the resort that the room belongs to. In operation 1504, the user selects the cluster within the resort that the room is a part of. In operation 1506, the user selects the room type for the room being defined.
In operation 1508, the user defines a room number of the room, typically_ the same room number that is on the door to the room. In operation 1510, the user names the room, e.g., the "Blue Room" or the "Victorian Room." In operation 1512, the user provides a description of the room. In operation 1514, the user selects the building that the room is in. In operation 1516, the user selects the floor that the room is on. In operation 1518, the user selects the business entity that receives the revenue for the room.
In main operation 1500b, the user defines thE: sleeping arrangements for the room. In operation 1519, the user defines the number of beds in the room.
In operation 1520, the user defines the number of people that the room can accommodate in non-shared accommodations in individual beds. In operation 1522, the user defines the number of people that tlhe room can accommodate in shared accommodations. For example, for a room with a queen size bed and a twin size bed, the number of beds in the mom is two, the number of people that the room can accommodate in non-shared accommodations is two, and the number the room can accommodate in shared accommodations is three people In main operation 1500c, the user defines the SI entities associated with the particular room being defined. In operation 1524, the user selects the resort name, e.g., "Sunbay" 1002, of the associated sales inventory unit, if applicable. In operation 1526, the user selects the associated timeshare unit type, e.g., three bedroom 1104; if applicable. in operation 1528, the user selects the associated SI timeshare unit, e.g., unit 105 (1108).
In main operation 1500d, the user defines the occupancy information for the room. In operation 1530, the user defines the first day that the room can be occupied. Far a resort already in existence this date is often the same date that the HI is being defined. However, for a new resort, this date is the first date that the room will be available when the resort is completed. This date is also important for resorts that are not currently using the Tool but will begin using the Tool in the future. In operation 1532, the user defines the last day that the room can be occupied.
In main operation 1500e, the user defines the lock-off status of the room. A lock-off is a room that rnay be partitioned into smaller subdivisions with a lockable door separating the partitions. Referring to Figure l0, room 105 (1018) is a lock-off. In operation 1534, the user defines the room type that the room belongs to in the lock-off situation. :In operation 1536, the user defines the rooms that belong to the lock-off. Referring again to Figure I0, room i05A (1020) and room 1058 (1022) belong to the lock off.
In main operation 1500f, the user defines the room attribute information fox the room. In operation 1538, the user is presented with a display of room attribute categories. An example o~f a room attribute is view, e.g., "ocean" view and "gol#" view illustrated in Figure 10. Other attributes include, for example, ski-out, in-room hot tub, and private master suite. In WO 00/63794 PCTIIJSOO/i0492 operation 1540, the user selects the attributes that describe the attributes of the room. .For example, room 105 (1018) has an ocean view.
Figure 16 illustrates the exemplary operations involved in defining a unit type for SI. In operation 1610, the table includes a unit type Id. This is 5 the primary key of the unit type table. The unit type Id provides a linking mechanism to associate with other Si tables. In operation 1620, the table includes a resort Id. This is the FK to the resort table. If the SI for the Sunbay Resort 1002 is being defined, the resort Id included in operation 1620 would be the same resort Id used to identify the Sunbay Resort defined in 10 operation 1302. Note, the resort definition parameters defined in operations 1300 - 1374 for HI, discussed above with regard to Figure 13, are also utilized as part of the SI.
In operation 1630, the user defines a unit type code. The unit type code is a unique code for the unit type being defined and is unique across the 15 resort. In operation 1640, the user defines the unit type name which is the name given to the unit type being defined, e.g., "3 bedroom" 1104. In operation 1650, the user defines the unit type description which is additional detail for the unit type. In operation 1660, the user defines the square footage for the unit type which indicates the size of the unit type.
20 Figure 17 illustrates the exemplary operations involved in defining a unit for SI. Generally, in main operation 1700a general unit information is defined, in main operation 1700b the sleeping accommodations for the unit are defined, in main operation 1700c SI to HI mapping; information is defined and in main operation 1700d unit attribute information is defined.
25 Referring now to the general unit information main operation 1700a, in operation 1702 the resort that the unit is being defined for is displayed. In operation 1704, the user defines the unit type to which the unit belongs, e.g., "3 bedroom." In operation 1706, the user defines t:he unit number of the unit being defined, e.g., "105." In operation 1708, the user defines a name for the 30 unit being defined, e.g., "Presidential Suite." In operation 1710, the user provides a short description of the unit being defined.

In operation 1718, the user defines the check:-in day for the unit. In operation 1720, the user defines the square footage of the unit. The square footage is used when maintenance fees are calculated. In addition, the square footage is used in calculating the property taxes for the unit. Finally, in operation 1722, the user defines whether the unit wall have an escrow account associated with it the unit is attached to a contract during the contract inventory selection operations discussed below.
Referring now to the sleeping accommodation main operation 1700b, in operation 1724, the user defines the total number of beds in the unit. In operation 1726, the user defines the total number of people that the unit will accommodate in non-shared sleeping accommodations. Finally, in operation 1728, the user defines the number of people that the; unit will accommodate in shared sleeping accommodations. For example, if the unit includes a queen size bed in a master bedroom, two twin beds in a shared room, and a pull-out couch that sleeps two in the living room, then the total number of beds in the unit is four, the total number of people that the unit will accommodate in non-shared sleeping accommodations is four, and the number of people that the unit will accommodate in shared sleeping accommodations is six.
Referring now to the SI to HI mapping main operation 1700c, in operation 1730 the user defines the hotel resort, defined in main operation 1300a-1300g, that the unit is a part of. The selection of the resort dictates the choice of buildings in operation 1714. In operation 1732, the user defines the hotel room type, defined in operation 1400-1440, that this unit is a part o~
The selection of the resort in operation 1730, dictates the available room types in operation 1732. Finally, in operation 1734, the user selects the hotel room, defined in main operations 1500a - 1500f that the unit being defined is associated with. The selection of the room type in operation 1732, dictates the available rooms in operation 1734.
Referring to Figure 1, an exemplary HI to SI mapping configuration for the Sunbay Resort 135 is illustrated by reference numerals 1736 and 1738.
Reference numeral 1736 shows that room 101 (140). of Hi (1IS) is mapped to unit 101 (120)of SI (110) and reference numeral 1?:38 shows that room 102 of HI (1IS) is mapped to unit 102 (17f) of SI (110).
PRODUCTINVENTORY
S Product inventory ("PI") is created through the association of products to SI. PI cannot be defined until at least one product is defined and SI is defined. The definition of both products and SI is discussed above. PI
definition includes two hierarchical operations: product and SI selection and product and SI association. The product and SI selection operation requires the user to select the product and a set bf SI entities that may later be associated. Preferably, the product is selected via a. dropdown datawindow that will list all defined products for the organization. Preferably, the set of SI
entities are selected by specifying some definitive search criteria that will return all valid SI entities that match the criteria. From the list of SI
entities, the user is able to mufti-select specific SI entities to~ associate to the product.
After the product and SI inventory selection operations, the product and SI inventory selected are associated. The association operation creates the product inventory, i.e., the set of timeshare widget.. that may be sold. After the association process is initiated, the user is prompted for some requisite as well as some optional information. The optional in~Formation is dependent upon the type of product being associated as defined by its usage type. The optional information includes: definition of a product calendar, definition of maintenance increments, definition of time allocation details (fractions only), attribute initialization, and definition of point aliotnnents and point totals. The optional information may also be defined or modified at a later time.
Figure 18 is a flowchart illustrating the exemplary operations involved in product and SI entity selection. In operation 181)5, the user selects a previously defined product. Preferably, a list of all of the defined products for an organization is provided for the user to select from: Following product selection, the user defines a search criteria 1807 for the SI entities that may later be associated with the product.

In operation 1810, the user selects a resort. Preferably, the resort is the only mandatory search criteria that the user must enter. If no other search criteria is specified, then the search, in operation 1855 (discussed in more detail below), would search the resort selected for a.ny entities that match the product selected in operation 1805. For example, if the product selected included a two bedroom unit and the resort selected. is Sunbay Resort 1002, then the SI entities found in operation 1805 matching the search criteria may include unit 101 ( 1110), unit 102 ( 1112), unit 103 ( 1114) and unit 104 ( 1116).
The user, however, may further define the search criteria in operations 1815 -1850. If a product with a pure points usage type is selected in operation 1805, then the following additional search criteria will preferably not be available to the user.
In operation 1815, the user may select a unit type to search for. In operation 1820, the user selects the unit type, preferably from a list of available unit types. In operation 1823, the user may select a phase. In operation 1830, the user selects the phase, preferably from a list of available phases. In operation 1835, the user may select a building. In operation 1840, the building is selected, preferably from a list of available buildings. In operation 1845, the user may select a unit. In operation 1850, the unit is selected, preferably from a list of available units. T'he operations 1805-1850 are preferably presented in drop down datawindows.
For operations 1810 - 1850, the lists of avail',able search criteria is dynamically updated based on the previously selected search criteria. For example, after a resort is specified in operation 1810, the unit type, unit, phase, and building fields, associated with operations 1815-1850 are filtered to display only those entities that are associated with t:he selected resort. As a further example, if a two bedroom unit type 1106 is defined as a search criteria in operation 1820, the units available for selection iin operation 1850 are unit 1 O l ( 1110}, unit 102 ( 1112), unit 103 ( 1114) and unit 104 ( 1116).
The resort selection in operation 1810 is required because of the potential calendar conflicts between resorts. A connmon calendar is implied in WO 00163794 PCT/US00l10492 a single association operation because time is one dimension of defining product inventory. As a result, when association occurs, as discussed below, the set of selected SI entities must have consistent season definitions. This cannot be guaranteed unless all selected ST entities a.re linked to the same S resort. Each resort defines the season it will utilize in its calendar during the resort season calendar definition operations as discussed in conjunction with Figure 5.
After any of the search criteria definition operations 1810 - 1850, the user may start the search in operation 1855. If the user elects to begin the search, in operation 1860, the Tool searches for SI that matches the search criteria. If no SI is found that matches the search criteria then the user may specify a new search beginning anew in operation 1 E~00. If SI entities are found matching the search criteria, then the Tool returns a list of ali SI
entities matching the search criteria. The list displays the resort, unit type, unit, phase and building of the matching SI. In operation 1875, the user may associate the product selected in operation 1805 with any of the displayed SI entities. The user may, however, elect to cancel the association operation in operation 1880 and close the association window, not shown, in operation 1895.
Preferably, the same product cannot be associated to the same SI entity more than once. The same SI entity, however, may be associated to more than one product. For example, if product 1 includes a two bedroom unit type 1106 and product 2 includes unit l0I (1110), then product 1 may only be associated to the two bedroom SI 1106 once. However, unit 101 may be associated to both product 1 and product 2. If product 2 is sold, then unit 101 is automatically disassociated from product 1 by the Tool.
In addition, the product can only be associated to a selected SI entity if the product selected to be associated with the SI displayed in operation 1865 have time units that are complementary to one another. To be complementary, the time units of all products associated to SI entity must share a lowest common factor that is also a time unit of one of the associated products. The lowest common factor cannot represent the single dray time unit. For example, products with time units of 1, 2, 4, 6, 8, and 10 days or 3, 6, 15, and 21 days satisfy the lowest common factor requirement because all combinations of the time units are evenly divisible by 2 or 3 days respectively which are also both time units of the associated products. Products with time units of 1, 4, 6 and 5 12 days, however, cannot be associated to the same SI unit because the set does riot satisfy the lowest common factor requiremient. The lowest common factor is 2 which is not a time unit of any of the products. In addition, week based products may only be associated to units that have a specified check-in-day value, see Figure 5.
10 Figure I9 is a flowchart illustrating the exernplary operations involved in a product to SI association for non "pure paints" products. At the conclusion of the non pure points product association operations 1910-1970 as set of widgets available for sale is defined.
In operation 1910, the user may define a product calendar. Default 15 resort calendars are defined for each resort per defined time unit. The resort calendars specify the distribution of the particular calendar's time unit increments into groupings known as seasons as discussed above along with Figure 5, When a product is associated with a piece of SI, the user has the option of either using the default resort season definitions for the specified 20 product's time unit or a specific product season calendar may be created.
If the default resort season definitions are used then any changes made to these default season definitions at the resort level, discussed above along with Figure 5, will be validated against and applied to the products utilizing it.
However, if the product defines its own season definitions, then the product 25 specific calendar will be completely isolated from tlhe resort calendar.
Any changes made to the resort calendar will not be reflected in these products.
The product season definitions simply allow the us<;r to redistribute the time unit increments into different season groupings than was defined by the resort.
The product definition must still account for the full subset of resort defined 30 seasons and the product cannot add additional seasons to the definition. It is simply an increment redistribution process.

If the user opts to specify product season definitions, then the new product season definitions need to be accessible to the subsequent operations of non pure points product association because the. subsequent operations rely on the season definitions. The operations necessary to specify product season def nition are substantially the same as the operations discussed above in regard to the resort season calendar definition. see Figure 5.
In operation 1920, the user may define a maintenance increment for the product association. The space, e.g., unit 101 ( 1110), that defines the space dimension of each piece of product inventory must: be maintained on a regular basis. To facilitate the control of maintenance time requirements, the Tool will allow the user to define maintenance time increments that designate widgets of PI over the specified maintenance increments as unavailable for sale.
Moreover, the Tool allows the user to specify more than one increment as maintenance. The set of maintenance increments are defined per product per SI unit. However, a SI unit can be associated witlh multiple products that define their own set of maintenance increments. ~~s a result, a specific SI
unit's complete maintenance definition is the union of all product and SI unit defined maintenance increments.
If a product defines a specific time increment as maintenance, then all other products associated with the same SI unit inherit that specified time increment as maintenance also. Non pure points product associated includes a validation of the specified maintenance increments that ensures that no existing widgets of PI have been sold during the intersecting maintenance time increments.
The maintenance increments defined in operation 1920 are accessible to the subsequent operations of non pure points product association because the subsequent operations interact with the maintenance increments. Preferably, the maintenance increments are defined using a dropdown time increment user object. The dropdown time increment user object: displays all of the time increments for the PI being defined. To define the maintenance increments the user simply selects the time increment to define ass a maintenance increment.

WO 00/63794 . PCTIUS00110492 In operation 1930, the user may view unit allocation details. Products with a usage type whose contract unit allocation attribute, defined in operation 655, is "type" are defined as floating over the product inventory's space dimension. A product with a floating space dimension is sold by the unit type and not the specific units that were selected for the association. Therefore, although specific units are still specified during the association process they only serve as bounds to the floating capability of the product inventory within the unit type. The unit allocation details provides a summary of the floating bounds, e.g., a list of units available to the product, within a unit type for the . floating space products. The unit allocation details provide the user with the opportunity to confirm that the correct number of units within each unit type was selected for the association. The unit allocation details operation is purely an informational display, therefore no data modification is performed in this operation.
In operation 1940, the user may define time allocation details for fractional products. Products with a usage type vvhose sales time unit attribute, defined in operation 610, is 'fraction' have no predefined time dimension. Therefore, the time dimension is defined during this operation.
The product's usage type defines how many increments {fractions) need to be defined herein. This operation distributes the defined time increments into the various fractions. The fractions themselves can have both a fixed and a floating component. The fixed components will always be specified as a quantity of increments desired in each season. This guarantees that the owner will have rights to the specified quantity of time increments in the season although the specific increments within the season cannot be guaranteed.
Suboperations 1942 and 1944 of operation 1940, define the time dimension for fractional products. In operation 1.942, the user is presented with a plurality of fields presenting data associated with fractional products, preferably including: the name of the product being associated, the sales time unit associated with the product's usage type, the sales increment associated with the product's usage type, the number of increments in the year that are WO 00163794 . PCT/USOOI10492 accounted for in a fraction definition as a fixed component, the number of increments in the year that are accounted for in a i:raction definition as a floating component, the number of increments in t:he year that are accounted for in a fraction definition as either a fixed or floating component, the name of the fraction far the specified product/inventory association, the description of the fraction for the specified product/inventory association, the number of fixed increments that is defined for the specified firaction, the number of floating increments that is defined for the specified fraction, a color coded graphical representation of every increment in the year according to their season's color, the name of the specified season in the appropriate calendar, the number of floating increments in the specified season as defined for the specified fraction, the number of floating increments in the specified season defined for the other fractions, and the number of increments in the specified season that are not defined as either a fixed or floating increment in any I S fraction.
The user then utilizes the information presented in operation 1942 to define the current fraction in operation 1944. In operation 1944, the user selects the name of the fraction that will be defined. The user then selects from the color coded graphical representation of increments, the fixed increments that will be associated with the current product. Defining the fixed increments for the product causes any field effected by the definition to be updated: Accordingly, the floating increments far the fractional product are updated. If the user is satisfied with the fractional product def ned the user may save the product. Figure 6b shows a table urith four fractional products.
For example, the time dimension for the fraction<~l product "Fraction 1" 632, is fixed weeks 1-6 (634), four floating weeks during the High Season and three floating weeks during the Low Season (636).
In operation 1750, the user may initialize the pricing and paints attributes for the product. The Tool tracks and vmaintains three prices for each widget of product inventory; the drop price, price, and cost. The drop price is the minimum price at which the widget of product inventory can be sold. The WO 00163794 . PCT/US00110492 price is the actual price that the widget of product: inventory should be sold for. The actual cost of the widget of product inventory is also tracked and maintained by the Tool.
The Tool also tracks and maintains a point;> value association for each widget of product inventory that is derived from a product usage type with a 'sales points' flag of 'Y' defined in operation 630 of Figure 6. Otherwise, the user will not be required to initialize points. Generally, the points value attribute allows the system to sell the product inventory as the widget itself (space/time) or by a points specification where a specified points value is resolved into actual product inventory.
The ability to specify an initial value for these pricing and points attributes during the association process provides the user with an efficient way to define product inventory: Although, the situation is probably rare that the initial pricing and points values specified are appropriate for all product inventory that will be generated from the association; the capability is provided by the system in case the user wants to take advantage of its existence. The pricing and points may also be defined in operations associated with the inventory management navigation module as discussed below.
In operation 1960, the user may initialize inventory dates attributes.
The Tool tracks and maintains two dates associated with each piece of product inventory (widget): the "inventory first date available for sale" ("IFDS") and the "inventory first use date" ("IFU"). The IFDS~ is the first date that the piece of product inventory can be sold. The IFU similarly determines the first date that the piece of product inventory is available for use by a member or owner.
In operation 1970, the user may initialize 'the business entities. The Tool tracks and maintains four business entity associations for each piece of product inventory. These four business entities are the seller, the association, the servicer, and the club. The seller determines the business entity that serves as the seller of the associated widget. The seller owns the accounts receivable ledger and the contract sales ledger. The accounts receivable ledger tracks revenues and expenses associated with a timeshare. The contract sales ledger w0 00163794 . PCT/US00110492 tracks contract revenues and expenses. The various ledgers discussed herein are, generally, accounting ledgers that are defined in an account administration module. The account administration module is not discussed in detail herein, however, one of ordinary skill in the art would b~e able to implement the 5 accounting ledgers. The association determines 'the business entity that serves as the association for the widget. The association bills and collects the maintenance fees and owns the maintenance fee aiccount receivables ledger.
The maintenance fee accounts receivable ledger i;racks maintenance fee receivables. The servicer determines the business entity that is associated with 10 each widget as -its servicer. The servicer bills and collects reservations fees and owns the miscellaneous member services accounts receivable and accounts payable ledgers. The accounts payable ledger tracks members account balances. The club determines the business entity that manages the points activity for the widget. The club owns the points audit ledger and the points 15 management subsidiary ledger.
Figure 20 illustrates the exemplary operations involved in a "pure points" product association. In operation 2010, the user defines the point allotments for the pure points product being associated. A pure points product can only be associated to resort SI entities. As a~ result, the resort must define 20 the total points it will obligate to timeshare sales., the amount of those total points that must be set aside for maintenance obligations, and the schedule of how many points become available at what time. The total points for the resort defines the upper bound for the defined allotments. At any point in time, the actual total points available for timeshare sales is determined by the 25 valid allotments less the maintenance points, rather than the total points less the maintenance points.
In operation 2010, the user is presented v~rith a plurality of fields presenting data associated with allotments, preferably including: the total number of points that the resort has defined for sale, the total number of points 30 that the resort has set aside as maintenance points, the difference between the total points and maintenance points, i.e., the nunnber of points available for sale, the name of the specified allotment, the amount of points that will be brought on-line as part of the allotment, and the date that the specified allotment becomes available for use. The user may then add, delete or modify the existing allotments.
S In operation 2020, the user may define the pricing of the pure points product being associated. Pure points products are sold strictly as points.
The owner specifies the number of points that is desired in some combination of valid points packages. The exact combination of points packages used to meet the desired points value will directly affect how the sate is priced. These points packages are set up with the pure points praduct during the product definition process, as described above in regard toy operations 835 - 845 of Figure 8. However, the pure points product cannot be priced until an association is made to a resort SI entity.
Similar to the pricing mechanics for inventory-backed products, i.e., non pure points products, the Tool tracks and maintains three prices for each points package defined for the product: the drop price, price, and cost. The drop price is the minimum price that the paints package can be sold. The price is the actual price that the points package should be sold for. The actual cost of the points package is also tracked and maintained by the system.
In operation 2030, the user may define the business entities related to the product inventory being associated. The Tool tracks and maintains four business entity associations for each piece of product inventory (widget).
These four business entities are the seller, the association, the services, and the club. The seller determines the business entity that serves as the seller of the associated widget. The seller owns the accounts receivable ledger and the contract sales ledger. The association determines the business entity that serves as the association for the widget. The association bills and collects the maintenance fees and owns the maintenance fee account receivables ledger.
The services determines the business entity that is associated with each widget its services. The services bills and collects reservations fees and owns the miscellaneous member services accounts receivable and accounts payable WO 00/63794 . PCT/US00/10492 ledgers. The club determines the business entity that manages the points activity for the widget. The club owns the points audit ledger and the points management subsidiary ledger.
CONTRACT INVENTORY SELECTION -- SALE
When a timeshare widget from PI is purchased, the user utilizes the contract inventory selection operations illustrated in Figure 21 to verify the SI
availability of the widget that is being purchased. Note, "contract" as used herein refers to the rights in a widget that a timeslhare owner has purchased.
IO The contract inventory selection operations are preferably available to the user when a new contract is created so that inventory availability is confirmed as soon as possible. Generally, contract inventory selection includes the following operations: entering search criteria, obtaining a list of inventory that matches the search criteria, selecting items to apFvly to the contract, and removing the selected items from general sales availability. The overall contracting process is performed outside the Tool.
Figure 21 illustrates the exemplary operations involved in contract inventory selection. Inventory selection is preferably defined by the user using drop-down data windows. In operation 2102, the user selects the resort that the contract owner is searching inventory for. In operation 2104, the user selects the product that the contract owner is searching inventory for. The resort and product selection operations 2102 and 2144 are preferably mandatory. The following operations 2106 - 21;0 further define the search criteria. However, operations 2106 - 2120 are preferably optional.
In operations 2106 and 2108, the user ma:y select the phase that the contract owner is searching inventory for. In operations 2110 and 2112; the user may select the building that the contract owner is searching inventory for.
In operations 2114 and 2116, the user may select the unit that the contract owner is searching inventory for. And, in operations 2118 and 2120, the user .
may select the week that the contract owner is searching inventory for.
Operations 2102 - 2120, define the search criteriia.

In operation 2122, the Tool searches for inventory based on the search criteria. The inventory matching the search criteria is displayed in operation 2124. An exemplary window illustrating the resulia of a search is provided in Figure 21a. Numerous attributes associated with t;he inventory are displayed, including: the resort 2124a, the phase 2124b, the building 2124c, the unit 2124d, the increment 2124e, the frequency 2124f, the availability 21248, the owner first use date 2124h, and the quantity for purchase 21241.
In operation 2126, the user selects the inventory to associate with the contract. Referring to Figure 21 a, the selected inventory is "ProductX"
(2126a) which is a "fixed/fixed" product including; "unit 201/weekl" at "Res 1." After selecting the inventory in operation 2126, the user may define an add-on membership in operations 2128 and 2130. The add-on membership operations 2128 and 2130 are substantially similar to operations 900 - 960a described above. In addition, the user may add a points package in operation 2132. Adding a points package includes selecting a points package to add in operation 2134 and selecting a points purchase package quantity in operation 2136. The quantity refers to more than one pointa package. For example, if two 1000 paints packages are selected, then 2000 total points are added.
In operation 2138, the user defines the owner first use date which is the first date the owner can use the widget. In operation 2140, the user defines the quantity for purchase. Finally, in operation 2144, the user may release the inventory to the contract. If the inventory is released, the inventory released is no longer available sales inventory.
The contract inventory selection operations discussed above are subject to various selling rules and selling preference that will be applied whenever a use attempts to search for widgets based on specified inventory. Selling rules are determine what inventory can be sold. Fop example, a rule selling rule can require that for every five 1 bedrooms that are sold a three bedroom must be sold. Accordingly, if the sixth 1 bedroom is searched for before the first three bedroom is sold, then the search will not return a match. Selling preferences is the order that the inventory is presented for selection. For example, if one match is from a new phase and four matches are from an older phase, then the older phase matches may be presented first in order to sell out the old phase before beginning to sell the new phase.
INVENTORY MANAGEMENT NAVIGATION MODULE
The inventory management navigation module (hereinafter "IMNM") is a central launching point for the operations discus:~ed herein. The IMNM
provides the user with three views of the various inventory systems: HI, SI
and PI. The HI view will allow the user to see all of the defined HI entities, IO e.g., resort, cluster, room type, and room, in a hierarchical treeview display.
Likewise, the SI view will allow the user to view all of the defined Si entities, e.g., resort, unit type, and unit, in a hierarchical treeview display.
Finally, the product view will list all of the defined products in the system and their product to SI associations in a treeview. The three views provide the user ZS with all requisite views of the inventory systems in an efficient and convenient manner. The IMNM also supports all functionality of defining and maintaining products, HI, SI and PI as described herein. The user will able to view any of the HI, SI or PI from the IMNM while modifying any of the HI, SI or PI at the same time.
20 The IMNM includes three main menu selections: inventory management, product, and inventory: The inventory management menu allows the user to select the exact view of inventory that is desired or toggle through the various views to determine the best view for the current action. In addition, all other operations of the Tool may be accessed through this menu.
25 The product menu allows the user to define the various products that are supparted by the Tool as described above with regard to Figures 3 - 9. The product menu also allows the user to initiate the product to SI association operations as described above with regard to Figures 18 - 20. Recall, product to SI association creates the PI widgets that are :.old and hence required to 30 support timeshare functionality. The inventory menu allows the user to interact with the various inventory entities - HI, SI and PI. Finally, the inventory menu also allows the user to initiate blocking and overbooking which are discussed in more detail below.
The following windows illustrate the preferable implementation of the three main IMNM menu selections. In addition, the windows shown in Figures 5 22, and 22a - 22g exemplify the preferable GUI implementation of the various operations described herein arid illustrate the look and feel of the Tool. Of course other GUI implementations are possible.
Figure 22, illustrates the main menu window for the Tool and the application. Many of the operations and resultant inventories discussed herein 10 are used by the various modules of the application shown in the main menu screen. The inventory management icon 2210 launches the IMNM. Figures 22a - 22g are exemplary window screen shots that are accessible through the IMNM. Figure 22a is the toolbar that is first viewed when the IMNM is accessed. The toolbar includes an inventory management drop down menu 15 2210a, a product drop down menu 2220a, an inventory drop down menu 2230a, a worklist drop down window 2240a and a help drop down menu 2250a.
The contents of the inventory management drop down menu 2210a are illustrated in Figure 22b. Many of the various operations discussed herein are 20 accessible from the inventory drop down menu. For example, the HI 2210b, SI
2220b, PI 2230b, resort calendar 2240b and resolved usage rights 2250b operations, amongst the others shown in Figure 22b, are all accessible from the inventory management drop down data menu 221.Oa.
Figure 22c, illustrates the window that is presented if the HI link 2210b 25 is selected in the inventory management drop down menu 2210a. The HI
window includes a list of the defned hotel inveni:ory 2210c. The user may select one of the defined HI at which time associated attributes 2220c are also displayed. The associated attributes includes the code afthe resort 2230c and the name of the resort 2240c, amongst other attributes, as defined in main 30 operations 1300a - 1330g discussed in conjunction with Figure 13. In WO 00/63794 . PCT/US00/10492 addition, the HI window includes various operational links 2250c along the top of the window.
Figure 22d, illustrates the window that is presented if the SI link 2220b is selected in the inventory management drop down menu 2210a. The SI
S window includes a list of the defined sales inventory 22104. The user may select one of the defined SI at which time associated attributes 22204, such as resort information 22304, are also displayed. Like the Hi window, various operational links 22404 are provided along the top of the window.
Figure 22e, illustrates the window that is presented if the PI link 2230b is selected in the inventory management drop down menu 2210a. The PI
window includes a list of the defined product inventory 2210e. The user may select one of the defined PI at which time associated attributes 2220e, such as the usage type 2230e, are also displayed. Like the: HI and SI window, various operational links 2240e are provided along the top of the window, including a I S link to the resort season calendar, and a link to any defined product calendars.
Figure 22f illustrates the product drop down menu 2220a. The product drop menu 2220a includes a link 22 i Of to the timeshare product definition main operations 300 - 360, a link 2220f to the miscellaneous product setup operations (discussed directly below -- need to discuss), a link 2230f to the product calendar operations, and a link 2240 to the product inventory association discussed with regard to Figures 18 - 20.
Miscellaneous products are products that dlo not fit into spaceltime or points category of products. However, miscellaneous products can be defined for sale and inventory control by quantity of products in existence. For example, golf club sets or stand-alone gym memberships are potential miscellaneous products.
Figure 22g illustrates the inventory drop down menu 2230a. The inventory drop menu 2230a includes numerous links to various operations, especially the hotel and sales inventory definition operations discussed in conjunction with Figures 10 - 17. The links to operations accessible through the inventory menu drop down menu 2210g include: a link 2210g to the resort defnition operations 1300 - 1372, a link 2220g to ithe unit type definition operations 1610 - 1660, and a link 2230g to the unit definition operations - 1738.
$ RESOLVED USAGE RIGHTS
An owner of a timeshare widget is granted nights to specific intersections of time and space depending upon the usage rights of the specific widget that was purchased. As noted above in conjunction with the contract inventory selection operations, after a timeshare widget is purchased, the owner has a "contract." The particular widget purchased is associated with a contract in the contract inventory selection operations. Every widget that is purchased includes usage rights, defined in operations 700 - 799 that are defined during the product definition operations, as discussed above along with Figures 3 - 9. Usage rights generally define a set of attributes including when an owner can make a reservation, when an owner can use the timeshare inventory, and the type of accommodation that is provided. The attributes are defined in terms of expressions that serve as a general rule for the specified product. However. the expressions used to define. the attributes will resolve to different values for each piece of sales inventory that is used to create product inventory through the product to SI association operations discussed above along with Figures 18 - 20. Specifically, the reservation and usage window attributes, defined in operations 720-73 $, of a usage right will change according to the implied dates of the specific product inventory widget's time increment, i. e. , week 1.
2$ The generation of resolved usage rights from the usage rights provides the owner with the ability to actually use their purchases. However, the discrete operation of resolving usage rights is sometimes not sufficient for the owner to gain access to all of his timeshare rights. This is especially true for owners of paints-based products. For these point, owners; other points accounting sub-processes are executed prior to their rights becoming effective and usable. In particular, the operation of resolv'r.ng usage rights must also WO 00!63794 . PCT/US00/10492 execute some or all of the following points accounting tasks if the associated product inventory being resolved is points based: iinitialize club points;
allocate points for new owners or members, allocate incentive points, allocate points for existing owners or members, expire points, and create extended exchange transactions. Furthermore, to ensure the: accuracy of the various points accounts, the following processes will also be performed: usage period end adjustment and cancel contract points.
The usage rights resolution (hereinafter "UI~R") operation will be executed for all "active" contracts, i.e., for all exi;>ting timeshare widgets that have been purchased and are still active, and contracts that have been canceled after the last time the operation was executed. Furthermore, "active"
contracts can be classified into two types, those that are existing (reached the requisite status prior to the last execution of the URR operation) and those that are new (reached the requisite status after the last time the URR operation was executed). Thus, on a scheduled recurring basis, tthe URR operation will execute and query the Tool for all appropriate contracts. All qualifying contracts will be processed in the URR operation. The URR operation executes for each qualifying contract individually and the set of qualifying contracts will also be processed together. Depending upon the status of each individual contract, one or more of the sub-processes listed above will be executed. in addition, the user may initiate the URR operation as an immediate action from a manual triggering mechanism.
Figure 23 illustrates the preferably operations involved in the URR
operation. The URR operation determines all contracts that have attained the 2S required user defined contract status and execute the required operations to provide the contract owners with rights to use their purchased timeshare inventory. For each contract, the URR operation executes the following operations as part of the overall URR operation.
In operation 2305, usage rights are resolvE;d. This operation resolves the usage rights specified during the product definition operations to resolved usage rights that will afford the owners with the ability to use the purchased w0 00/63794 PCT/US00/10492 timeshare inventory. The Tool will determine the suet of product inventory widgets associated to the qualifying contract. For each product inventory widget, its set of usage rights will be resolved to a corresponding set of resolved usage rights {"RUR"). The RUR will have a logical relationship amongst themselves as determined by their relative order and the logical operators of the underlying usage rights, defined in operation 755.
Each usage right will resolve to potentially one or more RUR. For example, non-contiguous seasons and fractions may resolve to a set of RURs instead of a single RUR. The many usage rights treat are resolved out of a single usage right record have an implied logical relationship to the set as a whole. The exact logical .relationship will depend upon the product inventory's associated usage type attributes. Specifically, the sales time allocation, defined in operation 625, and contract time allocation, defined in operation 660, attributes will determine whether the one to many RUR have an implied AND
or OR logic amongst the entire set. The table illustrated in Figure 23a, illustrates the different possibilities.
The row referred to by reference numeral 2,310a represents a product inventory widget from a fixed time product. The date keywords "fixed or floating" and "increment," defined by the sales time allocation operation 625 and contract time allocation 660 respectively, will. always resolve to a single date so ail resolutions will be one to one.
The row referred to by reference numeral 2320a is a product inventory widget from a floating time product. The date keywords "fixed or floating"
and "season," defined by the sales time allocation operation 625 and contract time allocation 660 respectively, will potentially return a set of dates, one for each non-contiguous range of the increments that comprise the season. As a result, the owner has rights to use an increment of duration "n" days as defined by its time unit anywhere within the set of date ranges that were resolved from the season's contiguous time increments. Thus; the logical relationship is an OR.

The row referred to by reference numeral .2330x; is a product inventory widget from a fractional product. Similar to the floating time product example above, the date keywords "fraction" and "increment" will potentially return a set of dates, one for each contiguous set of fixed time increments that 5 comprise the fraction and one for each floating increment that comprise the fraction. Fractional product owners, however, have a right to use the entire fraction and not just a single increment bounded by the fraction definitions.
As a result, the owner will have rights to all of the re solved usage rights records in this case. Thus, the logical relationship is an AND between all fixed 10 increment resolutions and the set of floating increment resolutions.
However, the set of floating increment resolutions will have an implied OR relationship in the case of noncontiguous season definitions.
The row referred to by reference numeral 2340x, is a pure points product. Pure points usage rights imply usage across all resorts in the 15 organization. However, the RURs can only be used at one of the many resorts that may exist within an organization. The one resort that the right is used against is completely at the discretion of the ownE,r. All other cases detailed above in the table of Figure 23a are preferably invalid combinations and are not defined within the Tool.
20 Ali resolved usage rights or set of resolved usage rights will maintain the logical relationship, defined in operation 755, that exists between its spawning usage rights records. For example, consider two usage rights (UR1, UR2) where the logical relationship is "URl AND UR2." If UR1 resolves to "RUR1 OR RUR2" because the product inventory is from a floating product;
25 UR2 resolves to "RUR3 OR RUR4." Then the final logical expression of the entire set of resolved usage rights is (RUR1 OR RUR2) AND (RUR3 OR
RUR4). A RUR Boolean expander algorithm will then simplify this set of resolved usage rights records to a more intuitive representation of sets of mutually exclusive retards. For the above example, the simplified expression 3 0 i s : (RUR 1 AND RUR3 ) OR (RUR 1 AND RUR4) OR (RURZ AND RUR3 ) OR
(RUR2 AND RUR4).

In operation 2310, the RUR operation initializes club points. A club is a group of affiliated resorts that provide the ability for their owners to exchange with one anther. Club points are essenltially the same as the "points"
discussed herein. The club point initialization operation allocates total points available to the club for the defined usage period and records them in the user-defined accounts in the points audit ledger ("PAI,"). The PAL keeps track of the use of club points in a debit credit fashion. Entries are posted to: Debit the specified "asset" account and Credit the specified "reserves" account. The "asset" account, which does not carry a status, is created by the Tool when the ledger is set up in the member services module; therefore, the account will never become inactive. Note, the member services module is not discussed in detail herein. The "reserves" account, however, is user-defined and carries a status. If the "reserves" account associated with the club is inactive, then an error will need to be logged to the scheduler log files and the entire RUR
operation will be rolled back to its previous states. Likewise, if a "reserves"
account is not associated with the club, then an error will be logged to the scheduler log files and the entire RUR operation for the current contract will be rolled back to its previous states.
In operation 2315, the RUR operation allocates points to new owners or members. As new sales occur, points need to be allocated to their ownerlmember accounts in the points management subsidiary ledger ("PMSL") that is defined in the member services module and tracks each members available points. New members/owners are defined as any new purchasers since the last allocation that have usage rights within the defined usage period.
The allocation process allocates points to the appropriate accounts in the PMSL and the liability and reserves accounts in the PAL. Entries are posted to: allocate points to each new owner/member account in the PMSL, credit a designated "liability" account in the PAL for usage period owner/member "regular points" liability, debit a designated "resf;rves" account for owner/member usage period liability. The "liability" and "reserves" accounts are user-defined and carry a status. If the accounts) are inactive, then an WO 00!63794 PCT/US00/10492 error will need to be logged to the scheduler log files and the entire RUR
operation for the current contract will be rolled back to its previous states.
If a "reserves" and/or "liability" account is not associated with the club, then an error will need to be logged to the scheduler log files and the entire RUR
allocation process for the current contract.will be rolled back to its previous states.
In operation 2320, the RUR operation allocates incentive points.
incentive points are given to members as an incentive to purchase a timeshare.
The following entries are posted: allocate points t:o the ownerlmember points account in the PMSL; credit a designated "liability" account in the PAL for usage period owner/member liability; and debit a designated "incentive reserves" account. The "liability" and "incentive reserves" accounts are user-defined and carry a status. If the accounts) are inactive, then an error will need to be logged to the scheduler log files and the entire RUR operation for the current contract will be rolled back to its previous states. If an "incentive reserves" and/or "liability" account is n.ot associated with the club, then an error will need to be logged to the scheduler log files and the entire RUR operation for the current contract will be rollled back to its previous states.
In operation 2325, the RUR operation allocates points to existing owners or members. The Tool will determine all contracts in the Tool that have a points value associated with them. These qualifying contracts will be those with product inventory that have associated. resolved usage rights with points accommodations. The allocation process allocates points to the appropriate accounts in the points management subsidiary ledger (PMSL) and the liability and reserves accounts in the PAL. Entries are posted to: credit each owner/member points account in the PMSL; credit a designated "liability"
account in the PAL for usage period owner/member "regular paints" liability;
debit a designated "reserves" account for owner/~member usage period liability.
The "liability" and "reserves" accounts are user-defined and carry a status.
If the accounts) are inactive, then an error will need to be logged to the WO 00/63794 . PCTlUS00/10492 scheduler log files and the component existing ownerlmember allocation process for the current contract will be rolled bacl~; to its previous states.
If a "reserves" and/or "liability" account is not associated with the club, then an error will need to be logged to the scheduler log fiiles and the component existing owner/member allocation process for the current contract will be rolled back to its previous states.
In operation 2330, the RUR executes the expires points operation. The expire points operation is used periodically to process transactions, which adjust accounts for points that have expired. When points are allocated, they are given an effective date and expiration date, which define the period of time for which they are valid and must be used. The following entries are posted for this process: debit each owner/member or exchange company account in the PMSL by the number of expired points as of the date the process runs;
debit the appropriate "liability" accounts; and credit the "asset" account used IS to track total points for the specified usage period in the PAL. When the operation runs, each owner/member or exchange company account in the PMSL will have a transaction posted to decrease it by the number of expired points. Points will be reversed with an "Expired"' transaction type based upon the expiration date entered when the transaction occurred to increase the account through allocation, rent, borrow, bank, etc. The "asset" account, which does not carry a status, is created by the system when the ledger is set up; therefore, the account will never become inactive. The "liability"
account, however, is user-defined and carries a status. If the "liability" account associated with the club is inactive, then an error will be logged to the scheduler log files and the component expire points process will be rolled back to its previous state. If a "liability" account is not associated with the club, then an error will be logged to the scheduler log files and the component expire points process will be rolled back to its previous state.
In operation 2335, the RUR operations adjusts the usage period end.
At the end of each usage period specified for the club defined in the PAL, the PAL account balances must be adjusted to close the period. The following entries are posted to: debit the points "reserves" accounts to zero the points balance for remaining "unused" or "unallocated" paints for the usage period;
and credit the points "asset" account that tracks the total points available throughout the use period for the amount of the current debit balance. The "asset" account, which does not carry a status, is created by the system when the ledger is set up; therefore, the account will never become inactive. The "reserves" account, however, is user-defined and carries a status. If the "reserves" account associated with the club is inactive, then an error will be logged to the scheduler log files and the component usage period end adjustment process will be rolled back to its previous state. If a "reserves"
account -is not associated with the club, then an error will be logged to the scheduler log files and the component usage period end adjustment process will be rolled back to its previous state.
In operation 2340, the RUR operation executes the cancel contract points operation. The system will determine the se;t of contracts that have been canceled since the last executian of the process. This set of freshly canceled contracts will serve as the driving factor of the cancel points component process. When a contract is canceled, all point transactions in the owner/member account for that contract with the Exception of a "Rent" -transaction needs to be reversed. The transaction:. in the PAL that are tied to that contract also needs to be reversed.
In operation 2345, the RUR operation creates extended exchange transactions. Extended exchange transactions refer to a two phase expiration of points. At the end of each usage period, a member's points expire.
However, for some organizations these points don.'t truly expire completely from the system. The member's expiring points are transferred from allocated points to extended usage points. Extended usage points have a life span defined by a business policy. They are valid for the period defined by the business policy, starting on the date the allocated points expired. These extended usage type of points may have restricted usage capabilities depending upon how the business policies have been defined. This component process is probably triggered by the component expire points process to ensure that all extended usage occurrences are properly handled by the system.
The Tool also allows split definitions. A split definition allows a member to change their resolved usage rights into many resolved usage rights 5 with different check-in-days and length-of stays. hor example, a float/float widget based on a "week" time unit might be divided into two float/float widgets with the total time for both widgets equaling one "week." A split is defined at the resort and time increment association. For each association, the user may define many split types, with each split type having a list of valid 10 check-in-days and length-of stays that total the time increment.
HOTEL INVENTORY CONTROL AND RESERVATION MODULE
Hotel inventory control manages the usage of hotel inventory for purposes of reservations and inventory blocks. As discussed above with regard 15 to Figures 10 - 17, HI is setup and maintained at lour levels: resort, cluster, room type and room. A resort is defined in the Tool as the physical location of the building or buildings that house the physical inventory available for rent. A
cluster is defined in the Tool as a grouping of room types based on similar pricing. A room type is defined in the Tool as a l;rouping of rooms with 20 similar attributes. For example, all two bedroom rooms or all ocean view rooms may be grouped together as a room type. Finally, a room is defined in the Tool as the physical piece of inventory availalble for rent.
The Tool includes a reservation system that allows an agent to confirm reservations at all levels of defined inventory. Rf;servations may be confirmed 25 at four different levels: run of house ("ROH"), rum of cluster ("ROC"), run of type ("ROT") or room. A ROH reservation means that a guest~is given confirmation that they will have a room in the resort available at check-in time.
The guest does not require any special room attributes, e.g., roam type, or any special price attributes, e.g., cluster. A ROC reservation means that a guest is 30 given a confirmation that they will have a room in an agreed cluster, i.e., pricing group, at check-in. The guest does not require any special room attributes. A ROT reservation means that a guest is given confirmation that they will have a room in an agreed upon room type; at check-in. Finally, a room reservation means a guest is given confirmation that they will have the requested room at check-in. The reservation agent typically makes reservations at the highest level (ROH) in order to~ try and accommodate future customers requesting reservations at a more speciiac level such as ROT. This strategy maximizes hotel revenue and customer satisfaction by not arbitrarily assigning customers to rooms with specific attributes such as ocean view when they do not desire the view.
The hotel inventory control and reservations module provides guaranteed sustained availability. Sustained availo~.bility is the number of consecutive nights that a particular room is available. Sustained availability is an improvement over other reservation systems that only provide daily availability. The following example further explains sustained availability.
Figure 24 illustrates an exemplary availability chart for rooms 101, 102 and 103 for three nights January 1, 2 and 4. A "Y" signifies that the room is available for the particular date and a "N" signifiers that the room is not available for the particular date. Daily availability for a requested three night stay, 1BR (one bedroom) room type, starting January 1 is two. Meaning, on any given night there are at least two rooms available. However, the sustained availability for the same request is zero because a guest will not be able to stay in the same room for all three nights. Preferably, sustained availability is implemented using a recursive technique.
The hotel inventory control and reservation module also provides for the setup and maintenance of overbooking and the setup and maintenance of blocks. Overbooking allows the reservation agent to make more reservations than there are rooms available to fulfill guest requests. Overbooking amounts are defined at all levels except the actual rooms. Overbooking relies on cancellations so that there are not more guests than rooms available.
Figure 25 illustrates the exemplary operatiions involved in defining overbooking amounts. In operation 2510, apera~tion 2520, and operation 2530, the user selects the resort, cluster and room type respectively to define overbooking amounts for. In operation 2540, the user selects the beginning date of a range of time that the overbooking limit is going to be assigned to.
In operation 2550, the user selects the end date ferr the range of time that the overbooking limit is going to be assigned to. In operation 2560, the user sets the overbooking limit for the range specified. Finally, in operation 2570 the user may select to exclude particular dates from tlhe range for which the overbooking limit will not be applied.
The tables presented in Figures 25a, 25b, 25c, 25d and 25e illustrate how the overbooking limits affect availability. Fi3;ure 25a illustrates the current availability for an exemplary resort "R," v~ith two clusters "CL 1"
and "CL2," with each cluster having two room types "RT1" and "RT2." ROH
availability is illustrated in the Figures as a row with only the Resort defined, e.g., the row with reference number 2510a. ROC availability is illustrated in the Figures as a row with the resort and cluster defined, e.g., the row with reference number 2520a. The ROT availability is illustrated in the Figures as a row with the resort, cluster and room type defined, e.g., the row with reference number 2530a. All availability number:. roll-up to the resort Level.
For example, if a reservation is made at the ROT level, then the ROT, ROC
and ROH availability numbers decrement by 1.
The following three scenarios refer to Figures 25a - 25e to illustrate the effect of overbooking on availability. Referring to Figure 25a, in scenario one, when a reservation is requested for RT2, then RTZ has 1 available, C 1 has 1 available, and R has two available therefore no overbooking rules are required because there is availability at all levels. Accordiingly, RT2 is decremented, is decremented and R is decremented. The resulting availability is illustrated in Figure 2c.
In scenario two, a second reservation is requested for RT2. RT2 is no longer available because it was reserved in scenario one. Accordingly, overbookiing for RT2 is checked. Referring to Fiigure 2b, RT2 may be overbooked by 2. Therefore, the availability for C 1 is checked. C 1 is not available. Referring to Figure 2b, C1 may be overbooked by 2. Therefore, the availability for R is checked. R has availability, therefore, the reservation for RT2 is taken and RT2, C1 and R are decremented.. The resulting availability is illustrated in Figure 25d.
In scenario three, a reservation is requested for RT3. Referring to Figure 25b, RT3 is not available. Therefore, referring to Figure 25b, the overbooking limit for RT3 is checked. RT3 may 'be overbooked by 2, therefore the availability of C2 is checked. Referring to Figure 25d, C2 is not available, therefore the overbooking limit far C2 :is checked. C2 cannot be overbooked so request cannot be granted unless a supervisor override is granted. If supervisor override is granted, then the availability for R is checked. Referring to Figure 25d, R is nat available, therefore check the overbooking limit for R. R can be overbooked, therefore take the reservation and decrement R, C2 and RT3. The resulting availability is illustrated in Figure 25e. All reservations at this point will require supervisor override because the resort limit for overbooking is set to 1 which was used.
Blocking removes inventory from general availability into a special blocked availability. The blacking functionality is primarily used to guarantee availability to particular guests such as timeshare owners, conferences and marketing promotions. Blocking may also be used to restrict certain pieces of inventory from being used by anyone if, for example, the piece of inventory is scheduled for remodeling. Blocks are definable at any reservation level, including ROH, ROC, ROT and room.
A block includes a block definition and the assigned inventory. The block definition defines the resort the block is defined at, a unique block code for the resort, a description and block expiration information. Inventory can be assigned at any level a reservation can be made, ROH, ROC, ROT; or room level. Each assignment of inventory will determine if the block will contain sustained or daily availability and the amount of :inventory to block. The actual amount of inventory to be blocked depends on a block number, an authorize number, and a forecast number entered by the user at inventory is assigned to the block. The block number is the actual amount of inventory to remove from general availability. The authorize number is the maximum number of reservations that can be reserved against the block. The forecast number is a best guess entered by the user as to what will be actually used.
Figure 26 illustrates an exemplary window implementation for assigning inventory to a block. The window includes the following drop down datawindow ("DDDW") fields utilized by the user to assign inventory to a block: "Block Code" 2610, "From Date" 2615, "'To Date" 2620, "Block"
2625, "Authorize" 2630, "Forecast" 2635, "Resort" 2640, "Cluster" 2645, "Room Type" 2650, and "Room" 2655: In addition, the window includes a sustained type radial button 2660, a daily radial button 2665 and an expiration display field 2670.
The black code field 2615 uniquely identifiies a particular block. The expiration date field 2670 displays the expiration date for the block. The from date field 2620 allows the user to define the date from when the inventory in a block is taken out of availability. The to date field 2625 allows the user to define the date when the inventory assigned to a block will be released to availability. The block field 2625 allows the user to define the number of pieces of inventory which will make up the block at a specific level in the hierarchy, e.g., two rooms or two clusters. The authorize field 2630 allows the user to define the number of pieces of inventory to assign to the block.
The forecast field 2635 allows the user to define the number of pieces of inventory that the user believes will actually be used from the block. The sustained button 2660 allows the user to define tlhe block as a sustained availability block. The daily button 2665 allows the user to define the block as a daily availability block.
The resort field 2640 allows the user to select the resort to assign to the block. The cluster field 2645 allows the user to aelect the cluster to assign to the block. The room type field 2650 allow the user to select the room type to assign to the block. And, the room field 2665 allows the user to select the roam to assign to the block.

Reservations Figure 27 illustrates the exemplary operations associated with processing a call from a member prior to making a, reservation for a timeshare.
After a member calls the resort or agent servicing a resort, the agent obtains 5 various identifying parameters from the member in operation 2710. The identifying parameters include: a personal identification such as a social security number, passport numbers, etc.; property or membership identification, a club defined identification, or the members Last name. From the identifying parameter, the agent is presented vvith information about the 10 member including: whether the members has any outstanding account balances, whether the member is a current or active member. In addition, clubs may also have special "current" rules that are checked. If the member is a current or active member than the member may make a reservation is operation 2720.
Additionally, the member may exercise remaining usage rights or extend 15 exchange options, settle any financial obligations, update contact information, inquiry about their membership, view points information and log complaints.
Referring to Figure 27x, if the member seeks to make a reservation, then the agent determines if the members seeks to make a fixed time reservation, a floating time reservation or a points reservation, in operations 20 2702x, 2704a and 2706x.
If the member seeks to make a fixed time reservation, then operations 2708a - 2728a are performed. In operation 2708;x, the member specifies a time for the reservation. In operation 2710x, the agent searches for the specifies time. If the time is not available, then the member may request a new time.
25 If the time is available, then payment processing is initiates in operation 2714x. In operation 2716x, the Tool determines if the member's financial obligations are resolved. If not, then the reservation operation is terminated in operation 2718x. If the member is good financial. standing, then the inventory according to the time selected is decremented in operation 2720x. In operation 30 2722x, the agent books the reservation. in operation 2724x, the agent gathers any additional member information that may be required or desired. In operation 2728a, the members usage rights are updated according to the reservation made.
Referring to Figure 27b and 27c, if the member seeks to make a floating reservation, then the member make a request in operation 2710c. If the member chooses a single date in operation 2702c, then the Tool searches for the date requested according to the resolved usage rights for the member in operation 2704c If the request is not available, then the agent may check overbooking limits in operation 2?40c. If overbooking is not available or the supervisor chooses not to override the overbooking limits in operation 2750c, then the member may make another request in operation 2702c. If, in operation 2702c, the user requested a date range;, then the tool searches for the date range requested according to the resolved usage rights for the member in operation 2714c. If the request is not available, 'then the agent may check overbooking or a supervisor may override overbooking limits. If the request is available, the member is presented with a list of options to choose from in operation 2718c.
If either the date request from operation ~:702c or an option in 2720c is available or selected, then hotel availability is confirmed in operation 2712c.
In operation 2722c, the Tool determines whether the member passed the rules.
If the member did not pass, then the agent or supervisor may override the rules in operation 2724c. If the rules are not overridden, then the agent may not make a reservation and the operation is ended.
in operation 2728c, the Tool determines if there is a transaction fee associated with the reservation. if there is, then the agent may override the fee in operation 2730c. Otherwise, the member mu:>t pay the fee in operation 2732c. In operation 2734c, the Tool determine:. if there is a process payment associated with the reservation. If there is a process payment, then payment processing is initiated in operation 2736c. In operation 2738c, the Tool determines whether the member resolved any outstanding payment obligations.
If not, then the availability is released and any payments corresponding to the reservation are reversed in operation 2740c.

If the customer did resolve any financial obligations or there was not a process payment, then the Tool process the delinquency policy in operation 2742c. If the delinquency process fails, then the member is asked to submit payment in operation 2746c. If the user does not submits a payment, then the delinquency policy hits a fatal level and the availability is released and the any payments corresponding to the reservation are reversed in operation 2740c.
If the member submits a payment, then the payment is collected in operation 2754c. After the payment is collected or if the delinquency policy does not fail, then the validation rules are processed in operation 2752c. In operation 2756c,. the reservation is booked. In operation 27S8c, the agent gathers additional member information. In operation 2760c, actions are generated. And, in operation 2762c; usage rights for the member are updated.
The member is they able to use the timeshare reserved.
Referring to Figure 27d and 27e, if the member seeks to make a points reservation, then the member may enter a request in operation 2702e. In operation 2704e, the member may request a single date for the reservation or a range of dates for the reservation. If a single date is requested, then availability is scanned in operation 2706e and the result is displayed in operation 2708e. If the request is available, then the availability is held in operation 2710e. If a date range is requested in operation 2704e, then the range is scanned for availability in operation 2716e. If the request is available, then a list of options are presented in operation ~:720e and the user may select an option is operation 2722e. The option selected is held in operation 2710e.
If either a date is not available, a date range is not available, or the member does not select an option, then the member may make a new request in operation 2702e.
After a request is held in operation 27i0e, then the Tool determines if the member passed the rules in operation 2712e. If not, then the agent may override the rules in operation 2714e or end the reservation process in operation 27-l Se. If the member passes the rules, then the Tool verifies that the member has enough points for the hold performed in operation 2710e. If the member does not have enough points, then the member may borrow points in operation 2730e or rent points in operation 2732e. If the member does not borrow or rent points, then the inventory held is released and the member may make an additional request in operation 2724e or end the reservation process.
If the member has enough points, borrows points, or rents points, then the Tool determines if there is a transaction fee in operation 2738e. If there is a transaction fee, then the agent may override the; fee is operation 2740e. If the fee is not overridden, then the member pays the fee. In operation 2744e, the Tool determines if there are any payments to process. If so, the payments are processed in operation 2746e. In operation 2;748e, the Tool determines if the customer resolved any outstanding financial obligations. If not, then the availability is released and any payments are reversed.
If the members has resolved any outstanding financial obligations in operation 2748e or there are any payments to process, then the Tool processes the delinquency policy in operation 2752e. If the delinquency policy fails in operation 2754e, the agent may request payment from the member in operation 2756e. If the payment is not collected, then the delinquency policy fails in operation 2758e and the availability is released i:n operation 2750e. If the payment is collected or the delinquency policy does not fail, then the validation rules are processed in operation 2760e.
In operation 2764e, the members points account is decremented and the reservation is hooked in operation 2766e. In operation 2768e, the agent gathers additional information. In operation 27'IOe, actions are generated. In operation 2772e, the members usage rights are updated based on the reservation. After operation 2772e, the reservation operations for a points based reservation are complete.
Points Rate Definition The Tool includes points rate definition which allows the Tool to define nightly point rates for use in the reservation process. Members with a points usage right and a points reservation policy associated with the usage right can request a reservation for a piece of inventory. 'The arrival date and length of stay will determine the availability of the inventory and then the point rate associated with the reservation. The rates are defined for a hotel cluster and weekend night combination.
A presently preferred embodiment of the present invention and many of its improvements have been described with a degree of particularity. It should be understood that this description has been made by way of example, and that the invention is defined by the scope of the following claims.

Claims (39)

1. We claim:1. A computer based method used in timeshare development and management for defining a timeshare product, comprising the operations of:
   defining a usage type based on the arrangement of a set of usage type variables; and defining at least one usage right associated with the usage type, the at least one usage right based an the arrangement of a set of usage right variables;
   whereby the characteristics of the product are a function of the usage type and the associated at least one usage right
2. 2. The method according to claim 1 wherein the usage type includes a space dimension component and a time dimension component.
3. 3. The method according to claim 1 wherein the usage type includes a point-based usage type.
4. 4. The method according to claim 1 wherein the usage type includes a space dimension component, a time dimension component, and a points-based component.
5. 5. The method according to claim 1 wherein the set of usage type variables include a sales time unit variable, a sales time unit count variable, a sales increment variable, a sales points variable, a pricing unit allocation variable, a pricing time allocation variable, a contract unit allocation variable, and a contract time allocation variable.
6. 6. The method according to claim 2 wherein the space dimension component includes one of a fixed space dimension component and a floating space dimension component.
7. 7. The method according to claim 2 wherein the time dimension component includes one of a fixed time dimension component, a floating time dimension component, and a fractional time dimension component.
8. 8. The method according to claim 1 wherein the usage type includes a whole ownership usage type and a pure points usage type.
9. 9. The method according to claim 1 further including the operation of defining a time unit.
10. 10. The method according to claim 9 wherein the time unit is a function of a day.
11. 11. The method according to claim 10 wherein the time unit includes a baseline factor, the baseline factor defining the tame unit as an even multiple of a day.
12. 12. The method according to claim 10 wherein the time unit includes a baseline factor, the baseline factor segmenting the time unit into discrete portions of a day.
13. 13. The method according to claim 1 wherein the operation of defining at least one usage right includes the operations of defining a reservation start date and a reservation end date for each at least one usage right, the reservation start date and end date together defining a reservation window in which a reservation can be made for the product being defined, the reservation start date defining the first day of the reservation window that a reservation can be made and the reservation end date defining the last day of the reservation window that a reservation can be made.
14. 14. The method according to claim 1 wherein the operation of defining at least one usage right includes the operations of defining a usage start date and a usage end date for each at least one usage right, the usage start date and the usage end date together defining a usage window in which the product being defined may be used, the usage start date defining the first day of the usage window that the product may be used and the usage end date defining the last day of the usage window that the product may be used.
15. 15. The method according to claim 1 wherein the operation of defining at least one usage right further includes the operation of defining an accommodation for each at least one usage right, wherein the accommodation includes unit, unit type and resort.
16. 16. The method according to claim 1 wherein the operation of defining at least one usage right includes the operation of defining a Boolean operator, wherein the Boolean operator determines the interaction between each usage right defined.
17. 17. The method according to claim 1 wherein the operation of defining a usage right includes the operation of defining at least one policy associated to the usage right wherein the policies include rental and exchange.
18. 18. The method according to claim 1 further including the operation of adding a membership to the product wherein the membership includes additional usage rights.
19. 19. The method according to claim 1 further including the operation of defining a points package for the product, the points package including a points increment representing the number of points that the points package represents.
20. 20. A computer based method used in timeshare development and management for developing and managing timeshare inventory, comprising the operations of:
    defining at least one timeshare product, each product having space and time characteristics;
    defining at least one sales inventory, each sales inventory including a set of sales inventory entities available for association with the timeshare product, the sales inventory entities defining a plurality of particular spaces; and linking at least one timeshare product with at least one sales inventory to create a product inventory, the product inventory including a set of product inventory entities available for sale as a timeshare interest, the product inventory entities including particular rights to space and time that can be used by a purchaser of the timeshare interest.
21. 21. The method according to claim 20 wherein the operation of defining at least one sales inventory includes the operation of defining a resort, defining a unit type and defining a unit.
22. 22. The method according to claim 20 including the operations of defining at least one hotel inventory, and mapping the at least one hotel inventory to the at least one sales inventory.
23. 23. The method according to claim 22 wherein the operation of defining at least one hotel inventory includes the operations of defining a resort, defining a cluster, defining a room type and defining a room.
24. 24. The method according to claim 20 wherein the operation of linking at least one product to at least one sales inventory includes the operations of selecting the at least one product, defining a search criteria that describes a particular entity within the set of sales inventory entities, searching the at least one sales inventory according to the search criteria, and displaying any matches between the search criteria and the at least one sales inventory found in the search.
25. 25. The method according to claim 24 wherein the at least one product includes a non pure points product, and wherein the operation of linking the at least one product to the at least one sales inventory for the non pure points product includes the operations of defining a product calendar, defining a maintenance increment, initializing a pricing attribute, initializing a points attribute, initializing an inventory dates attribute, and initializing a business entities attribute.
26. 26. The method according to claim 24 wherein the at least one product including a pure points products, and wherein the operation of linking the at least one product to the at least one sales inventory for the pure points product includes defining a price for the pure points product, and initializing a business entities attribute.
27. 27. A computer based method used in timeshare development and management for developing and managing timeshare inventory, comprising:
    selling a timeshare interest, the timeshare interest including at least one usage right defining how the timeshare interest may be used; and resolving the at least one usage right to generate at least one resolved usage right wherein the at least one resolved usage right defines how the timeshare interest may be used at a particular time.
28. 28. A computer based method used in timeshare development and management for developing and managing timeshare inventory, comprising:
    
    defining a timeshare product including at least one usage right;
    defining a sales inventory;
    defining a hotel inventory;
    linking the timeshare product to the sales inventory to define a product inventory including a set of product inventory entities available for sale, each of the product inventory entities including the at least one usage right;
    selling a product inventory entity;
    resolving the at least one usage right to generate at least one resolved usage right; and allowing a reservation to be made for the product inventory entity based on the at least one resolved usage right.
29. 29. The method according to claim 28 wherein the operation of selling a product inventory entity further includes the operations of selecting a product inventory entity, defining a search criteria for the product inventory entity including a space dimension search criteria and a time dimension search criteria, searching for the product inventory entity matching the search criteria, and selecting a product inventory entity from a set of product inventory entities that match the search criteria.
30. 30. The method according to claim 28 wherein the operation of defining a sales inventory includes the operations of defining a resort, defining at least one unit type and defining at least one unit.
31. 31. The method according to claim 28 wherein the operation of defining a hotel inventory includes the operations of defining a resort, defining at least one room type and defining a room.
32. 32. The method according to claim 28 wherein the operation of defining a product includes the operations of defining a time unit, and defining a usage type using the time unit wherein the at least one usage right is associated to the usage type.
33. 33. A software system for timeshare development and management comprising:
    
    a usage type definition module including a set of definable usage type variable fields;
    a usage right definition module including a set of definable usage right variable fields; and a timeshare product definition module including a set of definable timeshare product variable fields;
    whereby the usage type module, the usage right module and the timeshare product definition module can be utilized together to define a timeshare product.
34. 34. The system according to claim 33 further comprising a time unit definition module.
35. 35. A computer program product embodied in a tangible media comprising:
    a set of program code to implement a usage type definition module wherein the usage type definition module includes a set of definable usage type variable fields;
    a set of program code to implement a usage right definition module wherein the usage right definition module includes a set of definable usage right variable fields;
    a set of program code to implement a timeshare product definition module wherein the product definition module includes a set of definable timeshare product variable fields; and whereby the usage type module, the usage right module and the timeshare product definition module can be utilized together to define a timeshare product.
36. 36. The computer program product of claim 35 wherein the tangible media comprises a magnetic disk.
37. 37. The computer program product of claim 35 wherein the tangible media comprises an optical disk.
38. 38. The computer program product of claim 35 wherein the tangible media comprises a propagating signal.
39. 39. A system used in timeshare development and management for developing and managing timeshare inventory, comprising:
    a timeshare product definition module including a set of time unit definition fields, a set of usage type definition fields, and a set of usage right definition fields, the product definition module operative to create a timeshare product;
    a sales inventory definition module including a set of resort definition fields, a set of unit type definition fields and a set of unit definition fields, the sales inventory module operative to create a sales inventory that includes a set of sales inventory entities; and a product inventory definition module including a product field, a set of sales inventory entity fields and a linking module, the linking module operative to link the timeshare product with the sales inventory entity to create a product inventory that includes a set of product inventory entities that are available for sale as a timeshare interest.