EP1214672A4 - Verfahren zum verarbeiten von reservierungsanzahlungen - Google Patents

Verfahren zum verarbeiten von reservierungsanzahlungen

Info

Publication number
EP1214672A4
EP1214672A4 EP00936298A EP00936298A EP1214672A4 EP 1214672 A4 EP1214672 A4 EP 1214672A4 EP 00936298 A EP00936298 A EP 00936298A EP 00936298 A EP00936298 A EP 00936298A EP 1214672 A4 EP1214672 A4 EP 1214672A4
Authority
EP
European Patent Office
Prior art keywords
reservation
visitor
processing
date
fee
Prior art date
Legal status (The legal status 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 status listed.)
Withdrawn
Application number
EP00936298A
Other languages
English (en)
French (fr)
Other versions
EP1214672A1 (de
Inventor
Paul G Martin
Bradley Y Matsuda
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Passkeycom Inc
PASSKEY COM Inc
Original Assignee
Passkeycom Inc
PASSKEY COM 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 Passkeycom Inc, PASSKEY COM Inc filed Critical Passkeycom Inc
Publication of EP1214672A1 publication Critical patent/EP1214672A1/de
Publication of EP1214672A4 publication Critical patent/EP1214672A4/de
Withdrawn legal-status Critical Current

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Administration; Management
    • G06Q10/02Reservations, e.g. for tickets, services or events

Definitions

  • This invention provides a method of processing guest hotel room reservation deposits, and making refunds for cancelled hotel reservations for conventions and similar events. More specifically, the invention provides a method by which a single entity can service multiple prospective guests making reservations among multiple hotels in connection with a convention or similar event, and can provide reservation status information to the guests and hotels, the convention sponsor, meeting planners, housing managers, and other personnel having a need for such information.
  • the present invention overcomes the above described shortcomings of the prior art in providing a method of processing reservation deposits including storing, in a computer memory, data describing a plurality of rooms, the data comprising a quality classification for each room indicative of a class of visitors to whom reservations of said room are to be limited, and an inventory code for each of a plurality of dates indicative of whether or not the room is available for occupancy on each of the dates.
  • data describing a reservation request made by the visitor including a visitor class code assigned to the visitor, data indicating the stay dates for which at least one room is sought to be reserved by the visitor, and data identifying a financial institution and account therein from which collection of a deposit to secure the visitor's reservation may be made.
  • the visitor class code is compared with the quality classification for each room having an inventory code indicating that the room is available for each of the dates for which the reservation is sought.
  • the inventory code for the room is changed to indicate that it is no longer available, the room being reserved to the visitor,
  • a collection request is generated for collecting the visitor's deposit payment from the financial institution.
  • a transfer of funds to the hotel is initiated on a funds transfer date, the funds being equal in amount to a portion of the deposit from which there is excluded a processing fee.
  • a database with records of reservation requests and respective deposit payment offers is maintained.
  • a comparison is made of the present time and a predetermined time for processing the reservation deposits and, if the present time is equal to or greater than the predetermined processing time, for each record of a reservation requested by a visitor, a collection request for transferring funds from a financial institution in which an account has been opened for the benefit of the visitor for payment of the deposit is initiated.
  • the time of the request is compared with the processing time, and from the comparison a determination is made as to whether a refund is due in response to the cancellation.
  • a processing fee which is a function of the elapsed time between the processing time and the cancellation request time is subtracted from the deposit .
  • the present time is also compared with a predetermined funds transfer date later than the close time, and if the present time is later than the close time, a fund transfer request for transferring funds to a financial institution in which an account has been opened for the benefit of the beneficiary merchant is initiated.
  • Fig. 1 is a schematic diagram showing the communication paths between attendees of an event and a commerce processor for performing the method of the preferred embodiment of the invention.
  • Fig. 2 is a flow diagram depicting steps of the method of the preferred embodiment of the invention.
  • Fig. 3 is a graph of events versus time for the processing of deposits in accordance with the method of the preferred embodiment of the invention.
  • Fig. 4 is a graph of events versus time for the processing of cancellation refund requests in accordance with the method of the preferred embodiment of the invention.
  • Fig. 5 is a chart showing the relationship among modules of a computer program for performing the method of the preferred embodiment of the invention.
  • Fig. 6 is a schematic block diagram of a module of the computer program illustrated to in Fig. 5.
  • Fig. 7 is a schematic block diagram of another module of the computer program illustrated to in Fig. 5.
  • Fig. 8 is a schematic block diagram of still another module of the computer program illustrated to in Fig. 5.
  • Fig. 9 is a schematic block diagram of a further module of the computer program illustrated to in Fig. 5.
  • Fig. 10 is a schematic block diagram of a still a further module of the computer program illustrated to in Fig. 5.
  • Fig. 1 of the drawings individual attendees or their agents can make hotel reservations by communicating with a central reservation and deposit management facility operated under the control of a software-based reservation management system, sometimes hereinafter referred to as a commerce processor.
  • the commerce processor is capable of processing reservation deposits, which includes both payments and refunds.
  • the computer program automates the process of authorizing credit cards used as a deposit in reserving a hotel room as well as initiating the transfer of funds from the payment processor to the specified merchant.
  • the program also reports all failed transactions, which may then be investigated and resolved.
  • Communication with the reservation facility can take any form including telephone, fax, email or even personal visit to the central reservation facility. However, the most advantageous form of communication will be by accessing the central reservation facility's web site on the Internet .
  • Attendees may be of different classes, each of which will receive correspondingly different treatment in accordance with business rules usually promulgated by the convention sponsor. For example attendees may be respectively classified as general conference attendees 11, very important (VIP) conference attendees 13, and conference speaker attendees 15.
  • VIP very important conference attendees
  • Requests for reservations received in the central reservation and deposit management facility, orally or in writing, are converted into machine readable form.
  • requests for reservations received in the central reservation and deposit management facility are made by the visitor or attendee, or an agent, completing a form on a web page that is accessible on the Internet, thereby ensuring compatibility with the central reservation and deposit management facility software.
  • These forms are provided with the necessary menus and controls, e.g., check boxes, dropdown lists, combo boxes and the like as will be known to those skilled in the art.
  • Rules for data entry such as field sizes, capitalization, punctuation are enforced at the form level and necessary conversions of obvious errors can be made to ensure consistency with the input data requirements of the commmerce processor software.
  • Reservation requests from the various classes of attendees, in machine readable form, are stored in a reservation database accessible by a computer on which the commerce processor program resides .
  • Each reservation in the master reservation system is entered into a commerce transaction process table for processing on dates which will normally be predetermined for each event that is being attended. Referring to Figs. 3 and 4, reservations are accepted over a continuous range of dates beginning with a reservation open date and ending with a close date after which reservations are no longer accepted and deposit refunds are no longer made.
  • the commerce processor program credits its operator with two payments for each reservation.
  • the first payment is earned, on all reservations, on a predetermined date subsequent to the reservation open date .
  • the second payment is a processing service charge which is earned when the deposit payment is processed for collection on a predetermined date subsequent to the deposit fee date. No processing fee payment is earned on reservations cancelled before the processing fee date.
  • the commerce processor software cyclically compares the current date with the predetermined deposit fee date, processing fee date, close date, and a funds transfer date for each reservation and performs the actions scheduled for those dates .
  • Each record of a reservation requested in connection with the event is selected from the commerce transaction process table. If payment of the reservation deposit by credit card has been requested, an authorization request is constructed and transmitted to a clearing house for such requests. A record of the authorization request is entered into a commerce transaction history table.
  • a corresponding authorization response request is then received from the clearing house.
  • the commerce processor software tests the response and, if a credit card charge authorization has been granted, an order to charge the deposit to the credit card account is constructed and retransmitted to the clearing house.
  • the clearing house transmits an acknowledgement of the credit card charge order to the reservation facility which is reported to the commerce processor software.
  • the commerce processor software In response to a successful acknowledgment, the commerce processor software then causes a confirmation of the reservation to be transmitted to the attendee by email .
  • the commerce processor software tests for whether there are more reservations to be processed and, if there are, repeats the foregoing procedure. If there are no more reservations, processing is halted until another reservation is received.
  • Reservations may be received before and after the processing fee date. Reservations received before the processing fee date are batch processed on the processing fee date. Reservations received after the processing fee date are generally individually processed substantially immediately after receipt.
  • a record of the failed transaction is entered into a daily log by the commerce processor software. Manual follow-up of failed authorization requests and charge acknowledgements can be done at a terminal from which the commerce transaction history table and failed commerce transaction log can be accessed.
  • the commerce processor software includes a group inventory manager module 17.
  • the group inventory manager module 17 is connected to a database containing hotel inventory records 19 each of which can be associated with a hotel room.
  • the rooms can be categorized into blocks, each block being preassigned to different type or class of attendees. That is one block may be assigned for occupancy by general attendees 11, another block for VIPs 13 and a third block for speakers 15.
  • Inventory is broadly categorized as “available” or “booked. " As each room reservation is accepted, one or more fields of each relevant record in the inventory database is updated to reflect the assignment of a room to the reservation. Assigned rooms are classified as “booked” and removed from the blocks of rooms available for assignment to fill future reservations.
  • the group inventory manager module 17 receives requests for inventory from multiple classes of possible attendees, filters available inventory and offers only inventory that complies with business rule constraints in the database, allocates inventory based on business rules for attendee class, length of stay and number of guests, imposes and discloses constraints on cancellation, updates the information in an inventory configurator module 21, and receives messages from a payment controller module 23.
  • an inventory configurator module 21 of the commerce processor program code is provided with data specifying the number and quality of rooms available at each hotel property participating in the convention. Data may also be provided ranking each hotel property in accordance with desirability, taking into account such factors as distance to convention events, condition of physical plant, and amenities offered to guests.
  • the inventory configurator module 21 allocates a different attendee code to each class of attendee. Depending on the size of the convention, the inventory configurator module
  • the 21 may assign individual rooms or blocks of rooms for occupancy by different classes of attendees .
  • a minimum number of nights for which each room or block of rooms may be reserved is designated by the inventory configurator module 21 as a function of the class of attendee, i.e., attendee code, for which the room or block of rooms has been allocated.
  • the number of guests who are to occupy each room is also designated by the inventory configurator module 21 as a function of attendee code corresponding to the room, or the block of rooms or which it is a member.
  • different rooms or blocks of rooms may be removed from the participating hotels' regular inventories of rooms available to the general public, for different ranges of dates. For example, it may be desired to have VIPs 13 arrive earlier than other attendees to participate in special functions. Or, speakers 15 who are only giving presentations over one or two days of a longer convention may require rooms for a briefer range of dates than other attendees.
  • the inventory configurator module 21 receives business rules and applies the rules to each block of rooms as a function of the codes of the attendees respectively/ assigned to the block of rooms.
  • Room rates can also be assigned by the inventory configurator module 21 to each block of rooms according to the class of attendees to whom the rooms are assigned. For example, the rooms occupied by speakers 15 may be paid for by the convention sponsor and allowed a discount in accordance with the convention sponsor's contract with the hotel (s) .
  • the group inventory control manager module 17 arbitrates requests for reservations from, and assignment of rooms to, attendees. The group inventory manager module 17 receives reservation requests from multiple classes of attendees, and their agents, upon their transmission to the central reservation facility.
  • the group inventory manager module 17 Upon receipt of a reservation request, the group inventory manager module 17 interrogates the room inventory database in accordance rules stored in the inventory configurator module 21. That is, the room inventory is filtered in accordance with the class of attendee for whom a reservation is requested and the pool of unassigned rooms. Other factors used in filtering the room inventory may include the type and length of stay for which a reservation is being sought, that is the number of nights and beginning date of the stay, and the number of guests who, with the attendee, are to occupy the reserved room(s) .
  • the requester is offered a room only from those blocks of rooms which have been allocated to attendees of the requester's class, that is those rooms associated with the attendee code of the reservation requester, the requested time and type of stay, and the number of guests sharing the room(s) . Cancellation terms and penalties applicable to the class of attendee are also disclosed to the reservation requester at the time that the reservation is booked.
  • the group inventory manager module 17 communicates directly with the inventory configurator module 21 to apply the business rules governing the reservation of rooms to the attendees for whom reservations are sought.
  • the commerce processor software includes code for processing reservation deposits.
  • the payment controller includes payment configurator code in which there are stored business rules governing the handling of reservation deposits, authorizations and refunds.
  • the payment controller has payment configurator code which determines the processing fee dates for each of the types of transactions, i.e., credit card authorizations, collection of deposits by initiating charges to credit cards or depositing checks for collection, and issuing of credits to credit cards for refundable cancellations.
  • the payment controller has credit card controller code for transmitting charge and credit transaction requests to an electronic payments system, and check controller code for transmitting requests for collection of deposits made by check to a banking system.
  • the payment controller module 23 can have stored within it, for each class of attendee, a plurality of dates in the cycle of the processing of a payment listed in chronological order as follows:
  • Reservation Open Date The date when reservations can first be made for an attendee of a given class.
  • Deposit fee date The date by which the attendees deposit must be received in order to avoid cancellation of the reservation.
  • Processing fee date The date by which a predetermined portion of the attendee's deposit is earned by and paid to the operator of the commmerce processor, and is nonrefundable to the attendee .
  • the processing fee is a fixed fee per transaction collected once for each attendee reservation. If desired, the processing fee can be computed as a percentage of the value of the attendee's stay to the participating hotel.
  • Event date The date on which the convention or other sponsored event begins .
  • the payment controller code determines, for each attendee on behalf of whom a reservation requests has been made, which processes are to be performed, including credit card authorization, charging of deposit to credit card account, deposit of reservation check for collection by financial institution, and refund of deposit by issuance of check or credit to attendee ' s credit card account .
  • the payment controller code presorts the various processes by type and then transmits the data for batch processing. For example, all credit card authorization requests may be transmitted via credit card controller code to an external electronic payments system for approval. Similarly, authorized credit card deposits may be communicated to the electronic payments system in a batch process by the credit card controller code. Check payments are routed, in bulk, to the banking system for collection via check controller code.
  • Result messages indicative of the timeliness and validity of deposits are communicated to the group inventory manager module 17 to ensure that rooms are assigned only to attendees who have paid their reservation deposits .
  • the payment controller module 23 employs payment configurator code for determining when to process each type of transaction, requests sets of transactions to be processed from the attrition enforcer module 29, groups transactions to be processed into similar types for batch processing, e.g., authorizations, collections, and refunds and packages them for delivery to the corresponding -In ⁇
  • the payment controller module 23 has code for distributing status messages for access by parties to the settlement process.
  • the payment controller provides result messages to the inventory manager which enable rooms for which reservations have been cancelled to be returned to available inventory.
  • a major benefit achievable with the central reservation and deposit management facility of the invention is a substantial reduction in multiple bookings and cancelled reservations. Maintaining and enforcement of business rules governing the refund and forfeiture of deposits discourages cancellations in general . Enforcement of an escalating scale of deposit forfeiture amounts encourages attendees who must cancel to do so as early as possible to enable the rooms to be returned to available inventory and rebooked.
  • Business rules directed to reduction of attendee attrition are stored for each combination of beneficiary merchant and attendee class.
  • Initial date threshold manager code stores a processing fee date for the commencement of deposit forfeiture
  • threshold dollar manager code stores forfeiture dollar amounts which are to be applied as a function of date of cancellation. There is no forfeiture on cancellations made prior to the processing fee date. Forfeiture charges begin to be applied and increase with time from the processing fee date until the cancellation close date. There is a one hundred percent forfeiture of deposits on cancellations made after the cancellation close date.
  • Unit count limit manager code provides a predetermined limit on the number of rooms that can be reserved by a deposit to a single credit card for attendees of each class. VIPs 13 may thereby be allowed to reserve more rooms on a credit card than may general attendees 11.
  • the unit count limit manager code compares the number of rooms sought to be reserved with a predetermined limit on the number of units that can be charged to a single credit card for the respective class of attendee, irrespective of the amount of the charge. If the result of the comparison indicates that the number of rooms sought to be reserved on a credit card is less than or equal to the predetermined limit assigned to the respective class of attendee, the attendee's credit card is charged with the deposit amount as will hereinafter be explained.
  • the attrition manager module 25 receives secured user input, establishes participating beneficiary merchant (e.g. hotel operator) accounts, establishes an inventory unit count limit per credit card for each class of attendee, establishes initial threshold processing fee dates, establishes all threshold processing dollar amounts, establishes record writing dates for all other steps, and establishes charge amounts for credit card transactions.
  • participating beneficiary merchant e.g. hotel operator
  • establishes an inventory unit count limit per credit card for each class of attendee establishes initial threshold processing fee dates, establishes all threshold processing dollar amounts, establishes record writing dates for all other steps, and establishes charge amounts for credit card transactions.
  • An attrition adjuster module 27 contains code for determining the times at which cancellation penalties are applied in steps occurring from the processing fee date until the cancellation close date, the amount applied at each step having been established in the threshold dollar manager code of the attrition manager module 25. Attrition rules are applied by class of attendee. Thus VIPs 13 may be given more favorable treatment on cancellation than the treatment given to general attendees 11.
  • the attrition adjuster code also provides for adjusting the attrition step by class of attendee. For example, the deposit of a general attendee 11 may be penalized more in more frequently occurring steps than the deposit of a VIP 13.
  • the attrition adjuster records an attrition rule for each attendee class, records multiple attrition rule steps for each attendee class, records attrition step threshold dates for each attendee class, and records an attrition step dollar cost for each attendee class.
  • An attrition enforcer module 29 (see Fig. 9) has a clock input for continuously receiving time signals from a time agent.
  • Threshold listener/trigger code determines when a time has been reached at which refunds for prospective cancellations are to be penalized and triggers a reduction in the portion of the deposit which may thereafter be refunded in response to a cancellation.
  • the threshold listener/trigger code signals action broker code to direct that a signal be sent to a payment controller module 23 via action actor code.
  • the action/actor code updates the threshold listener/trigger code in preparation for the next penalty event.
  • the attrition enforcer identifies a financial charge (transaction) for each time threshold crossed by each attendee as a function of the attendee's class, identifies a progress charge amount inversely related to proximity to the event start date, and computes a diminishing refund for each prospective cancelled reservation consistent with the rule for each class of attendee as established by the attrition adjuster.
EP00936298A 1999-05-25 2000-05-25 Verfahren zum verarbeiten von reservierungsanzahlungen Withdrawn EP1214672A4 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US13586999P 1999-05-25 1999-05-25
US135869P 1999-05-25
PCT/US2000/014425 WO2000072214A1 (en) 1999-05-25 2000-05-25 Method of processing reservation deposits

Publications (2)

Publication Number Publication Date
EP1214672A1 EP1214672A1 (de) 2002-06-19
EP1214672A4 true EP1214672A4 (de) 2002-09-04

Family

ID=22470098

Family Applications (1)

Application Number Title Priority Date Filing Date
EP00936298A Withdrawn EP1214672A4 (de) 1999-05-25 2000-05-25 Verfahren zum verarbeiten von reservierungsanzahlungen

Country Status (4)

Country Link
EP (1) EP1214672A4 (de)
AU (1) AU5163300A (de)
CA (1) CA2371793A1 (de)
WO (1) WO2000072214A1 (de)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
SE0101265L (sv) * 2001-04-06 2002-10-07 Sven Prytz Metod och system för tillhandahållande av information om köförhållanden och för inrangering av köande kunder vid serviceställen
US11651297B2 (en) * 2019-12-30 2023-05-16 Expedia, Inc. Booking management system

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPS5553767A (en) * 1978-10-14 1980-04-19 Keihin Kiyuukou Dentetsu Kk Computer system for motor school
US5404291A (en) * 1989-11-20 1995-04-04 Hyatt Corp. Inventory control process for reservation systems
US5237499A (en) * 1991-11-12 1993-08-17 Garback Brent J Computer travel planning system
US5864818A (en) * 1993-01-04 1999-01-26 Feldman; Ron Automated hotel reservation processing method and system
US5581461A (en) * 1993-02-08 1996-12-03 Itt Sheraton Corporation Computerized system and method for storage, processing and transfer of inventory and other data among a central processor/database and a number of remote locations
US5832451A (en) * 1996-01-23 1998-11-03 Electronic Data Systems Corporation Automated travel service management information system

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
No Search *
See also references of WO0072214A1 *

Also Published As

Publication number Publication date
AU5163300A (en) 2000-12-12
EP1214672A1 (de) 2002-06-19
WO2000072214A1 (en) 2000-11-30
CA2371793A1 (en) 2000-11-30

Similar Documents

Publication Publication Date Title
RU2337401C2 (ru) Способ выполнения банковских трансакций со связыванием счетов посредством общих счетов
US6553346B1 (en) Conditional purchase offer (CPO) management system for packages
US5864818A (en) Automated hotel reservation processing method and system
US20040249745A1 (en) System and method for automatically adjudicating transactions involving an account reserved for qualified spending
US20080091582A1 (en) Systems and methods for redeeming rewards associated with accounts
US20080091480A1 (en) Global reservation transaction management system and method
CN1633667A (zh) 操作忠诚度方案的方法与系统
JP2002515991A (ja) 信用貸し及び債務申請のオンライン審査及び承認を行うシステムと方法
MX2007006604A (es) Metodo y sistema de control de cuenta que permite comprar solamene articulos elegibles y autorizados con el uso de la cuenta.
CA2395502A1 (en) Payroll management method and apparatus
US10803459B2 (en) Online transaction processing system for multi-product transactions
US20100082477A1 (en) Method and system for loan and payment processing
RU2639950C2 (ru) Способ и система для обеспечения кредитных сделок, а также связанная с ними компьютерная программа
KR101070454B1 (ko) 잔액 기반의 정기예금 운영방법
US20020138312A1 (en) Right to use vacation interest resort business method
KR20130041668A (ko) 온라인 계모임 서비스 제공 방법
EP1214672A1 (de) Verfahren zum verarbeiten von reservierungsanzahlungen
US8595031B1 (en) Method and apparatus for providing access to healthcare funds
JP6668444B2 (ja) 賃貸料決済システム及び賃貸料決済方法
US20130311384A1 (en) Lease deposit exemption policy
JP7378173B1 (ja) 情報処理装置、情報処理方法及びプログラム
US20170278158A1 (en) Online transaction processing system for multi-product transactions
EP1306784A1 (de) Informationsaufzeichnungsmedium und system damit
US20170278163A1 (en) Online transaction processing system for multi-product transactions
JP2005149287A (ja) 賃貸物件管理システム

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20011210

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LI LU MC NL PT SE

AX Request for extension of the european patent

Free format text: AL;LT;LV;MK;RO;SI

A4 Supplementary search report drawn up and despatched

Effective date: 20020722

AK Designated contracting states

Kind code of ref document: A4

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LI LU MC NL PT SE

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20041201