WO2000063794A1 - Outil logiciel pour la gestion de multiproprietes - Google Patents

Outil logiciel pour la gestion de multiproprietes Download PDF

Info

Publication number
WO2000063794A1
WO2000063794A1 PCT/US2000/010492 US0010492W WO0063794A1 WO 2000063794 A1 WO2000063794 A1 WO 2000063794A1 US 0010492 W US0010492 W US 0010492W WO 0063794 A1 WO0063794 A1 WO 0063794A1
Authority
WO
WIPO (PCT)
Prior art keywords
product
inventory
usage
defining
timeshare
Prior art date
Application number
PCT/US2000/010492
Other languages
English (en)
Inventor
Gene N. Pence
Original Assignee
Css International, Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Css International, Inc. filed Critical Css International, Inc.
Priority to EP00922300A priority Critical patent/EP1112540A1/fr
Priority to AU42505/00A priority patent/AU4250500A/en
Priority to CA002339065A priority patent/CA2339065A1/fr
Publication of WO2000063794A1 publication Critical patent/WO2000063794A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/02—Reservations, e.g. for tickets, services or events
    • H—ELECTRICITY
    • H10—SEMICONDUCTOR DEVICES; ELECTRIC SOLID-STATE DEVICES NOT OTHERWISE PROVIDED FOR
    • H10N—ELECTRIC SOLID-STATE DEVICES NOT OTHERWISE PROVIDED FOR
    • H10N60/00—Superconducting devices
    • H10N60/01—Manufacture or treatment
    • H10N60/0184—Manufacture or treatment of devices comprising intermetallic compounds of type A-15, e.g. Nb3Sn

