Note: Descriptions are shown in the official language in which they were submitted.
CA 02339065 2000-12-19
WO 00/b3794 PCT/US00l10492
1
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
CA 02339065 2000-12-19
WO 00/63794 PCT/US00/10492
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
CA 02339065 2000-12-19
WO 00/63794 PCT/US00110492
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
CA 02339065 2000-12-19
WO 00/63794 PCTIUS00/10492
4
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.
CA 02339065 2000-12-19
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
CA 02339065 2000-12-19
WO 00/63794 PCTIUS00/10492
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
CA 02339065 2000-12-19
WO 00/63794 PCT/US00/10492
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
CA 02339065 2000-12-19
WO 00163794 PCT/US00/10492
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
CA 02339065 2000-12-19
WO 00/63794 PCTIUS00/10492
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.
CA 02339065 2000-12-19
WO 00/63794 PCTJLTS00/10492
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;
CA 02339065 2000-12-19
WO 00/63794 PCT/US00/10492
11
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;
CA 02339065 2000-12-19
WO 00!63794 PCT/US00/10492
12
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
CA 02339065 2000-12-19
WO 00/63794 PCTICTS00/10492
13
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
CA 02339065 2000-12-19
WO OOI63794 PCTIUS00/10492
I4
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
CA 02339065 2000-12-19
WO 00/63794 PCT/US00110492
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.
CA 02339065 2000-12-19
WO 00163794 PCT/USOOJ10492
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
CA 02339065 2000-12-19
WO 00/6394 PCTIUS00/10492
17
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.
CA 02339065 2000-12-19
WO 00!63794 PCTIUSOO/I0492
18
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
CA 02339065 2000-12-19
WO 00!63794 PCT/IJSOOI10492
19
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
CA 02339065 2000-12-19
WO 00/63794 PCT/US00/10492
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.
CA 02339065 2000-12-19
WO 00/63794 PCTIIJS00/10492
21
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.
CA 02339065 2000-12-19
WO 00/63794 PCT/US00110492
22
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
CA 02339065 2000-12-19
WO 00/b3794 PCT/IIS00110492
23
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
CA 02339065 2000-12-19
WO 00/63794 PCTIUS00/10492
24
"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
CA 02339065 2000-12-19
WO OOI63794 PCT/LTS00110492
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
CA 02339065 2000-12-19
WO 00/63794 PCTIUS00/10492
26
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
2
(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.
CA 02339065 2000-12-19
WO 00/63794 PCTIUS00/10492
27
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
CA 02339065 2000-12-19
WO 00!63794 PCT/US00/10492
28
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
CA 02339065 2000-12-19
WO 00/63799 PCT/US00/10492
29
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
CA 02339065 2000-12-19
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"
CA 02339065 2000-12-19
WO 00/63794 PCT/US00/10492
31
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
CA 02339065 2000-12-19
WO 00/63794 PCT/US00/10492
32
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
CA 02339065 2000-12-19
WO 00/63794 PCTIUS00/10492
33
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
CA 02339065 2000-12-19
WO 00/63794 PCT/US00/10492
34
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.
CA 02339065 2000-12-19
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.
CA 02339065 2000-12-19
WO 00/63794 PCTIUS00/10492
36
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,
CA 02339065 2000-12-19
WO 00/63794 PCT/US00/10492
37
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
CA 02339065 2000-12-19
WO 00163794 PCT/US00/10492
38
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
CA 02339065 2000-12-19
WO 00!63794 PCT/US00/10492
39
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
CA 02339065 2000-12-19
WO 00/63794 PCT/USOOI10492
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
CA 02339065 2000-12-19
WO 00/63794 PCT/US00110492
41
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
CA 02339065 2000-12-19
WO 00163794 PCT/US00110492
42
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;
CA 02339065 2000-12-19
WO 00/63794 PCTIUS00/10492
43
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
CA 02339065 2000-12-19
WO 00!63794 PCT/US00I10492
44
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
CA 02339065 2000-12-19
WO 00/63794 PCT/US00/10492
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
CA 02339065 2000-12-19
WO 00/63794 PCT/US00110492
46
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
1334
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
CA 02339065 2000-12-19
WO OOI63794 PCTIUS00/10492
47
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."
CA 02339065 2000-12-19
WO 00/63794 PCTIUS00/10492
48
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
CA 02339065 2000-12-19
WO OO/G3794 PCTIUS00/10492
49
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
CA 02339065 2000-12-19
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.
CA 02339065 2000-12-19
WO 00/63794 PCT/LJS00/10492
51
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
CA 02339065 2000-12-19
WO 00/63794 PCTIUS00/10492
52
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.
CA 02339065 2000-12-19
WO 00/63794 PCT/US00/10492
53
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
CA 02339065 2000-12-19
WO 00163794 PCT/US00l10492
54
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,
CA 02339065 2000-12-19
WO 00/63794 PCT/US00/10492
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.
CA 02339065 2000-12-19
WO 00/63794 PCT/US00/10492
56
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.
CA 02339065 2000-12-19
WO 00/63794 . PCTIUS00110492
57
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
CA 02339065 2000-12-19
WO 00163794 . PCT/USOOI10492
58
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
CA 02339065 2000-12-19
WO 00163794 . PCT/US00110492
59
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
CA 02339065 2000-12-19
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
CA 02339065 2000-12-19
WO 00/63794 PCT/US00110492
61
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
CA 02339065 2000-12-19
WO 00/63794 . PCT/US00/10492
62
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.
CA 02339065 2000-12-19
WO 00/63794 PCTIUS00110492
63
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
CA 02339065 2000-12-19
WO 00/63794 PCT/US00/10492
64
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
CA 02339065 2000-12-19
WO 00/63794 PCT/US00/10492
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
CA 02339065 2000-12-19
WO 00/63794 . PCT/US00/10492
66
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
CA 02339065 2000-12-19
WO 00/63794 PCTIUSOOI10492
67
defnition operations 1300 - 1372, a link 2220g to ithe unit type definition
operations 1610 - 1660, and a link 2230g to the unit definition operations
1700
- 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
CA 02339065 2000-12-19
WO 00!63794 . PCT/US00/10492
68
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
CA 02339065 2000-12-19
w0 00/63794 PCT/US00/10492
69
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.
CA 02339065 2000-12-19
WO OOI63794 PCT/US00/10492
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).
CA 02339065 2000-12-19
WO 00/63794 PCT/US00/10492
71
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
CA 02339065 2000-12-19
WO 00!63794 PCT/US00/10492
72
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
CA 02339065 2000-12-19
WO 00/63794 . PCTlUS00/10492
73
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
CA 02339065 2000-12-19
WO 00163794 PCT/US00/10492
74
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
CA 02339065 2000-12-19
WO 00163794 PCT/US00/10492
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
CA 02339065 2000-12-19
WO 00/63794 PCT/US00/10492
76
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
CA 02339065 2000-12-19
WO 00/63794 PCT/US00/10492
77
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,
C 1
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
CA 02339065 2000-12-19
WO 00/63794 PCTIUS00I10492
78
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
CA 02339065 2000-12-19
WO 00/63794 PCTIUS00/10492
79
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.
CA 02339065 2000-12-19
WO 00/63794 PCT/US00/10492
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
CA 02339065 2000-12-19
WO 00163794 PCTIUS00110492
81
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.
CA 02339065 2000-12-19
WO 00163794 PCT/US00/10492
82
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
CA 02339065 2000-12-19
WO 00163794 PCT/I1S00/10492
83
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
CA 02339065 2000-12-19
WO 00/63794 PCT/US00/10492
84
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.