Definitions

  • 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.
  • 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 condo 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.
  • 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 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 did not provide enough flexibility for timeshare developers.
  • 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.
  • 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.
  • 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.
  • 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 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 multi-site timeshares, vacation clubs and complicated organizational structures.
  • Multi-site timeshares and vacation clubs are similar in that they both give participants access to more than one property.
  • a vacation club allows a club participant to use various properties with the club. Oftentimes the club properties are in different locations such as Florida and Las Vegas. Accordingly, the timeshare owner can go to the club's property in Florida or Las Vegas.
  • 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.
  • a points value to piece of inventory 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 object of the present invention is to provide inventory management for the various current and yet to be defined points based products.
  • 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 another. Accordingly, a further object of the present invention is to provide inventory management for timeshare owners with complicated organizational structures.
  • time share property management 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.
  • the present invention relates to a computer based method used in timeshare development and management for defining a timeshare product.
  • the method includes defining a usage type based on the arrangement of a set 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 time unit count variable, a sales increment variable, a sales points variable, a pricing unit allocation variable, a pricing time allocation variable, a contract unit allocation variable, and a contract time allocation variable.
  • 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 may 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 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 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.
  • the product may include a non pure points product.
  • the operation of linking the product to the sales inventory for the non 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 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 timeshare product to the sales inventory to define a product inventory including a set of product inventory entities available for sale, each of the product inventory entities including the 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 utilized 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 implement a usage type definition module, wherein the usage type definition module includes a set of definable usage type variable fields.
  • 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.
  • Figure 1 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 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
  • Figure 4 is a flowchart illustrating time unit definition operations
  • Figure 5 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 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 rights definition operations
  • Figure 8 is a flowchart illustrating timeshare product definition operations
  • Figure 9 is a flowchart illustrating membership definition operations
  • Figure 10 is a block diagram illustrating an exemplary representative configuration of hotel inventory
  • Figure 1 1 is a block diagram illustrating an exemplary representative configuration of sales inventory
  • Figure 12 is a flowchart illustrating the high level operations of defining hotel inventory and defining sales inventory
  • Figure 13 is a flowchart illustrating the fields and operations involved in defining a resort
  • Figure 14 is a flowchart illustrating the fields and operations involved in defining a room type
  • Figure 15 is a flowchart illustrating the fields and operations involved in defining a room
  • Figure 16 is a flowchart illustrating the fields and operations involved in defining a unit type
  • Figure 17 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 contract inventory selection operations
  • Figure 21a 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
  • 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
  • Figures 27d and 27e are flowcharts illustrating point product reservation operations.
  • 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 1 10, hotel inventory 1 15, hotel inventory control 120 and their interrelationships. Figure 1 is referred to throughout this document for illustrative and exemplary purposes.
  • Product inventory 105 comprises what may be sold as a timeshare.
  • a particular piece of product inventory i.e., a widget 125
  • Sales inventory 1 10 comprises the logical space that may be sold as a part of the product inventory 105.
  • the two bedroom unit 130 at the Sunbay Resort 135 is a piece of sales inventory.
  • hotel inventory 1 15 comprises the space that may actually be used when a reservation is made.
  • a piece of hotel inventory may be Room 101 (140) (a particular two bedroom unit) at the Sunbay Resort 135.
  • PI 105 Product Inventory 105
  • SI sales inventory 1 10
  • HI hotel inventory 1 15
  • the creation of PI 105 involves the definition of products 145.
  • a product 145 is the set of parameters that define the timeshare rights.
  • a product includes usage types 150 and usage rights 155.
  • 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. 7).
  • 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 1 10 involves, essentially, the definition of the details of a particular property into pieces that may then be associated to a product and together sold.
  • the SI for the Sunbay Resort 135 may include two types of units 162, a 3 bedroom unit type 164 and a two bedroom unit type 166. There may be one three bedroom unit, unit 105 (168); and four two bedroom units, unit 101 (170), unit 102 (172), 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).
  • the tool provides for the creation and manage of a plurality of widgets at one time.
  • the PI automatically removes the unit 101 from availability for the two-bedroom/week 1 widgets 178. Accordingly, there would only be three two-bedroom/week 1 widgets available for sale.
  • HI 1 15 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.
  • the HI 1 15 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 , 103 and 105 A), two bedroom golf view (102, 104, 109), and studio (105B, 108, 1 10)).
  • 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.
  • two usage rights for a particular widget may be: "Right 1" the right to make a reservation for Unit 101 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 Weekl and the first day of Weekl .
  • the resolved usage right at 400 days before Weekl is usage Right 1
  • 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 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 AppleTM operating system, however, may be utilized.
  • GUI graphical user interfaces
  • the tool preferably runs on a Windows NTTM server or Unix TM server and utilizes an OracleTM database.
  • the software code for the Tool is implemented using Power BuilderTM by SybaseTM.
  • FIG. 2 is a flowchart illustrating the exemplary hierarchical or main operations involved in the use of the Tool.
  • 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.
  • 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.
  • Two exemplary usage rights 155 include the right to reserve a specific unit or the right to reserve a type of unit.
  • 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 defined in the SI.
  • the SI 1 10 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 both 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.
  • the products are associated to the SI to create product inventory 105.
  • Each discrete component or "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.
  • 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.
  • the Tool 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.
  • usage rights and policies are defined for each product. The usage rights and policies define how a product may be used by the timeshare owner. Oftentimes, usage rights and policies are a function of time. For example, a usage right associated with a product may provide rights to a particular unit at time X (such as between 6 and 12 months in advance) while another usage right associated with the product may only provide rights to a particular unit type at time Y (such as between 3 and 6 months in advance).
  • These two usage rights are resolved in operation 225 to determine how, at a particular time, the widget may be used. For example, at time X the timeshare owner may reserve the particular unit whereas at time Y the owner may only reserve a particular unit type.
  • main operation 230 a reservation is made at a resort.
  • the reservation operation utilizes HI 1 15, a member servicing module 235, hotel inventory control 240, resolved usage rights 225 and points rates information 245.
  • the Tool updates inventory availability based on the reservation made in operation 230.
  • 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.
  • a timeshare product may be defined to create an interest in golf course tee times or racquetball court times.
  • a timeshare product may be defined to create an interest in golf course tee times or racquetball court times.
  • the description herein will primarily use property based examples to describe the present invention.
  • FIG 3 is a flowchart illustrating an exemplary hierarchical or main operations by which a timeshare product is defined.
  • Product definition allows a user to define a customized set of timeshare products.
  • 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 101 (140), typically located at a resort, e.g. , Sunbay (135), meant for reoccurring use by the eventual timeshare owner, e.g. , weekl of each year.
  • SI is associated with a product to create PI, a set of timeshare widgets, that may be sold.
  • 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 demands that any inventory management tool be able to support a plurality of customized time units.
  • 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.
  • 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.
  • the resort season calendar is a compilation of time units. 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.
  • 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.
  • 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.
  • 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 to be used, e.g., "weekl" the first week of each year.
  • 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 101.
  • a fixed usage type for the time dimension preferably refers to a fixed time, e.g., the first week of High Season.
  • High Season is an exemplary season that is defined in the resort season calendar, discussed herein in conjunction with main operation 320, that 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 the 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.
  • timeshare owner may reserve any unit at any resort during any time with an equal or lesser point value as long as the unit, resort and unit are included in the timeshare.
  • points may be included with any product to give increased flexibility to the timeshare product.
  • the user defines usage rights and policies for a given product which is associated with a usage type.
  • Each product will have at least one associated usage right and may have more. Additionally, each product may have multiple associated usage rights and the eventual buyer may select to purchase a product having some subset of the available rights.
  • An exemplary usage right defines what type of reservation may be made as a function of the time when the timeshare owner attempts to make the reservation. For example: Right 1 provides that if a reservation is made more 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.
  • the exemplary Right 1 and Right 2 would not apply to a pure fixed/fixed product wherein a particular unit at a particular 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 weekl may be 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 instead of using the unit that year.
  • time unit defined in main operation 3 10 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 defines what is eventually associated with SI to create widgets that are sold.
  • add-on memberships are supported. Membership is an optional or mandatory enhancement 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.
  • 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 "day” and "year.” If the user chooses to define a time unit that is less than a day operation 406 follows. In operation 406, the user inputs a name for the time unit. The name selected will then be used to identify the defined time unit throughout the Tool. In operation 408, the user defines a baseline 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.
  • the time unit is six hours long.
  • the user names the subdivisions. Referring to the previous example, four subdivision names would be required, e.g., "Sub l ,” “Sub2,” “Sub3,” and "Sub 4.”
  • the user defines the start time and end time for each subdivision. For example, the start time and end time for Sub l 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.
  • 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.
  • operation 424 follows.
  • 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.
  • the user defines a baseline factor for the new time unit.
  • the baseline factor for time units greater than a day, defines 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.
  • 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.
  • the user may activate the newly defined time unit and hence make it available for usage type definition and resort season calendar definition as described below.
  • the newly defined time unit may alternatively, however, be activated at a later time. If, at operation 402, the user had not selected 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.
  • 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 resort season calendar structures the layout of a use year within a resort.
  • a resort's use year is the entire year.
  • 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 serves 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 500a, increment one start date main operation 500b, seasons main operation 500c and swap increment main operation 500d.
  • the preliminary resort season calendar main operation 500a includes selecting the resort and selecting a time unit.
  • the resort that the calendar is being defined for is selected from a set of previously defined resorts.
  • the time unit that the calendar is being defined for is selected from a set of previously defined time units.
  • 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 all 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 for each check-in day.
  • the check-in days are a function of the IOSD.
  • the user selects the year that the IOSD is being specified for.
  • 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.
  • the user selects the IOSD with a Monday check-in.
  • the user selects the IOSD with a Tuesday check- in.
  • the user selects the IOSD with a Wednesday check-in.
  • the user selects the IOSD with a Thursday check-in.
  • the user selects the IOSD with a Friday check-in.
  • 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#-l)*time unit).
  • main operation 500c 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 organization's defined season.
  • An "organization” represents a high level entity such as MarriotTM 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.
  • the user defines a code for the season.
  • the code allows other modules to access the season definition.
  • the code may be "highseason.”
  • the name for the season is selected.
  • the season may be named "High Season.”
  • 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.
  • 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.
  • main operation 500d the user defines "swap increments."
  • 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 always included with the widget.
  • the adjacent increment is the "swap" increment.
  • the user selects the year for the swap increment operations.
  • the year dictates what potential values are presented for the subsequent swap increment operations.
  • the user selects the time increment from the specified year for the swap.
  • the user is presented with the use year associated with the specified time increment.
  • the user is presented with the start date and the end date for the specified time increment.
  • the user is presented with all of the available time increments for the year in two side-by-side lists. The user selects the increments that are two be swapped from the two lists and executes the swap operation preferably by hitting a swap button. The two increments are then swapped.
  • the resort season calendar definition operations are implemented in a window, not shown herein, and preferably the workflow of the resort season calendar definition operations is left to right.
  • FIG. 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 comprises a set of widgets that may be sold as timeshares.
  • Usage type definition includes main operation 600a wherein 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.
  • 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 dimension).
  • 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 may represent interests in items beside property such as use of a racquetball court.
  • the usage types described in Figure 6a are predefined in the Tool and available to the user of the Tool in a pulldown window when the user initially begins the usage type definition operations.
  • 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 ski season.
  • 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 1-6 (634), four weeks during High Season and three weeks during Low Season (636). Like the High 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 includes weeks 14-19 (640), four weeks during High Season and three weeks during Low Season (642).
  • the fractional time dimension for Fraction 3 includes weeks 27-32 (646), four weeks during High Season and three weeks during Low Season (648).
  • the time dimension for Fraction 4 includes weeks 40-45 (652), four weeks during High Season and three weeks during Low Season (654).
  • the Tool allows fractions to include a mix of fixed, floating and points time dimensions. With a fixed space dimension, each fraction illustrated in Figure 6b is associated with a particular unit.
  • a floating unit / fixed week usage type 656 is used to create a widget that includes an interest in a particular type of unit at a particular time, e.g.
  • a 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. With 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 to 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.
  • 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.
  • the sales attributes definition operation 600a 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.
  • the sales attributes determine how PI is controlled.
  • 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.
  • the user defines the sales time unit 666.
  • the sales time unit defines the length of time for usage of the inventory that the prospective purchaser may be purchasing.
  • 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.
  • a set of sales time units that is the same as the set of previously defined time units is available to select from.
  • the user defines the sales time unit count 668.
  • the sales time unit count defines how many sales time units are defined for a given use year. Referring to the fixed unit / fixed week usage type 626, the user 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.
  • the sales time unit count 668 defaults to 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 668 value 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 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).
  • the user defines the sales increment 670.
  • the sales increment 670 defines how many widgets are ultimately generated for the PI, as discussed below.
  • a "widget" represents a discrete item in the product inventory.
  • a widget represents a timeshare interest in a piece of property, i.e., SI, as defined by the operations of this invention.
  • a widget may represent timeshare interests in items besides property, e.g. , a 4 p.m. racquetball court time every week.
  • 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.
  • 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.
  • the sales increment 670 cannot be a value that is greater than the sales time unit count 668.
  • 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.
  • the sales time allocation 672 will be defaulted to "fraction”
  • the pricing time allocation 678, described below in operation 614 is defaulted to "increment”
  • 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.
  • the sales increment 670 must be greater than 0.
  • 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 attributes defined in operations 602-606.
  • the valid values for the sales time unit allocation 672 are "fixed or floating,” “fraction” or “points.”
  • 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 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.” 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 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 614, defining a pricing time allocation 678.
  • the pricing attributes determine how product inventory is priced.
  • the user defines the pricing unit allocation 676.
  • the pricing unit allocation 676 determines the pricing attributable to the space dimension.
  • the valid values for the pricing unit allocation 676 are unit, type and points. Any usage type with an "unit” pricing unit allocation 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” pricing unit allocation 676 will create a usage type with a "points" space dimension.
  • the user defines the pricing time allocation 678.
  • the pricing time allocation 678 determines the pricing attributable to the time dimension.
  • the valid values for the pricing time allocation 678 are increment, season and points. Any usage type with 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 type with a "floating" time dimension. And, any usage type with a "points” pricing time allocation 678 will create a usage type with a "points" time dimension.
  • the contract attribute definition main operation 600c preferably includes: operation 616, defining contract unit allocation 680; and operation 618, defining contract time allocation 682.
  • contract attribute definition determines how product inventory is sold.
  • the user defines the contract unit allocation 680.
  • 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.
  • the user defines the contract time allocation 682.
  • the valid values for contract time allocation include increment, season and points.
  • the contract time allocation determines what time dimension the widget will encompass.
  • the Tool 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 Tool at any time so long as it is not currently used in the definition of a timeshare product.
  • a usage type may be activated or inactivated at any time. Activation of a usage type means that the usage type is available for the definition of a timeshare product. An inactivated usage type that was previously used in the definition of timeshare product does not effect the previously defined timeshare product.
  • the usage type definition operations are implemented in a window, not shown herein, and preferably the workflow of the usage type definition window is left to right, similar to that shown in Figure 6a.
  • the usage type setup window and associated datawindow fields, i.e. , operations 600 - 620 do not enforce this workflow. Accordingly, the operations 600 - 620 may be performed in any order the user of the Tool desires.
  • 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.
  • 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.
  • the 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 and policies associated with a particular product are part of the product and fully accessible by the Tool.
  • 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.
  • the Tool includes a set of usage rights that may be customized for a particular product by the user.
  • Usage 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
  • the set of usage rights includes: the reservation start and end date, the usage start and end date, the length of stay, and the accommodation.
  • the usage rights definition includes a boolean relationship, i.e., AND or OR, between different rights that allows the user to establish relationships between different rights for a given product.
  • 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.
  • FIG. 7 is a flowchart illustrating the exemplary operations involved in defined a usage right.
  • operation 700 the user selects a product for which they desire to define a usage right and policy for.
  • 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.”
  • 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.
  • this is achieved by entering a formula that consists of a defined keyword and an expression ⁇ @seasonstart-365.
  • the keyword for the reservation start date is @seasonstart wherein @seasonstart is defined as January 1 of the particular year.
  • the expression is (-365) which represents 365 days before
  • @seasonstart Therefore, with @seasonstart-365 entered as the reservation start date the owner has the right to make a reservation for his particular timeshare product 365 days before the first day of High Season.
  • the keywords, starting with "@,” are reserved in the Tool.
  • 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 2 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.
  • the reservation end date is entered by way of a formula that consists of a defined keyword and an expression.
  • the keyword and expression is @seasonend-7.
  • the keyword for the reservation end date is @seasonend wherein @seasonend is defined as March 3 1 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 13 months and 1 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.
  • the user selects the usage start date.
  • the usage start date determines the start of when the owner has a right 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 101 during weekl for Right 1. 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.
  • 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 @deedend is defined as the end of weekl .
  • the user defines the length of stay.
  • 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.
  • this value defaults to the time unit, e.g., "week", selected for the particular product.
  • the user defines the probability that the member will exercise the specified usage right within the reservation window defined.
  • the sum of all probabilities for the rights associated with a product must equal 100%.
  • the probability is a variable that may be used in conjunction with market planning to forecast future product inventory needs and to forecast future availability blocking requirements.
  • the user defines the accommodation for the rights.
  • the accommodation would be "unit type" and for Right 1 the accommodation would be unit.
  • the particular unit type of Right 2 or the particular unit of Right 1 is defined during contract inventory selection discussed in conjunction with Figure 21 below.
  • the set of available accommodation values is unit, unit type and points.
  • the user defines the Boolean operator which determines the interaction of various rights associated with the product. For 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 exercise Right 1.
  • the user may elect to edit an existing usage right or define another new usage right for the product.
  • 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, edit or 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.
  • 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 790.
  • 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 799.
  • a policy defines how a particular right may 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, are defined in a business rules engine that is associated with the Tool.
  • 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.
  • 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.
  • the user determines if a new product will be created. If so, in operation 805, the user selects a previously defined usage type for the new product.
  • the user names the product.
  • the user determines if the product will have a perpetual life.
  • the user sets the use term start date in operation 860.
  • 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.
  • the use term expiration date is set.
  • the use term expiration date determines the date the product expires on.
  • 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.
  • the use term years field, in operation 867, and the use term expiration date field, in operation 865 will be disabled.
  • 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 term years and use term expiration date fields will be cleared. However, if 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.
  • use term 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 specified 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.
  • 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.
  • 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. If the product does not have an annual frequency, then the user defines the frequency in operation 853. For 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.
  • 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).
  • operation 835 after determining the frequency in operations 830,
  • 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 points 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.
  • the standard is defined as 1000 points and an extra is defined as 100 points
  • a buyer could purchase 1200 points (1 standard + 2 extras); if no extra is defined, buyers are limited to purchasing 1000 points, 2000 points, etc., which are increments of the standard points product of 1000 points.
  • 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.
  • operation 805 If, in operation 805, discussed above, the user is not creating a new 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.
  • the product definition are implemented in a window and 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 be., 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. Membership
  • Membership is an optional or mandatory enhancement sold in conjunction with a widget. Memberships alter the usage right of the standalone widget. For example, the widget purchased alone may have usage rights at resort A exclusively. However, the same widget purchased with a gold 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.
  • the user selects the add-on membership icon from the main menu to start the operations of adding on a membership to a product.
  • the user selects a product to add a membership to.
  • the user determines if a new membership will be added to the product. If a new 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.
  • the user sets the membership price.
  • the membership price is the price of the membership for the specified renewal frequency.
  • 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.
  • 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.
  • the user may select to delete a usage right in which case the user selects a usage right that is deleted in operation 935a.
  • 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.
  • the user may select to end the add-on membership definition process in operations 950 and 950a.
  • the user may select a previously defined membership for the product in operation 955. Then, the user may choose to delete the membership in operation 960 or modify the membership in operation 965. If deletion is selected, then the previously selected membership is deleted in operation 960a and 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 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 15 in Figure 1.
  • SI Sales 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, be. , HI.
  • a block diagram illustrating the SI for the Sunbay Resort is shown in Figure 1 1 and discussed in more detail below. Note, the SI illustrated in Figure 1 1 is the same SI illustrated at reference numeral 1 10 in Figure 1.
  • 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 12 illustrates the exemplary hierarchical operations involved in defining HI and SI.
  • the HI and SI definition operations include: defining a resort or hotel in operation 1210; defining room types in operation 1220; defining rooms in operation 1230; defining unit types in operation 1240; defining units in operation 1250; and defining locations of interest that are near the resort, in operation 1260.
  • HI is primarily defined in operations 1210, 1220 and 1230 and SI is primarily defined in operations 1240, 1250 and 1260.
  • many of the attributes defined in the operations, especially those associated with operation 1210 are related to both HI and SI.
  • FIG 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 of rooms.
  • 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 1012 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.
  • room 105 (1018) is composed of two rooms, a two bedroom 105 A (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 105A (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.
  • the studio room type includes three rooms 105B (1038), 108 (1040) and 1 10 (1042).
  • FIG 1 1 is a block diagram illustrating an exemplary SI for the Sunbay Resort.
  • the Sunbay Resort 1002 SI has two unit types: three bedroom 1 104 and two bedroom 1 106.
  • the unit types each include associated units.
  • the three bedroom unit type includes unit 105 ( 1 108).
  • the two bedroom unit type includes unit 101 (1 1 10), unit 102 (1 1 12), unit 103 (1 1 14) and unit 104 (1 1 16).
  • HI results in, for example, a representation in the Tool of the
  • Main operations 1300a-1300g 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.
  • the user defines general information pertaining to the resort or hotel being setup.
  • 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 any entity with a timeshare interest.
  • 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.
  • 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.
  • the user defines a resort number.
  • the resort number is a unique number to identify the resort within the organization.
  • the user defines a resort code which is a unique code to identify the resort within the organization.
  • the user defines a resort name, e.g., "Sunbay.”
  • the user provides a description of the resort.
  • the user defines a planning horizon for the resort.
  • the planning horizon is the number of days in the planning horizon of the resort.
  • 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.
  • the user defines a historic horizon which is the number of days to hold historic hotel resort information.
  • the user defines a type.
  • 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 strictly a hotel - there will not be any timeshares.
  • a "both" value for the type means the resort is both a timeshare property and that it will also have transient guests.
  • main operation 1300b the user defines the clusters associated with the resort defined in main operation 1300a.
  • 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.
  • 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 the Sunbay Resort defined in operation 1302. Note, clusters are not defined for sales only resorts.
  • the user defines the cluster code which is a unique code to identify the cluster within the resort.
  • the user defines a cluster name, e.g. , "three bedroom.”
  • the user provides a description of the cluster being defined. For example, the description may be "three bedroom units.”
  • the user provides a display order which is the order to display values in a drop down window. For example, if unit 101 , 103, 102 and 104 are going to be presented in a window, then the display order presents them as 101, 102, 103 and 104 or as 104, 103, 102 and 101.
  • phase 1 may include 20 units and is built first.
  • Phase 2 includes 10 units and is built after phase 1 is complete.
  • 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.
  • the phase table includes a resort Id. This is the FK to the resort table. If the 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.
  • the user defines a phase code which is unique code to identify the phase within the resort.
  • the user names the phase currently being defined.
  • the user provides a description of the phase.
  • the user provides the display order which is the order to display values in a drop down window.
  • the user defines the buildings associated with the resort.
  • the table includes a building Id. This is the primary key of the building table. The building Id provides a linking mechanism to associate with other tables.
  • 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.
  • the user defines a building code which is a unique code to identify the building within the resort.
  • the user defines a building name.
  • the user provides a description of the building.
  • the user defines the floors associated with the buildings defined in operation 1300d.
  • the user defines a floor Id. This is the primary key of the floor table. The floor Id provides a linking mechanism to associate with other tables.
  • the user selects a building Id. This is the FK to the building table.
  • the user defines a floor code which is a unique code to define the floor within the building.
  • the user defines a floor name.
  • the user provides a description of the floor.
  • the user defines a display order which is the order to display values in a drop down window.
  • the user defines a proximity which is used to determine points of interest that are located near the resort.
  • 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.”
  • 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.”
  • the user defines a resort attribute. Exemplary resort attributes include a swimming pool and a gold course.
  • the user defines a code which is a unique code associated with the attribute.
  • the user names the attribute being defined, e.g. , "swimming pool.”
  • the user provides a description of the attribute.
  • Figure 14 illustrates the exemplary operations involved in setting up a room type for a HI resort.
  • the user defines a room type Id which is the primary key of the resort table.
  • the user specifies the resort Id of the resort that the room type is being defined for.
  • the user names the room type, e.g. , "3 Ocean” 1010.
  • the user specifies the cluster Id for the cluster that the room type being defined belongs to, e.g., "3 bedroom” 1004.
  • the user provides a room type code which is a unique code that used to identify the room type.
  • the user provides a description of the room type, e.g., "three bedroom with a master suite and an ocean view.”
  • 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.
  • the 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 1500a, 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 1500d, defining lock-off rooms in main operation 1500e, and providing room attribute information in main operation 1500f.
  • main operation 1500a the user defines general room information for the room being defined.
  • the user selects the resort that the room belongs to.
  • the user selects the cluster within the resort that the room is a part of.
  • the user selects the room type for the room being defined.
  • the user defines a room number of the room, typically the same room number that is on the door to the room.
  • the user names the room, e.g., the "Blue Room” or the "Victorian Room.”
  • the user provides a description of the room.
  • the user selects the building that the room is in.
  • the user selects the floor that the room is on.
  • the user selects the business entity that receives the revenue for the room.
  • main operation 1500b the user defines the sleeping arrangements for the room.
  • the user defines the number of beds in the room.
  • the user defines the number of people that the room can accommodate in non-shared accommodations in individual beds.
  • the user defines the number of people that the 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 room 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
  • the user defines the SI entities associated with the particular room being defined.
  • the user selects the resort name, e.g., "Sunbay” 1002, of the associated sales inventory unit, if applicable.
  • the user selects the associated timeshare unit type, e.g. , three bedroom 1 104, if applicable.
  • the user selects the associated SI timeshare unit, e.g., unit 105 (1 108).
  • main operation 1500d the user defines the occupancy information for the room.
  • operation 1530 the user defines the first day that the room can be occupied. For 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.
  • operation 1532 the user defines the last day that the room can be occupied.
  • main operation 1500e the user defines the lock-off status of the room.
  • a lock-off is a room that may be partitioned into smaller subdivisions with a lockable door separating the partitions.
  • room 105 (1018) is a lock-off
  • operation 1534 the user defines the room type that the room belongs to in the lock-off situation.
  • operation 1536 the user defines the rooms that belong to the lock-off Referring again to Figure 10, room 105A (1020) and room 105B (1022) belong to the lock off.
  • the user defines the room attribute information for the room.
  • the user is presented with a display of room attribute categories.
  • An example of a room attribute is view, e.g., "ocean” view and "golf view illustrated in Figure 10.
  • Other attributes include, for example, ski-out, in-room hot tub, and private master suite.
  • 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.
  • the table includes a unit type Id. This is the primary key of the unit type table.
  • the unit type Id provides a linking mechanism to associate with other SI tables.
  • 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 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.
  • 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 resort.
  • the user defines the unit type name which is the name given to the unit type being defined, e.g., "3 bedroom" 1 104.
  • the user defines the unit type description which is additional detail for the unit type.
  • the user defines the square footage for the unit type which indicates the size of the unit type.
  • Figure 17 illustrates the exemplary operations involved in defining a unit for SI.
  • main operation 1700a general unit information is defined
  • main operation 1700b the sleeping accommodations for the unit are defined
  • main operation 1700c SI to HI mapping information is defined
  • main operation 1700d unit attribute information is defined.
  • main operation 1700a in operation 1702 the resort that the unit is being defined for is displayed.
  • the user defines the unit type to which the unit belongs, e.g. , "3 bedroom.”
  • the user defines the unit number of the unit being defined, e.g., " 105.”
  • the user defines a name for the unit being defined, e.g. , "Presidential Suite.”
  • the user provides a short description of the unit being defined.
  • the user defines the check-in day for the unit.
  • 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.
  • the user defines whether the unit will have an escrow account associated with it the unit is attached to a contract during the contract inventory selection operations discussed below.
  • the user defines the total number of beds in the unit.
  • the user defines the total number of people that the unit will accommodate in non-shared sleeping accommodations.
  • 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.
  • the user defines the hotel room type, defined in operation 1400-1440, that this unit is a part of.
  • the selection of the resort in operation 1730 dictates the available room types in operation 1732.
  • 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.
  • FIG. 1736 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 (1 15) is mapped to unit 101 (120)of SI (1 10) and reference numeral 1738 shows that room 102 of HI (1 15) is mapped to unit 102 (172) of SI (110).
  • PRODUCT INVENTORY 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 of SI entities that may later be associated.
  • the product is selected via a dropdown datawindow that will list all defined products for the organization.
  • 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 multi-select specific SI entities to associate to the product.
  • the association operation creates the product inventory, i.e. , the set of timeshare widgets that may be sold.
  • the association operation creates the product inventory, i.e. , the set of timeshare widgets that may be sold.
  • the optional information 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 allotments 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.
  • 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.
  • the user defines a search criteria 1807 for the SI entities that may later be associated with the product.
  • the user selects a resort.
  • 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 any entities that match the product selected in operation 1805.
  • 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 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.
  • the user may select a unit type to search for.
  • the user selects the unit type, preferably from a list of available unit types.
  • the user may select a phase.
  • the user selects the phase, preferably from a list of available phases.
  • the user may select a building.
  • the building is selected, preferably from a list of available buildings.
  • the user may select a unit.
  • the unit is selected, preferably from a list of available units.
  • the operations 1805-1850 are preferably presented in drop down datawindows.
  • the lists of available 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 the selected resort. As a further example, if a two bedroom unit type 1 106 is defined as a search criteria in operation 1820, the units available for selection in operation 1850 are unit 101 (1 1 10), unit 102 (1 1 12), unit 103 (1 1 14) and unit 104 (1 1 16). The resort selection in operation 1810 is required because of the potential calendar conflicts between resorts. A common calendar is implied in a single association operation because time is one dimension of defining product inventory.
  • 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 1800. If SI entities are found matching the search criteria, then the Tool returns a list of all 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.
  • the same product cannot be associated to the same SI entity more than once.
  • the same SI entity may be associated to more than one product.
  • product 1 includes a two bedroom unit type 1106 and product 2 includes unit 101 (1110)
  • product 1 may only be associated to the two bedroom SI 1106 once.
  • 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.
  • 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.
  • 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 day time unit. For example, products with time units of 1, 2, 4, 6, 8, and 10 days or 3, 6, 15, and 21 days satisfy the lowest common factor requirement because all combinations of the time units are evenly divisible by 2 or 3 days respectively which are also both time units of the associated products. Products with time units of 1, 4, 6 and 12 days, however, cannot be associated to the same SI unit because the set does not satisfy the lowest common factor requirement.
  • FIG. 19 is a flowchart illustrating the exemplary operations involved in a product to SI association for non "pure points" products. At the conclusion of the non pure points product association operations 1910-1970 as set of widgets available for sale is defined.
  • the user may define a product calendar.
  • Default 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.
  • the user has the option of either using the default resort season definitions for the specified product's time unit or a specific product season calendar may be created.
  • any changes made to these default season definitions at the resort level will be validated against and applied to the products utilizing it.
  • the product defines its own season definitions, then the product specific calendar will be completely isolated from the resort calendar. Any changes made to the resort calendar will not be reflected in these products.
  • the product season definitions simply allow the user 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 seasons and the product cannot add additional seasons to the definition. It is simply an increment redistribution process.
  • 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.
  • 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.
  • 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.
  • a SI unit can be associated with multiple products that define their own set of maintenance increments.
  • a specific SI unit' s complete maintenance definition is the union of all product and SI unit defined maintenance increments.
  • 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.
  • 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 as a maintenance increment. 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.
  • the user may define time allocation details for fractional products.
  • Products with a usage type whose 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.
  • 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 accounted for in a fraction definition as a fixed component, the number of increments in the year that are accounted for in a fraction definition as a floating component, the number of increments in the year that are accounted for in a fraction definition as either a fixed or floating component, the name of the fraction for 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 fraction, 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
  • operation 1944 the user selects the name of the fraction that will be defined.
  • the user 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 for the fractional product are updated. If the user is satisfied with the fractional product defined the user may save the product.
  • Figure 6b shows a table with four fractional products. For example, the time dimension for the fractional 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).
  • the user may initialize the pricing and points attributes for the product.
  • the Tool tracks and maintains 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 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 points 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.
  • 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.
  • 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").
  • IFDS is the first date that the piece of product inventory can be sold.
  • IFU similarly determines the first date that the piece of product inventory is available for use by a member or owner.
  • the user may initialize the business entities.
  • 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.
  • 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 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 be able to implement the 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 account receivables ledger.
  • the maintenance fee accounts receivable ledger tracks maintenance fee receivables.
  • the servicer determines the business entity that is associated with 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 management subsidiary ledger.
  • Figure 20 illustrates the exemplary operations involved in a "pure points" product association.
  • 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.
  • the resort must define 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 valid allotments less the maintenance points, rather than the total points less the maintenance points.
  • the user is presented with 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 that the resort has set aside as maintenance points, the difference between the total points and maintenance points, i.e., the number of points available for sale, the name of the specified allotment, the amount of points that will be brought on-line as part of the allotment, and the date that the specified allotment becomes available for use.
  • the user may then add, delete or modify the existing allotments.
  • 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 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 points 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.
  • 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 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 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 servicer determines the business entity that is associated with each widget its servicer. The servicer bills and collects reservations fees and owns the miscellaneous member services accounts receivable and accounts payable 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 operations 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.
  • contract refers to the rights in a widget that a timeshare owner has purchased.
  • 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.
  • contract inventory selection includes the following operations: entering search criteria, obtaining a list of inventory that matches the search criteria, selecting items to apply 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.
  • operation 2102 the user selects the resort that the contract owner is searching inventory for.
  • operation 2104 the user selects the product that the contract owner is searching inventory for.
  • the resort and product selection operations 2102 and 2104 are preferably mandatory.
  • the following operations 2106 - 2120 further define the search criteria. However, operations 2106 - 2120 are preferably optional.
  • operations 2106 and 2108 the user may select the phase that the contract owner is searching inventory for.
  • operations 2110 and 2112 the user may select the building that the contract owner is searching inventory for.
  • operations 21 14 and 21 16 the user may select the unit that the contract owner is searching inventory for.
  • operations 2118 and 2120 the user may select the week that the contract owner is searching inventory for.
  • Operations 2102 - 2120 define the search criteria.
  • 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 results of a search is provided in Figure 21a. Numerous attributes associated with the inventory are displayed, including: the resort 2124a, the phase 2124b, the building 2124c, the unit 2124d, the increment 2124e, the frequency 2124f, the availability 2124g, the owner first use date 2124h, and the quantity for purchase 2124i.
  • the user selects the inventory to associate with the contract.
  • the selected inventory is "ProductX” (2126a) which is a "fixed/fixed” product including "unit 201/weekl" at
  • 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.
  • 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 points package. For example, if two 1000 points packages are selected, then 2000 total points are added.
  • the user defines the owner first use date which is the first date the owner can use the widget.
  • the user defines the quantity for purchase.
  • the user may release the inventory to the contract. If the inventory is released, the inventory released is no longer available sales inventory.
  • Selling rules are determine what inventory can be sold. Fop example, a rule selling rule can require that for every five 1 bedrooms that are sold a three bedroom must be sold. Accordingly, if the sixth 1 bedroom is searched for before the first three bedroom is sold, then the search will not return a match.
  • Selling preferences is the order that the inventory is presented for selection. For example, if one match is from a new phase and four matches are from an older phase, then the older phase matches may be presented first in order to sell out the old phase before beginning to sell the new phase.
  • the inventory management navigation module (hereinafter "IMNM") is a central launching point for the operations discussed 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, e.g. , resort, cluster, room type, and room, in a hierarchical treeview display.
  • 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.
  • 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 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.
  • the IMNM includes three main menu selections: inventory management, product, and inventory.
  • 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.
  • all other operations of the Tool may be accessed through this menu.
  • the product menu allows the user to define the various products that are supported 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 sold and hence required to support timeshare functionality.
  • the inventory menu allows the user to interact with the various inventory entities - HI, SI and PI. Finally, the inventory menu also allows the user to initiate blocking and overbooking which are discussed in more detail below.
  • the following windows illustrate the preferable implementation of the three main IMNM menu selections.
  • the windows shown in Figures 22, and 22a - 22g exemplify the preferable GUI implementation of the various operations described herein and 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 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 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 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 2210a.
  • Figure 22c illustrates the window that is presented if the HI link 2210b is selected in the inventory management drop down menu 2210a.
  • the HI window includes a list of the defined hotel inventory 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 of the resort 2230c and the name of the resort 2240c, amongst other attributes, as defined in main operations 1300a - 1330g discussed in conjunction with Figure 13.
  • 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 window includes a list of the defined sales inventory 2210d.
  • the user may select one of the defined SI at which time associated attributes 2220d, such as resort information 2230d, are also displayed.
  • time associated attributes 2220d such as resort information 2230d
  • various operational links 2240d 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 223 Oe, are also displayed. Like the HI and SI window, various operational links 2240e are provided along the top of the window, including a 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 221 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 223 Of 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 do not fit into space/time 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 definition operations 1300 - 1372, a link 2220g to the unit type definition operations 1610 - 1660, and a link 223 Og to the unit definition operations 1700 - 1738.
  • An owner of a timeshare widget is granted rights to specific intersections of time and space depending upon the usage rights of the specific widget that was purchased.
  • 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.
  • 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.
  • the reservation and usage window attributes, defined in operations 720-735, of a usage right will change according to the implied dates of the specific product inventory widget's time increment, be., weekl .
  • the generation of resolved usage rights from the usage rights provides the owner with the ability to actually use their purchases.
  • 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 points-based products. For these points owners, other points accounting sub-processes are executed prior to their rights becoming effective and usable.
  • the operation of resolving usage rights must also execute some or all of the following points accounting tasks if the associated product inventory being resolved is points based: initialize 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 "URR") operation will be executed for all "active" contracts, i.e. , for all existing timeshare widgets that have been purchased and are still active, and contracts that have been canceled after the last time the operation was executed.
  • "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).
  • the 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.
  • the user may initiate the URR operation as an immediate action from a manual triggering mechanism.
  • FIG 23 illustrates the preferably operations involved in the URR operation.
  • the URR operation determines all contracts that have attained the 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.
  • usage rights are resolved. 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 timeshare inventory.
  • the Tool will determine the set 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").
  • 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 that 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 2310a 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 all 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.
  • 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.
  • the logical relationship is an OR.
  • the row referred to by reference numeral 2330a is a product inventory widget from a fractional product.
  • the date keywords "fraction” and “increment” will potentially return a set of dates, one for each contiguous set of fixed time increments that comprise the fraction and one for each floating increment that comprise the fraction.
  • Fractional product owners have a right to use the entire fraction and not just a single increment bounded by the fraction definitions.
  • the owner will have rights to all of the resolved usage rights records in this case.
  • the logical relationship is an AND between all fixed increment resolutions and the set of floating increment resolutions.
  • 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 2340a is a pure points product. Pure points usage rights imply usage across all resorts in the 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 owner. All other cases detailed above in the table of Figure 23 a are preferably invalid combinations and are not defined within the Tool. All 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.
  • 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 essentially 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 ("PAL").
  • 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.
  • the "reserves" account 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.
  • the RUR operation allocates points to new owners or members. As new sales occur, points need to be allocated to their owner/member 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.
  • PMSL points management subsidiary ledger
  • 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 to the owner/member 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 account(s) 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 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 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 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
  • 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.
  • PMSL points management subsidiary ledger
  • 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 points” 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 account(s) are inactive, then an error will need to be logged to the scheduler log files and the component existing owner/member allocation process 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 component existing owner/member allocation process for the current contract will be rolled back to its previous states.
  • 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 to track total points for the specified usage period in the PAL.
  • 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 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.
  • the RUR operations adjusts the usage period end.
  • the PAL account balances must be adjusted to close the period.
  • the following entries are posted to: debit the points "reserves” accounts to zero the points balance for remaining "unused” or “unallocated” points 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 is user-defined and carries a status.
  • the RUR operation executes the cancel contract points operation.
  • the system will determine the set of contracts that have been canceled since the last execution of the process. This set of freshly canceled contracts will serve as the driving factor of the cancel points component process.
  • all point transactions in the owner/member account for that contract with the exception of a "Rent" transaction needs to be reversed.
  • the transactions in the PAL that are tied to that contract also needs to be reversed.
  • Extended exchange transactions refer to a two phase expiration of points. At the end of each usage period, a member's points expire. However, for some organizations these points don't truly expire completely from the system. The member's expiring points are transferred from allocated points to extended usage points. Extended usage points have a life span defined by a business policy. They are valid for the period defined by the business policy, starting on the date the allocated points expired. These extended usage type of points may have restricted usage capabilities depending upon how the business policies have been defined. This component process is probably triggered by the component expire points process to ensure that all extended usage occurrences are properly handled by the system.
  • the Tool also allows split definitions.
  • a split definition allows a member to change their resolved usage rights into many resolved usage rights with different check-in-days and length-of-stays. For 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 check-in-days and length-of-stays that total the time increment.
  • Hotel inventory control manages the usage of hotel inventory for purposes of reservations and inventory blocks.
  • HI is setup and maintained at four 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 grouping of rooms with similar attributes. For example, all two bedroom rooms or all ocean view rooms may be grouped together as a room type.
  • a room is defined in the Tool as the physical piece of inventory available for rent.
  • the Tool includes a reservation system that allows an agent to confirm reservations at all levels of defined inventory. Reservations may be confirmed at four different levels: run of house (“ROH”), run 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. , room type, or any special price attributes, e.g. , cluster.
  • a ROC reservation means that a guest is given a confirmation that they will have a room in an agreed cluster, i.e., pricing group, at check-in. The guest does not require any special room attributes.
  • a ROT reservation means that a guest is given confirmation that they will have a room in an agreed upon room type at check-in.
  • 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 specific 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 availability 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” signifies 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.
  • 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.
  • 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 operations involved in defining overbooking amounts.
  • operation 2510, operation 2520, and operation 2530 the user selects the resort, cluster and room type respectively to define overbooking amounts for.
  • the user selects the beginning date of a range of time that the overbooking limit is going to be assigned to.
  • the user selects the end date for the range of time that the overbooking limit is going to be assigned to.
  • the user sets the overbooking limit for the range specified.
  • the user may select to exclude particular dates from the range for which the overbooking limit will not be applied.
  • Figure 25a illustrates the current availability for an exemplary resort "R,” with two clusters “CL1” 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 numbers 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.
  • Figures 25a - 25e The following three scenarios refer to Figures 25a - 25e to illustrate the effect of overbooking on availability.
  • Figure 25a in scenario one, when a reservation is requested for RT2, then RT2 has 1 available, Cl has 1 available, and R has two available therefore no overbooking rules are required because there is availability at all levels. Accordingly, RT2 is decremented, Cl is decremented and R is decremented. The resulting availability is illustrated in Figure 2c.
  • RT2 is no longer available because it was reserved in scenario one. Accordingly, overbooking for RT2 is checked. Referring to Figure 2b, RT2 may be overbooked by 2. Therefore, the availability for Cl is checked. Cl is not available Referring to Figure 2b, Cl may be overbooked by 2 Therefore, the availability for R is checked R has availability, therefore, the reservation for RT2 is taken and RT2, Cl and R are decremented The resulting availability is illustrated in Figure 25d In scenario three, a reservation is requested for RT3 Referring to
  • 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 for 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 not 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 blocking functionality is primarily used to guarantee availability to particular guests such as timeshare owners, conferences and marketing promotions
  • Blocking may also be used to restrict certain pieces of inventory from being used by anyone if, for example, the piece of inventory is scheduled for remodeling Blocks are definable at any reservation level, including ROH, ROC, ROT and room
  • a block includes a block definition and the assigned inventory
  • the block definition defines the resort the block is defined at, a unique block code for the resort, a description and block expiration information Inventory can be assigned at any level a reservation can be made, ROH, ROC, ROT, or room level
  • Each assignment of inventory will determine if the block will contain sustained or daily availability and the amount of inventory to block
  • the actual amount of inventory to be blocked depends on a block number, an authorize number, and a forecast number entered by the user at inventory is assigned to the block
  • the block number is the actual amount of inventory to remove from general availability
  • the authorize number is the maximum number of reservations that can be reserved against the block
  • the forecast number is a best guess entered by the user as to what will be actually used
  • Figure 26 illustrates an exemplary window implementation for assigning inventory to a block
  • the window includes the following drop down datawindow ("DDDW") fields utilized by the user to assign inventory to a block "Block Code" 2610, "From Date” 2615, "To Date” 2620,
  • the block code field 2615 uniquely identifies 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 the 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 select 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
  • the room field 2665 allows the user to select the room to assign to the block Reservations
  • Figure 27 illustrates the exemplary operations associated with processing a call from a member prior to making a reservation for a timeshare
  • the agent obtains 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
  • the agent is presented with information about the member including whether the members has any outstanding account balances, whether the member is a current or active member
  • 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 exchange options, settle any financial obligations, update contact information, inquiry about their membership, view points information and log complaints
  • the agent determines if the members seeks to make a fixed time reservation, a floating time reservation or a points reservation, in operations 2702a, 2704a and 2706a
  • operations 2708a - 2728a are performed.
  • the member specifies a time for the reservation
  • the agent searches for the specifies time If the time is not available, then the member may request a new time If the time is available, then payment processing is initiates in operation
  • the Tool determines if the member's financial obligations are resolved If not, then the reservation operation is terminated in operation 2718a If the member is good financial standing, then the inventory according to the time selected is decremented in operation 2720a In operation 2722a, the agent books the reservation In operation 2724a, the agent gathers any additional member information that may be required or desired In operation 2728a, the members usage rights are updated according to the reservation made.
  • the member 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 2740c. 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.
  • 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.
  • 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 must pay the fee in operation
  • the Tool determines if there is a process payment associated with the reservation. If there is a process payment, then payment processing is initiated in operation 2736c. In operation 2738c, the Tool determines whether the member resolved any outstanding payment obligations. If not, then the availability is released and any payments corresponding to the reservation are reversed in operation 2740c. If the customer did resolve any financial obligations or there was not a process payment, then the Tool process the delinquency policy in operation 2742c. If the delinquency process fails, then the member is asked to submit payment in operation 2746c. If the user does not submits a payment, then the delinquency policy hits a fatal level and the availability is released and the any payments corresponding to the reservation are reversed in operation 2740c.
  • 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.
  • the reservation is booked.
  • the agent gathers additional member information.
  • actions are generated.
  • usage rights for the member are updated. The member is then able to use the timeshare reserved.
  • the member may enter a request in operation 2702e.
  • 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 2720e 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.
  • 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 2715e. If the member passes the rules, then the Tool verifies that the member has enough points for the hold performed in operation 2710e. If the member does not have enough points, then the member may borrow points in operation 2730e or rent points in operation 2732e. If the member does not borrow or rent points, then the inventory held is released and the member may make an additional request in operation 2724e or end the reservation process. If the member has enough points, borrows points, or rents points, then the Tool determines if there is a transaction fee in operation 2738e.
  • the agent may override the fee is operation 2740e. If the fee is not overridden, then the member pays the fee.
  • the Tool determines if there are any payments to process. If so, the payments are processed in operation 2746e. In operation 2748e, the Tool determines if the customer resolved any outstanding financial obligations. If not, then the availability is released and any payments are reversed.
  • 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 in operation 2750e. If the payment is collected or the delinquency policy does not fail, then the validation rules are processed in operation 2760e.
  • the Tool includes points rate definition which allows the Tool to define nightly point rates for use in the reservation process.
  • Members with a points usage right and a points reservation policy associated with the usage right can request a reservation for a piece of inventory.
  • the arrival date and length of stay will determine the availability of the inventory and then the point rate associated with the reservation.
  • the rates are defined for a hotel cluster and weekend night combination.

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Tourism & Hospitality (AREA)
  • Marketing (AREA)
  • Quality & Reliability (AREA)
  • Economics (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Human Resources & Organizations (AREA)
  • Manufacturing & Machinery (AREA)
  • Operations Research (AREA)
  • Development Economics (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

L'invention concerne un procédé et un outil logiciel prévus pour développer, vendre, utiliser et gérer des multipropriétés. Dans l'étape de commercialisation et de ventes de multipropriétés, les produits sont créés en définissant des types d'utilisation (150) pour chaque produit et en définissant les droits d'utilisation (155) associés à chaque type d'utilisation (150). Le type d'utilisation peut présenter une composante dimension d'espace, et/ou une composante à base de points. Un inventaire d'hôtels (115) est élaboré en se fondant sur des informations relatives aux chambres, types de chambres et villégiatures.
PCT/US2000/010492 1999-04-19 2000-04-19 Outil logiciel pour la gestion de multiproprietes WO2000063794A1 (fr)

Priority Applications (3)

Application Number Priority Date Filing Date Title
EP00922300A EP1112540A1 (fr) 1999-04-19 2000-04-19 Outil logiciel pour la gestion de multiproprietes
AU42505/00A AU4250500A (en) 1999-04-19 2000-04-19 Software tool for management of timeshare properties
CA002339065A CA2339065A1 (fr) 1999-04-19 2000-04-19 Outil logiciel pour la gestion de multiproprietes

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US13007999P 1999-04-20 1999-04-20
US60/130,079 1999-04-20
US09/553,238 2000-04-19

Publications (1)

Publication Number Publication Date
WO2000063794A1 true WO2000063794A1 (fr) 2000-10-26

Family

ID=22442957

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2000/010492 WO2000063794A1 (fr) 1999-04-19 2000-04-19 Outil logiciel pour la gestion de multiproprietes

Country Status (2)

Country Link
AU (1) AU4250500A (fr)
WO (1) WO2000063794A1 (fr)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8380602B2 (en) 2009-07-21 2013-02-19 Cfph, Llc Exchange for fractional interests and usage rights in a collection of assets
US9230235B2 (en) * 2012-11-09 2016-01-05 Accenture Global Services Limited Room inventory management
WO2016103265A1 (fr) * 2014-12-26 2016-06-30 Splitty Travel Ltd. Système et procédé permettant d'optimiser l'utilisation d'un ensemble d'installations physiques sous-utilisées telles que des installations touristiques
US11481694B2 (en) 2015-07-26 2022-10-25 Holisto Ltd Split vacation deal generating server and efficient split deal generating methods

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
DATABASE BUSINESS WIRE (610) [online] 21 June 2000 (2000-06-21), "WorldRes.com Adds Six Automated Interface Partners", XP002947419, accession no. DIALOG Database accession no. 20000621173B6528 *
DATABASE GALE GROUP NEWSWIRE [online] 29 October 1997 (1997-10-29), "Signature resorts announces agreement to acquire global development ltd. European vacation ownership Business for $18 million cash", XP002947420, accession no. Dialog Database accession no. 19933070 *
WORCESTER BARBARA A.: "Internet to play critical role in property management", HOTEL & MOTEL MANAGEMENT, vol. 15, no. 2, 7 February 2000 (2000-02-07), pages 1, XP002947488 *

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8380602B2 (en) 2009-07-21 2013-02-19 Cfph, Llc Exchange for fractional interests and usage rights in a collection of assets
US9230235B2 (en) * 2012-11-09 2016-01-05 Accenture Global Services Limited Room inventory management
WO2016103265A1 (fr) * 2014-12-26 2016-06-30 Splitty Travel Ltd. Système et procédé permettant d'optimiser l'utilisation d'un ensemble d'installations physiques sous-utilisées telles que des installations touristiques
US11481694B2 (en) 2015-07-26 2022-10-25 Holisto Ltd Split vacation deal generating server and efficient split deal generating methods
US12008489B2 (en) 2015-07-26 2024-06-11 Holisto Ltd Split vacation deal generating server and efficient split deal generating methods

Also Published As

Publication number Publication date
AU4250500A (en) 2000-11-02

Similar Documents

Publication Publication Date Title
US7328166B1 (en) Global reservations transaction management system and method
Ménard 17. Enforcement procedures and governance structures: what relationship?
US20080021746A1 (en) System and method for airline purchasing program management
US20060010023A1 (en) System, method and computer program product for managing meeting planning operations
US20140122346A1 (en) Method, apparatus, system, and computer readable medium for leasing space
JP2005500611A (ja) １以上の商品目録項目の予約リクエストを管理するシステムおよび方法
JP2005500609A (ja) １以上の商品目録項目の予約リクエストを管理するシステムおよび方法
Gil et al. Using revenue sharing to implement flexible prices: Evidence from movie exhibition contracts
US20060149586A1 (en) Lodging attribute inventory
Kaganova et al. Guidebook on real property asset management for local governments
US20050137934A1 (en) Property management solution
JP4898086B2 (ja) 賃貸不動産情報管理システム
Zhang et al. Two-sided pricing strategies for a parking sharing platform: Reselling or commissioning?
US20210279756A1 (en) System for dynamically optimizing the income of a service provider
AU2021201972A1 (en) A computer-enabled method, system and computer program for the management of a multi stage transaction including management of a booking and service delivery process
AU2021202226A1 (en) A computer-enabled method, system and computer program for providing an intuitive user interface arranged to create a dynamic floor plan utilisable by an allocation algorithm to perform the task of managing a function or event
WO2000063794A1 (fr) Outil logiciel pour la gestion de multiproprietes
WO2000043927A2 (fr) Procede et systeme de gestion globale d'operations de reservation
EP1112540A1 (fr) Outil logiciel pour la gestion de multiproprietes
CA2339065A1 (fr) Outil logiciel pour la gestion de multiproprietes
JP4087484B2 (ja) 組織内協調システム及びコンピュータ読み取り可能な記録媒体
US20160210565A1 (en) Revenue-optimized opaque bookings
EP3048567A1 (fr) Réservations opaques à revenu optimisé
Partnerships Content
CA2820206A1 (fr) Systeme et methodologie d'optimisation d'un reseau mise en oeuvre sur ordinateur

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY CA CH CN CR CU CZ DE DK DM DZ EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG US UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GH GM KE LS MW SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

ENP Entry into the national phase

Ref document number: 2339065

Country of ref document: CA

Ref document number: 2339065

Country of ref document: CA

Kind code of ref document: A

WWE Wipo information: entry into national phase

Ref document number: PA/A/2000/012743

Country of ref document: MX

121 Ep: the epo has been informed by wipo that ep was designated in this application
WWE Wipo information: entry into national phase

Ref document number: 2000922300

Country of ref document: EP

Ref document number: 2001/00582

Country of ref document: ZA

Ref document number: 509468

Country of ref document: NZ

Ref document number: 200100582

Country of ref document: ZA

WWP Wipo information: published in national office

Ref document number: 2000922300

Country of ref document: EP

REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

NENP Non-entry into the national phase

Ref country code: JP

WWW Wipo information: withdrawn in national office

Ref document number: 2000922300

Country of ref document: EP