U.S. patent application number 10/172481 was filed with the patent office on 2004-02-26 for method and apparatus for customer direct on-line reservation of rental vehicles.
Invention is credited to Belanger, Hugues, Boruff, Kelli, Fitzgerald, Neil, Tucker, Paul.
Application Number | 20040039612 10/172481 |
Document ID | / |
Family ID | 29733075 |
Filed Date | 2004-02-26 |
United States Patent
Application |
20040039612 |
Kind Code |
A1 |
Fitzgerald, Neil ; et
al. |
February 26, 2004 |
Method and apparatus for customer direct on-line reservation of
rental vehicles
Abstract
A method of processing a reservation transaction between a
customer and reservation-booking entity via a computer network
inter-connecting a customer computer with an automated reservation
transaction processor, the reservation transaction requiring
submission of at least three different types of reservation data
from the customer for successful completion thereof, each
reservation data type having one of a plurality of different
values, wherein each reservation data type value is dependent upon
other reservation data type values, the method including presenting
an initial page for data value entry for a plurality of reservation
data types, accepting for partial data entry data values for less
than all of said reservation data types, and determining, on the
basis of the interdependence of the different data values for the
different reservation data types, a list of acceptable data values
for any un-entered reservation data types. Also, the processor
provides the customer with a less than full page summary section on
many of the reservation booking pages, the summary section
including a list of submitted data values for the reservation
transaction and an edit link associated with each listed data value
that is selectable to initiate a revision of its associated data
value. Further, the present invention supports promotional
deep-linking, promotion reservation with notification upon customer
violation of the promotion rules, and corporate account
deep-linking.
Inventors: |
Fitzgerald, Neil; (Wildwood,
MO) ; Belanger, Hugues; (Creve Coeur, MO) ;
Boruff, Kelli; (St. Charles, MO) ; Tucker, Paul;
(Ballwin, MO) |
Correspondence
Address: |
THOMPSON COBURN, LLP
ONE US BANK PLAZA
SUITE 3500
ST LOUIS
MO
63101
US
|
Family ID: |
29733075 |
Appl. No.: |
10/172481 |
Filed: |
June 14, 2002 |
Current U.S.
Class: |
705/5 ;
705/1.1 |
Current CPC
Class: |
G06Q 10/02 20130101;
G06Q 30/0645 20130101 |
Class at
Publication: |
705/5 ;
705/1 |
International
Class: |
G06F 017/60 |
Claims
What is claimed is:
1. A method of processing a reservation transaction between a
customer and reservation-booking entity via a computer network
connecting a customer computer with an automated reservation
transaction processor, the reservation transaction requiring
submission of at least three different types of reservation data
from the customer for successful completion thereof, each
reservation data type having one of a plurality of different
values, wherein each reservation data type value is dependent upon
other reservation data type values, the method comprising: (a)
displaying a page on the customer computer, the page including (1)
a request that the customer submit values for at least two of the
different data types, and (2) for each requested data value, a data
submitter through which the customer can submit a data value to the
automated reservation transaction processor; (b) receiving data at
the automated reservation transaction processor from the customer
computer that corresponds to a submission of a data value for at
least one of the data types; (c) determining from the received data
at least one data type, if any, that remains unsubmitted; (d) if
any unsubmitted data type is determined to remain, determining, on
the basis of the interdependence of the different data values for
the different reservation data types, a list of remaining
acceptable values for the at least one unsubmitted reservation data
type; (e) displaying another page on the customer computer, the
another page including (1) said at least one determined list of
acceptable data submission values, and (2) for each said determined
list, a data submitter for submitting at least one of said
acceptable values to the automated reservation transaction
processor; and (f) repeating steps (b) through (e) as necessary
until all required data types are successfully submitted to the
automated reservation transaction processor, thereby completing the
reservation.
2. The method of claim 1 wherein the step of displaying another
page includes selecting one from a plurality of pages, each of said
another pages corresponding to at least the unsubmitted data
type.
3. The method of claim 2 wherein the step of selecting includes
selecting corresponding also to the submitted values.
4. The method of claim 1 wherein the step of displaying another
page includes selecting one from a plurality of pages, each of said
another pages corresponding to at least the submitted data
values.
5. The method of claim 1 where the step of displaying another page
includes displaying the other page wherein the determined list
includes unacceptable data submission values.
6. The method of claim 1 wherein the another page includes a
summary section that lists the received data value for each
reservation data type, the summary section including an edit link
for each listed data value, the edit link being selectable to
request an edit page, the edit page being configured to accept a
revision to the listed data value for the reservation data type
corresponding to the selected edit link.
7. The method of claim 6 wherein the reservation transaction is a
rental vehicle reservation transaction.
8. The method of claim 7 wherein the reservation data types
comprise a reservation location, a reservation starting date, a
reservation ending date, and a vehicle type.
9. The method of claim 8 wherein the reservation data types further
comprise the customer's age.
10. The method of claim 8 wherein the displaying step includes
displaying a page on the customer's computer, the page including a
data submitter for submitting at least a partial data value for
each of a reservation location, a reservation starting date, and a
reservation ending date for transmission to the automated
reservation transaction processor.
11. The method of claim 10 wherein the receiving step includes
receiving data from the customer computer, the data including a
value for reservation starting time, a value for reservation ending
time, and a partial value for reservation location.
12. The method of claim 11 wherein the unsubmitted data type
determining step comprises determining that the reservation
location remains undetermined.
13. The method of claim 12 wherein the remaining data entry option
determining step includes determining, from a plurality of
different reservation locations, at least one reservation location
dependent upon the submitted partial location value.
14. The method of claim 13 wherein the another page sending step
includes sending the another page over the computer network to the
customer computer for display thereon, the another page including
(1) a list comprising each determined reservation location
satisfying the submitted partial location value, and (2) for each
determined reservation location, a link selectable by the customer
to effect a submission of the reservation location to the automated
reservation transaction processor.
15. The method of claim 8 further comprising: receiving a data
value for vehicle type corresponding to a vehicle selection;
receiving a data value for reservation time; determining a total
cost for the reservation from a base rate for the vehicle selection
and the received reservation time; and displaying a page on the
customer computer that identifies both the base rate and the total
cost for the reservation transaction.
16. The method of claim 1 wherein the another page displaying step
includes displaying the another page wherein the another page
further includes a selectable message tile for initiating an action
in accordance therewith.
17. A method of processing a reservation transaction between a
customer and reservation-booking entity via a computer network
inter-connecting a customer computer with an automated reservation
transaction processor, the reservation transaction requiring
submission of at least three different types of reservation data
from the customer for successful completion thereof, each
reservation data type having one of a plurality of different
values, wherein each reservation data type value is dependent upon
other reservation data type values, the method including presenting
an initial page for data value entry for a plurality of reservation
data types, accepting for partial data entry data values for less
than all of said reservation data types, and determining, on the
basis of the interdependence of the different data values for the
different reservation data types, a list of acceptable data values
for any un-entered reservation data types.
18. The method of claim 17 further comprising presenting another
page on said customer's computer, said another page including a
summary section that lists the received data value for each
reservation data type, the summary section including an edit link
for each listed data value, the edit link being selectable to
request an edit page, the edit page being configured to accept a
revision to the listed data value for the reservation data type
corresponding to the selected edit link.
19. The method of claim 18 wherein said another page is presented
regardless of whether data values have been entered for all
reservation data types.
20. The method of claim 19 wherein the reservation transaction is a
rental vehicle reservation transaction and wherein the reservation
data types comprise a reservation location, a reservation starting
date, a reservation ending date, and a vehicle type.
21. The method of claim 20 wherein the initial page presenting step
includes displaying a data submitter for submitting at least a
partial data value for each of a reservation location, a
reservation starting date, and a reservation ending date for
transmission to the automated reservation transaction
processor.
22. The method of claim 21 wherein the un-entered data type
determining step comprises determining that the reservation
location remains undetermined and wherein the list determining step
includes determining, from a plurality of different reservation
locations, at least one reservation location dependent upon the
submitted partial location value.
23. A method of processing a reservation transaction between a
customer and a reservation-booking entity via a computer network
connecting a customer computer with an automated reservation
transaction processor, the reservation transaction requiring a
plurality of customer-entered pieces of information that are
necessary for successful completion thereof, the method comprising
displaying a page on the customer's computer, the page being
configured with: (1) at least one field for the customer to submit
a piece of necessary information, and (2) a summary that includes
(a) a list comprised of any pieces of said necessary information
previously submitted by the customer and (b) at least one
selectable edit link for requesting a data submitter for entering
at least one revised data value for at least one piece of said
necessary information.
24. The method of claim 23 further comprising: recognizing
selection of said at least one edit link, displaying on the
customer computer a data submitter for receiving revised data
values for a piece of necessary information, receiving a revision
to the piece of necessary information that corresponds to the
selected edit link; and updating the corresponding piece of
necessary information.
25. The method of claim 23 wherein the method includes providing an
edit link for each piece of necessary information on the list.
26. The method of claim 25 further comprising locating each edit
link adjacent its associated piece of necessary information.
27. The method of claim 23 wherein the method further comprises
providing a progress marker indicative of proportional successful
entry of pieces of necessary information.
28. The method of claim 23 wherein the reservation transaction is a
vehicle rental reservation transaction, and wherein the pieces of
necessary information comprise (1) temporal information for the
reservation, (2) a rental location for the reservation, and (3) a
vehicle type for the reservation.
29. The method of claim 28 wherein the pieces of necessary
information further comprise personal information about the
customer.
30. The method of claim 23 further comprising displaying said
summary on less than a full page.
31. The method of claim 30 further comprising permitting the rest
of the page to be separately addressed and used for display of
other information relating to the reservation.
32. An apparatus for processing a reservation transaction between a
customer and a reservation-booking entity via a computer network,
the reservation transaction requiring a plurality of
customer-submitted pieces of information that are necessary for
successful completion thereof, the apparatus comprising: a
processor configured to create a page for display on a customer
computer, the page having: (1) at least one field for the customer
to submit a piece of necessary information; and (2) a summary that
includes (a) a list comprised of any pieces of said necessary
information previously submitted by the customer and (b) at least
one selectable edit link for requesting a data submitter for
entering at least one revised data value for at least one piece of
said necessary information.
33. The apparatus of claim 32 wherein the processor is further
configured to (1) recognize selection of said at least one edit
link, (2) interact with the customer computer to display thereon a
data submitter for receiving revised data values for a piece of
necessary information, (3) receive a revision to the piece of
necessary information that corresponds to the selected edit link,
and (4) update the corresponding piece of necessary
information.
34. The apparatus of claim 32 wherein the summary includes an edit
link for each piece of necessary information on the list.
35. The apparatus of claim 34 wherein each edit link is located
adjacent its associated piece of necessary information.
36. The apparatus of claim 32 wherein the summary further comprises
a progress marker indicative of proportional successful entry of
pieces of necessary information.
37. The apparatus of claim 32 wherein the reservation transaction
is a vehicle rental reservation transaction, and wherein the pieces
of necessary information comprise (1) temporal information for the
reservation, (2) a rental location for the reservation, and (3) a
vehicle type for the reservation.
38. The apparatus of claim 37 wherein the pieces of necessary
information further comprise personal information about the
customer.
39. The apparatus of claim 32 wherein the summary comprises less
than all of the page.
40. A method of processing a reservation transaction between a
customer and reservation-making entity via a reservation booking
website accessed over a computer network that connects a customer
computer with the website host, the reservation transaction having
at least three different data types for which the customer must
submit a data value to effect a completion thereof, the method
comprising: receiving data from the customer computer that is
indicative of a selection of a promotional link, the promotional
link having a promotion associated therewith, the promotion having
at least one condition, the at least one condition corresponding to
a particular promotional data value that one of the reservation
data types must exhibit for the promotion to be valid; creating a
reservation transaction for the customer computer; and deep-linking
the customer computer into the reservation booking website such
that, for the customer computer's reservation transaction, any of
the data types that correspond to the at least one promotion
condition are set equal to the particular promotional data
value.
41. The method of claim 40 wherein the reservation transaction is a
vehicle rental reservation transaction, wherein one of the
reservation data types is vehicle type, wherein the particular
promotional data value for the at least one promotion condition is
a particular vehicle type.
42. The method of claim 40 wherein the reservation transaction is a
vehicle rental reservation transaction, wherein one of the
reservation data types is a reservation location, wherein the
particular promotional data value for the at least one promotion
condition is a particular reservation location.
43. The method of claim 40 wherein the reservation transaction is a
vehicle rental reservation transaction, wherein one of the
reservation data types is customer age, wherein the particular
promotional data value for the at least one promotion condition is
a particular minimum customer age.
44. The method of claim 40 wherein the reservation transaction is a
vehicle rental reservation transaction, wherein one of the
reservation data types is reservation starting date, wherein the
particular promotional data value for the at least one promotion
condition is a particular reservation starting date.
45. The method of claim 40 wherein the reservation transaction is a
vehicle rental reservation transaction, wherein one of the
reservation data types is reservation ending date, wherein the
particular promotional data value for the at least one promotion
condition is a particular reservation ending date.
46. The method of claim 40 wherein the reservation transaction is a
vehicle rental reservation transaction, wherein the reservation
data types comprise a reservation location, a reservation starting
date, a reservation ending date, and a vehicle type, wherein the
promotion has a plurality of conditions associated therewith, and
wherein the deep-linking step comprises: deep-linking the customer
computer into the reservation booking website such that, for the
customer computer's reservation transaction, each of the data types
that correspond to the promotion conditions are set equal to their
particular promotional data value.
47. The method of claim 40 further comprising: determining whether
a subsequent data submission received from the customer violates
any promotion condition; if a promotion condition violation is
found, presenting the customer with an option to revise the data
causing the violation.
48. A method of processing a reservation transaction between a
customer and reservation-making entity via a reservation booking
website accessed over a computer network that connects a customer
computer with a website host, the reservation transaction having at
least three different data types for which the customer must submit
a data value to effect a completion thereof, the website comprising
a plurality of interactive pages through which the customer submits
data values to the host, the method comprising: receiving data from
the customer computer that is indicative of a selection of a
promotional link, the promotional link having a promotion
associated therewith, the promotion having at least one condition
that corresponds to a range of data values that one of the
reservation data types must exhibit for the promotion to be valid;
creating a reservation transaction for the customer computer;
linking the customer computer to a page of the website; receiving
data from the customer computer that corresponds to a submission of
a data value for a data type that corresponds to the at least one
promotion condition; identifying whether a violation of the at
least one promotion condition exists by determining whether the
submitted data value is within the condition's range of valid data
values; if a promotion condition violation is identified, linking
the customer computer to another page of the website, the another
page being configured to notify the customer of the promotion
condition violation; and permitting the customer to complete the
reservation either within the promotion condition or outside the
promotion condition.
49. The method of claim 48 wherein the another page is further
configured to allow the customer to submit a new data value for the
data type corresponding to the violated promotion condition, the
new data value being within the within the violated condition's
range of valid data values.
50. The method of claim 48 wherein the promotion has at least two
conditions, one of the promotion conditions corresponding to a
particular promotional data value that one of the reservation data
types must exhibit for the promotion to be valid, and wherein the
another page linking step comprises: deep-linking the customer
computer to the another page such that, for the customer computer's
reservation transaction, the data type that corresponds to the
promotion condition with the particular promotional data value is
set equal to the particular promotional data value.
51. A method of processing a reservation transaction between a
customer and reservation-making entity via a reservation booking
website accessed over a computer network that connects a customer
computer with a website host, the reservation transaction having at
least three different data types for which the customer must submit
a data value to effect a completion thereof, the website comprising
a plurality of interactive pages through which the customer submits
data values to the host, the method comprising: receiving data from
the customer computer that is indicative of a selection of a
promotional link, the promotional link having a promotion
associated therewith, the promotion having at least one condition
that corresponds to a range of required data values; receiving data
submitted from the customer computer corresponding to a
reservation; identifying whether a violation of the at least one
promotion condition exists by determining whether at least one
submitted data value is within the condition's range of valid data
values; if a promotion condition violation is identified, notifying
the customer of the promotion condition violation; and permitting
the customer to continue with either the promotion or with a
standard reservation outside the promotion.
52. The method of claim 51 further comprising presenting an option
to revise any data value determined to violate the valid promotion
data values.
53. The method of claim 51 further comprising performing the method
in the order recited.
54. The method of claim 51 further comprising completing the
reservation of the promotion should no violation be identified
55. The method of claim 51 further comprising permitting the
reservation to be completed outside of the promotion should a
violation be identified.
56. A method of processing a reservation transaction between a
customer and reservation-making entity via a reservation booking
website accessed over a computer network that connects a customer
computer with the website host, the reservation transaction having
at least three different data types for which the customer must
submit a data value to effect a completion thereof, the method
comprising: receiving data from the customer computer that is
indicative of a selection of a corporate account, the corporate
account having a pricing rate associated therewith and further
having at least one parameter associated therewith, the parameter
defining at least one condition corresponding to a particular data
value that one of the reservation data types must exhibit for the
corporate account pricing rate to carry over to the reservation
transaction; creating a reservation transaction for the customer
computer; deep-linking the customer computer into the reservation
booking website such that, for the customer computer's reservation
transaction, any of the data types that correspond to the at least
one parameter are set equal to the particular data value
corresponding thereto; and permitting the customer to complete the
reservation as a corporate account reservation or outside the
corporate account.
57. The method of claim 56 further comprising: determining whether
a subsequent data submission received from the customer violates
any parameter; if a parameter violation is found, presenting the
customer with an option to revise the data causing the
violation.
58. A method of processing a reservation transaction between a
customer and reservation-making entity via a reservation booking
website accessed over a computer network that connects a customer
computer with a website host, the reservation transaction having at
least three different data types for which the customer must submit
a data value to effect a completion thereof, the website comprising
a plurality of interactive pages through which the customer submits
data values to the host, the method comprising: receiving data from
the customer computer that is indicative of a selection of a
corporate account, the corporate account having a pricing rate
associated therewith and further having at least one parameter
associated therewith, the parameter defining at least one condition
corresponding to a range of acceptable data values that a data
value of one of the reservation data types must exhibit for the
corporate account pricing rate to carry over to the reservation
transaction; creating a reservation transaction for the customer
computer; linking the customer computer to a page of the website;
receiving data from the customer computer that corresponds to a
submission of a data value for a data type that corresponds to the
at least one parameter; identifying whether a violation of the at
least one parameter exists by determining whether the submitted
data value is within the parameter's range of acceptable data
values; if a parameter violation is identified, linking the
customer computer to another page of the website, the another page
being configured to notify the customer of the parameter violation;
and permitting the customer to proceed either with a corporate
account reservation or outside the corporate account
parameters.
59. The method of claim 58 wherein the another page is further
configured to allow the customer to submit a new data value for the
data type corresponding to the violated parameter, the new data
value being within the within the violated parameter's range of
acceptable data values.
60. A system for processing a reservation transaction between a
customer and a reservation-making entity via a computer network
connecting a customer computer with an automated reservation
transaction processor, the reservation transaction comprising a
plurality of data values, the automatic reservation transaction
processor being programmed to display any one of a plurality of
display pages, said plurality of display pages being
inter-connected in a network so that most of said display pages
offer movement to any one of a plurality of further display pages,
wherein said processor is configured to move from one display page
to another in response to data values not yet received, and wherein
at least some of said another displayed pages include at least
partial data corresponding to data values not yet received.
Description
FIELD OF THE INVENTION
[0001] The present invention relates to the automated processing
and booking of reservation transactions conducted over a computer
network between a customer and a reservation booking entity. In
particular, the present invention relates to the on-line
reservation of rental vehicles. Even more particularly, the present
invention relates to the reservation of rental vehicles over the
internet through a consumer accessing a dedicated web site.
BACKGROUND OF THE INVENTION
[0002] In the past decade, the use of the Internet in connection
with commercial activities (so-called "e-commerce") has exploded
into virtually all areas of the business world. Among the
businesses utilizing the Internet for e-commerce purposes have been
car rental businesses.
[0003] One of the ways that the car rental industry has utilized
the power of the Internet is through on-line reservation booking.
In addition to the many travel web sites, another way for a
consumer to book a reservation over the Internet using an
Internet-connected computer is to interact with a server maintained
by the entity that books the reservation. To successfully complete
a reservation transaction, the customer must generally provide the
server with 3 or 4 basic types of information: (1) temporal
information--when and for how long the car rental is needed
(typically entered as pick up and return dates), (2) location
information--from which branch of the rental car company the rental
car is desired to be obtained, (3) vehicle information--what type
of vehicle is needed, and optionally (4) customer information--the
customer's age and/or name.
[0004] With these informational needs in mind, various websites
dedicated to on-line booking of car rental reservations have been
developed. Such on-line reservation websites guide the customer
through the reservation process so that the customer provides the
server with the information necessary to complete a reservation
transaction. Thereafter, the server can create the reservation and
post it to the rental car company's database. However, the current
on-line reservation websites have failed to guide customers through
the reservation process in a manner that provides both a high
degree of user-friendliness and flexibility. Because of the rigid
navigational structure of current on-line reservation websites, it
is believed that on-line reservation processing has failed to reach
its full potential in the marketplace.
[0005] FIGS. 1(a)-(d) illustrate an example of a conventional
on-line reservation booking process. The customer accesses a page
having a form that includes a plurality of fields in which he/she
can enter data. Some fields are required for the reservation to be
booked, some are not (required fields are denoted by the *). If the
customer submits data for less than all of the required fields, the
form is returned to the customer with an indication that he/she
must fill out all required fields to successfully submit a
reservation. In the example of FIG. 1(a), it can be seen that the
customer has entered "St. Louis Airport" in the required location
field, but has left all other fields blank. When this form is
submitted, the form of FIG. 1(b) is returned. Error indicators are
placed adjacent to the blank required fields, and an error message
instructs the customer to fill all required fields. If the form of
FIG. 1(c) represents the result of the customer's next attempt to
submit a reservation, it can seen that the customer has now failed
to include his/her age in the form. The confirmation form of FIG.
1(d) will only be provided to the customer after an age is entered
in the age field. The confirmation page of FIG. 1(d) is only
presented to the customer after the customer has submitted all
required fields and the server has determined that a reservation is
possible given the data submitted in the required fields (i.e.,
that a luxury sedan is available for rental at the St. Louis
Airport branch from Aug. 1, 2002 through Aug. 3, 2002 to a 35-year
old person).
[0006] Because of the different types of data needed to book a
reservation (as exemplified by the required fields in the forms of
FIGS. 1(a)-(c)), the on-line rental vehicle reservation process can
be thought of as a multi-stage process, wherein each stage
corresponds to receipt of a particular type of necessary
reservation information from the customer. That is, one stage
relates to obtaining temporal information from the customer,
another stage relates to obtaining location information from the
customer, another stage relates to obtaining vehicle information
from the customer, and yet another stage relates to obtaining
personal information from the customer.
[0007] Many current on-line rental vehicle reservation websites
guide customers through these stages one stage at a time. That is
to say, the customer is first presented with a page requesting that
temporal information for the reservation be provided. After the
customer transmits the requested temporal data to the server, the
server responds by presenting the customer with a page requesting
that location information for the reservation be provided. After
the customer transmits the requested location data to the server,
the server responds by presenting the customer with a page
requesting that vehicle information be provided, and so on until
the server receives all types of necessary data. Once all types of
necessary data are received, the server presents the customer with
a verify page that summarizes the entered data. If the customer
wishes to change any of the entries, that customer is dropped back
to the stage where revision is desired. In simplistic systems, the
customer must thereafter re-supply the server with the information
for any stages downstream from the revised stage. In more advanced
systems, the customer can be returned to the verify page after
entering the revision data. FIG. 2 illustrates such a conventional
linear process (the dashed line indicating the improved revision
process).
[0008] Such conventional techniques suffer from a shortcoming in
that a customer who realizes that an error was made in entering
stage 1 data (for example, entering the wrong starting date for the
rental) but does not realize the mistake until stage 2, must wait
until all stages are complete before getting the opportunity to
correct the mistake. Because of this inconvenience, customer
frustration may occur which could lead to the customer leaving the
site without completing the reservation. Also, such conventional
reservation techniques require the customer to complete reservation
stages in a fixed order defined by the reservation booking entity
and not the customer. Thus, customers typically do not have the
freedom to complete stages in the order they may desire.
[0009] Another reservation booking process known as of the filing
date hereof is shown in FIG. 3. Rather than forcing the customer to
first complete a particular stage before proceeding to a next
stage, the customer is allowed to first complete any of a plurality
of stages (but not the vehicle stage--which requires prior
completion of both the time stage and location stage), and then
proceed through each individual remaining stage in a single-step
fashion. While such a reservation system gives the customer the
partial freedom to select the order in which stages are completed,
it still requires the customer to complete the reservation process
sequentially using a fixed number of minimum data exchanges. That
is to say, for each stage, the customer must access the page
associated with that stage before proceeding to a page associated
with the next stage. This shortcoming may unnecessarily draw out
the reservation process, thereby adding to customer frustration and
possible loss of a reservation.
[0010] Another feature of a competitor's on-line reservation system
is a summary section that is provided on the left hand side of each
page associated with a stage (the right hand side of each page is
dedicated to prompting the customer to enter the data for the stage
associated therewith). The summary section lists the stage data
entered by the customer. As the customer completes stages, the
summary section is updated with the new data entries. However, the
competitor's summary section is a read-only summary. It is not
interactive to allow the customer to directly select a data entry
he or she may wish to revise. If the customer, upon reviewing the
summary section, decides that a stage needs to be re-visited to
revise the data corresponding thereto, the customer must correlate
which stage is associated with the data needing revision and then
identify a tab or other pointer on the right hand side of the page
and select it to re-visit the stage associated with the data
needing revision. FIG. 4 illustrates this aspect of the
competitor's reservation system. Because of the potential customer
confusion that may be created as customers navigate through such an
on-line reservation system, increased customer dissatisfaction may
develop.
[0011] Log file research and usability tests have shown that
customers will abandon websites as a function of the website's
user-unfriendliness and inconvenience. As such, to maximize the
potential of their e-commerce investment, it is highly important
that reservation booking entities develop an on-line reservation
system that smoothly guides the customer from start to finish while
allowing those customers to proceed at their own desired pace with
a minimum of inconvenience. This is especially the case due to the
inherent uncertainty of speed and connectivity of the Internet. In
other words, requiring potential customers to access increased
numbers of menus or displays increases the amount of time required
to successfully complete a reservation. These studies have shown
that user drop out increases as a function of time, so designing a
web site which perhaps is easily implementable in HTML or other
programming code may well lead to a rigid, single path architecture
that is not optimized for user friendliness, minimal data entry,
and minimal display access steps.
SUMMARY OF THE INVENTION
[0012] Toward this end, the inventors herein have developed an
on-line reservation transaction system wherein the customer can
complete the stages of the reservation transaction via a
customer-determined path, and not according to a strictly defined,
straight-line architecture.
[0013] According to one aspect of the present invention, disclosed
herein is a method of processing a reservation transaction between
a customer and reservation-booking entity via a computer network
connecting a customer computer with an automated reservation
transaction processor, the reservation transaction requiring
submission of at least three different types of reservation data
from the customer for successful completion thereof, each
reservation data type having one of a plurality of different
values, wherein each reservation data type value is dependent upon
other reservation data type values, the method comprising: (a)
displaying a page on the customer computer, the page including (1)
a request that the customer submit values for at least two of the
different data types, and (2) for each requested data value, a data
submitter through which the customer can submit a data value to the
automated reservation transaction processor; (b) receiving data at
the automated reservation transaction processor from the customer
computer that corresponds to a submission of a data value for at
least one of the data types; (c) determining from the received data
at least one data type, if any, that remains unsubmitted; (d) if
any unsubmitted data type is determined to remain, determining, on
the basis of the interdependence of the different data values for
the different reservation data types, a list of remaining
acceptable values for the at least one unsubmitted reservation data
type; (e) displaying another page on the customer computer, the
another page including (1) said at least one determined list of
acceptable data submission values, and (2) for each said determined
list, a data submitter for submitting at least one of said
acceptable values to the automated reservation transaction
processor; and (f) repeating steps (b) through (e) as necessary
until all required data types are successfully submitted to the
automated reservation transaction processor, thereby completing the
reservation.
[0014] The reservation transaction is preferably a rental vehicle
rental reservation, wherein the types of necessary data comprise
temporal information, location information, and vehicle
information. Additional types of necessary data types may include
customer age information and other customer personal information
(such as name, phone number, insurance, etc.).
[0015] The data values for the reservation data types are said to
be dependent upon each other because it is not necessarily the case
that all possible combinations of the different values for each
reservation data type will be acceptable to complete a reservation.
That is, in a given reservation transaction, a particular data
value for a particular data type may restrict the range of
acceptable values for other data types. For example, the value of
"luxury" for vehicle type may display a range of location values
but restrict the range of acceptable location values from location
1-10 to only locations 3 or 4; or the value of Jul. 10-14, 2002 for
starting/end time and the value of Location X for location may
restrict the range of acceptable values for vehicle types from all
vehicle types to only "economy" and "compact". Thus, the range of
acceptable values for each reservation data type are dependent upon
availability given any previous data value entries for other
reservation data types. At the same time, the user may choose to
change one of the limiting data values to thereby change the
resulting range of acceptable data values for other data types.
Because the present invention narrows the customer's data
submission options to a list of acceptable values for an
unsubmitted data type on the basis of what values are acceptable
for successful completion of a reservation given the previous data
value submissions for the other data type, customers are guided
toward making choices that maximize the likelihood of successfully
booking a reservation with minimal customer dissatisfaction.
[0016] According to another aspect of the present invention, herein
is disclosed a method of processing a reservation transaction
between a customer and a reservation-booking entity via a computer
network connecting a customer computer with an automated
reservation transaction processor, the reservation transaction
requiring a plurality of customer-entered pieces of information
that are necessary for successful completion thereof, the method
comprising displaying a page on the customer's computer, the page
being configured with (1) at least one field for the customer to
submit a piece of necessary information, and (2) a summary that
includes (a) a list comprised of any pieces of said necessary
information previously submitted by the customer and (b) at least
one selectable edit link for requesting a data submitter for
entering at least one revised data value for at least one piece of
said necessary information.
[0017] The use of such an interactive summary on the interactive
web pages of the present invention allows customers to quickly and
easily enter any changes to the previously-submitted data.
[0018] According to yet another aspect of the invention,
deep-linking is provided for customers seeking to book a
reservation from a promotional link or from a corporate account.
The promotion corresponding to a promotional link that may be
selected by a customer may have one or more promotion conditions,
each promotion condition corresponding to a particular data value
or range of data values that the customer must choose for a
particular reservation data type. For example, a promotion offering
a reduced rate may only be valid for a single vehicle type or may
only be valid for a limited time. Similarly, a corporate account
may include limiting parameters analogous to promotion conditions.
With the present invention, when a customer selects a promotional
link or a particular corporate account, that customer is
deep-linked into the reservation booking process such that the data
values for any data type that correspond to a promotion condition
(or a corporate account parameter) are identified in the
accompanying text. Also, any reservation data types corresponding
to promotional conditions (or corporate account parameters) have
their data values set equal to those conditions/parameters. Should
the customer submit a data value that violates a promotion
condition (or corporate account parameter), then the present
invention notifies the customer of this situation and presents
him/her with an option to revise the data value causing the
violation of a promotion condition/corporate account parameter.
Instructional text may also be found on subsequent pages.
Alternately, the customer may elect to continue the process and not
take advantage of the promotion or move off the corporate
account.
[0019] By deep-linking into the website those customers who are
seeking to take advantage of an offered promotion (or an available
corporate account), the present invention avoids inconvenience to
the customer that would result from requiring the customer to first
learn what data values need to be entered to satisfy the conditions
of the promotion and then entering those values. Those steps are
bypassed by deep-linking the customer to a point in the reservation
booking process where data values relating to promotional
conditions are automatically set to the conditional values. Also,
by notifying the customer when a submitted data value for a
reservation data type violates a promotion condition (or corporate
account parameter) and by giving the customer the option to
accordingly revise that data value, the present invention avoids
the customer dissatisfaction that may arise from the customer
losing out on a desired advantage because of an unintentional
violation of a promotion condition or corporate account
parameter.
[0020] The present invention further provides an efficient use of a
user's time and network connectivity, by minimizing the required
amount of interactivity, and movement of data/displays from the
reservation booking website and the customer's computer. As is
known in the art, delays are commonly experienced on the Internet
due to the required transmission of large amounts of data to create
displays so that minimizing the number of displays must necessarily
speed up the process of a user making an Internet reservation.
[0021] Still another aspect of the present invention is the design
feature that creates a summary section with hyperlinks for a user
to conveniently click and move to a display to change the
corresponding data needed to complete the reservation. This summary
is further advantaged by occupying less than all of the display
screen. This feature of the invention focuses the user on the
single most important task at hand, i.e. that of completing the
reservation in a manner acceptable to the user, with the correct
information entered, and with perhaps the most user-friendly and
intuitive method for correcting/changing any information needed for
completing the reservation. The invention thus adapts the website
architecture to the user's needs, and points every user action
towards completing the reservation to thereby maximize the
"completion" rate of reservations achieved compared to the number
of users accessing the website.
[0022] These and other features and advantages of the present
invention will be in part apparent and in part pointed out in the
following description and referenced figures.
BRIEF DESCRIPTION OF THE DRAWINGS
[0023] FIG. 1 illustrates a prior art technique by which a
reservation booking website obtains reservation data from a
customer;
[0024] FIG. 2 illustrates another prior art technique by which a
reservation booking website obtains reservation data from a
customer;
[0025] FIG. 3 illustrates yet another prior art technique by which
a reservation booking website obtains reservation data from a
customer;
[0026] FIG. 4 illustrates a known technique for providing a
customer with a summary of existing reservation data as the
customer proceeds through the various stages of the reservation
booking process;
[0027] FIG. 5 illustrates an overview of the reservation data
gathering technique of the present invention, wherein 3 types of
reservation data are needed;
[0028] FIG. 6 illustrates a preferred architectural overview for
the present invention;
[0029] FIG. 7 illustrates the preferred automated reservation
transaction processor in more detail;
[0030] FIG. 8 illustrates a preferred technique for how the present
invention processes data received from the customer;
[0031] FIGS. 9-12 illustrate various preferred navigational paths
for the reservation booking process of the present invention
starting from the home page;
[0032] FIG. 13 illustrates a preferred navigational path for the
reservation booking process of the present invention starting from
a page designed to obtain general locational information from the
customer;
[0033] FIGS. 14-15 illustrate various preferred navigational paths
for the reservation booking process of the present invention
starting from pages designed to obtain a branch selection from the
customer;
[0034] FIGS. 16-17 illustrate various preferred navigational paths
for the reservation booking process of the present invention
starting from pages designed to obtain a vehicle selection from the
customer;
[0035] FIGS. 18-19 illustrate various preferred navigational paths
for the reservation booking process of the present invention
starting from pages designed to provide the customer with detailed
information about a selected vehicle;
[0036] FIGS. 20-23 illustrate various preferred navigational paths
for the reservation booking process of the present invention
starting from pages designed to provide the customer with detailed
information about a selected branch;
[0037] FIG. 24 illustrates a preferred navigational path for the
reservation booking process of the present invention starting from
a page designed to obtain pertinent personal information about the
customer;
[0038] FIGS. 25-26 illustrate various preferred navigational paths
for the reservation booking process of the present invention
starting from pages designed to allow the customer to review and
verify the reservation data prior to booking;
[0039] FIG. 27 illustrates a preferred navigational path for the
reservation booking process of the present invention starting from
a reservation confirmation page;
[0040] FIGS. 28-29 illustrate various preferred navigational paths
for the reservation booking process of the present invention
starting from pages designed to allow the customer to change the
reservation time;
[0041] FIG. 30 illustrates a preferred navigational path for the
reservation booking process of the present invention starting from
a page designed to allow the customer to change the age data;
[0042] FIG. 31 illustrates an overview of how the present invention
allows a customer to deep-link into the reservation booking process
upon the selection of a promotional link;
[0043] FIG. 32 illustrates the promotional deep-linking aspect of
the present invention;
[0044] FIG. 33 illustrates how the present invention allows a
customer who is following a promotional path to make informed
decisions when entering data to avoid violating the conditions of
the promotion;
[0045] FIG. 34 illustrates an overview of how the present invention
allows a customer to deep-link into the reservation booking process
with use of a corporate account;
[0046] FIG. 35 illustrates the corporate account deep-linking
aspect of the present invention;
[0047] FIG. 36 illustrates how the present invention allows a
customer who is following a corporate account path to make informed
decisions when entering data to avoid violating the parameters of
the corporate account's profile;
[0048] FIG. 37 is a screenshot of a preferred home page (H) for the
present invention;
[0049] FIGS. 38-41 are screenshots of preferred "choose location"
pages (CL1-CL4) for the present invention;
[0050] FIGS. 42-43 are screenshots of preferred "choose vehicle"
pages (CV1-CV2) for the present invention;
[0051] FIGS. 44-45 are screenshots of preferred "vehicle details"
pages (VD1-VD2) for the present invention;
[0052] FIGS. 46-49 are screenshots of preferred "branch details"
pages (BD1-BD4) for the present invention;
[0053] FIGS. 50(a)-50(b) are screenshots of a preferred "renter
information" page (RI) for the present invention;
[0054] FIGS. 51-52 are screenshots of preferred "verify" pages
(V1-V2) for the present invention;
[0055] FIG. 53 is a screenshot of a preferred "confirmation" page
(Conf) for the present invention;
[0056] FIGS. 54-55 are screenshots of preferred "change time" pages
(ChT1-ChT2) for the present invention;
[0057] FIG. 56 is a screenshot of a preferred "change age" page
(ChA) for the present invention;
[0058] FIG. 57 is a screenshot of a preferred "stripped down home
page" page (SH) for the present invention
[0059] FIG. 58 is a screenshot of a preferred "after hours" page
(AH) for the present invention;
[0060] FIGS. 59-61 are screenshots of preferred "apology" pages
(APOL1-APOL5) for the present invention;
[0061] FIG. 62 is a screenshot of a preferred "cancel reservation"
page (Cancel) for the present invention;
[0062] FIG. 63(a) is a screenshot of a preferred "promotional
parameters notice" page (Notice) for the present invention; and
[0063] FIG. 63(b) is a screenshot of a preferred "corporate account
parameters notice" page (Notice) for the present invention.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT
[0064] FIG. 5 illustrates the basic navigational structure for the
reservation booking website of the present invention. In the
example of FIG. 5, the different types of data needed from the
customer to successfully book a rental car reservation are: (1)
temporal data (T)--such as the starting and ending dates for the
reservation, (2) location data (L)--such as an identification of
the particular branch of the rental car company from which the
customer seeks a car rental reservation, and (3) vehicle data
(V)--such as the type of vehicle the customer wants to rent
(economy, midsize, luxury, etc.). The customer can submit values
for these data types to the reservation booking entity via a
customer-determined number of stages. Each box in FIG. 5 represents
a page of the website, and the text within each box represents the
data types for which the page requests data values from the
customer. Each arrow indicates a submission of data by the
customer, and the text adjacent each arrow represents the type(s)
of data being submitted.
[0065] The customer, depending on his/her desires, can either
submit all data values for all necessary data types to the
reservation booking entity via a single data exchange 104, two data
exchanges 102, or in single-step fashion via three data exchanges
100. Once the reservation booking entity has received all necessary
data from the customer, a verify page is presented from which the
customer can review his/her data entries and thereafter book the
reservation if all is accurate.
[0066] In the single data exchange 104 wherein the customer submits
temporal, locational, and vehicle data at the same time, the
reservation booking entity must consult a database to determine
whether a reservation having those data values is possible. If not,
the customer will be guided to amend one or more of the reservation
data entries.
[0067] In the two-step data exchange 102, the reservation booking
entity can process the double submission (TL, TV, or LV) to
determine how to more accurately guide the customer through the
process. For example, if both T and L are submitted at once, the
reservation booking entity knows that vehicle data is still needed,
but because both T and L data have been submitted, it can refine
the customer's options for selecting vehicles to only those
vehicles available at the selected time from the selected location.
This aspect of the invention is taken one step further in the
three-step data exchange 100. On each submission of data, the
reservation booking entity processes the submitted data on the
basis of the data values interdependent to refine the number of
acceptable data value options for the remaining data types.
[0068] FIG. 6 illustrates a preferred architecture for the present
invention. A plurality of customer computers 210 connected to a
network 204 (such as the Internet) and using web browsing software
can access a reservation booking website hosted by automated
reservation transaction processor 150. Automated reservation
transaction processor 150 can be any computer that is network
connectable. Preferably, the processor 150 comprises an application
server 200 (or application servers for redundancy purposes) a web
server (or servers) 200, a customer/promotional database 208, and a
business database 206. The application server 200 (1) interacts
with the customer computers via web server 202 (or web servers) to
obtain reservation data therefrom, (2) interacts with business
database 206 via a connector interface such as Tuxedo, and (3)
interacts with a customer/promotional database 208 via a connector
interface such as JBDC. Business database 206 stores all of the
data pertaining to the rental car company's branch locations,
vehicle inventories, pricing, etc. Customer/promotional database
208 preferably stores the profiles of any registered customers, the
profiles of any corporate accounts, and data relating to any rental
promotions being offered by the company.
[0069] FIG. 7 illustrates the automated reservation transaction
processor 150 in greater detail. Application server 200 preferably
runs WebLogic 6.1 software 250 and interfaces with web server 202
(preferably an Apache web server 242) via a servlet 220 and a Java
Server Page (JSP) 222, preferably using Struts architecture. The
servlet communicates with a personalization application
programmer's interface (API) 228 to store and retrieve customer
profiles and a promotions API 230 to retrieve promotional data. The
APIs 228 and 230 link with EJB connector logic 232 which in turn
links with JBDC connector logic 234. The JBDC connector logic 234
allows the application server 200 to communicate with database
server 208 (which is preferably an Informix database 236). The
server also communicates with the business database 206 via EJB
connector logic 224 and WebLogic Tuxedo connector 226. The business
database server 206 is preferably an AS/400s implementing Tuxedo
services 240 and Tuxedo connector 238.
[0070] Servlet 220 performs the major decision-making tasks for the
reservation booking process of the present invention. Servlet 220
interacts with the databases to gather necessary information for
both (1) determining which page should be constructed by the JSP
222, and (2) the particular data that should appear on the page.
Upon reference to the navigational charts and screen shots of the
succeeding figures, a programmer having ordinary skills can readily
implement the programming needed to implement the present
invention, particularly the servlet 220 and JSP 222. Also, as one
of ordinary skill in the art would readily recognize, any of a
number of servers and software platforms can be used in connection
with the present invention. As such, the present invention is in no
way limited by the configurations shown in FIGS. 6 and 7.
[0071] FIG. 8 is a flowchart illustrating how the application
server 200 processes data received from customers. At step 8.1, the
application server receives a data submission from a customer
computer. Using FIG. 5 as an example, this data may relate to T, L,
or V. At step 8.2, the application server creates a reservation
transaction for the customer computer and stores the received data
therein. Next at step 8.3, the application server processes the
received data to determine what information is still needed from
the customer to complete a reservation, and what information the
customer needs to make a meaningful decision when deciding what to
choose for the remaining data. To make such decisions, the servlet
220 interacts with the business database 206. For example, if
servlet has received T and L data from the customer, the servlet
determines that V data is still needed and queries database server
206 for all vehicles available from the selected L at the selected
T. Preferably, the servlet also queries the database for additional
information pertaining to the available vehicles, such as a price
and a general description (both of which can be included in the
page to be built and sent to the customer). At step 8.4, the
servlet then interacts with JSP 222 to build a web page with
necessary information and hyperlinks that allow the customer to
make a further data submission that will at least partially satisfy
at least one remaining reservational data need. Thereafter, at step
8.5, the customer computer accesses the built page and the process
repeats itself as additional data submissions are received from the
customer computer.
[0072] The navigational path for the reservation booking website of
the present invention will now be described. FIG. 9 shows a
navigational path starting from the home page wherein a zip code
has been entered as partial location information. FIG. 38
illustrates a preferred format for the home page (H) of the present
invention.
[0073] With reference to FIG. 38, page H includes a plurality of
fields in which the customer can enter reservation data. The four
basic types of reservation data are preferably location information
(L), temporal information (T), vehicle information (V), customer
age (A), and additional customer information (RI). From the home
page, the customer can preferably enter data for L, T, V, and A.
Also, it should be noted that the website can be designed to
recognize returning visitors through the use of cookies or customer
registration, which would eliminate the need to repetitively gather
A and RI information from repeat customers.
[0074] Preferably, a customer enters partial L data from the home
page that will allow the processor 150 to determine a general area
(such as a metropolitan area or state) from which the customer is
interested in renting a car. In locational field 302, the customer
can enter either a zip code, an airport code, or general search
text. Business database 206 preferably associates each branch
location with a plurality of nearby zip codes to enable zip code
searching. Also, any branch locations that are designated as
airport branches (preferably branches near an airport) are
associated with the 3 character airport code of the nearby airport
to enable airport code searching. If general search text is
entered, the servlet will query the business database 206 for all
branch locations having the entered text anywhere in its address.
However, it should be understood that other locational search
methods may be readily implemented (including but not limited to
methods such as a drop down menu listing all of the rental car
company's branches--which is not very efficient for a large rental
car company having thousands of branches, a pop-up map with
geographically-placed hyperlinks, cascaded searches by state then
city then branch, or the like). If a customer wishes that only
branch locations associated with airports be returned but does not
know the airport code for the airport of interest, a box 326 is
provided that restricts the branches returned from a zip code or
general text search to only airport branches that satisfy the zip
code/text search criteria.
[0075] Full temporal information is preferably provided in fields
304, 306, 308, and 310 which correspond to starting date, starting
time, return date, and return time respectively. It is preferred
that default values be used for the temporal information (such as
the current date for starting/end dates and noon for starting/end
time) in the event that the customer does not enter T data from the
home page. In the event error data is received as a date, the
customer will be linked to a "stripped down" version of page H (SH,
see FIG. 57) to re-enter valid temporal data.
[0076] Vehicle information is preferably provided in field 314. A
drop down menu can list available vehicle types (including but not
limited to types such as compact, economy, mid-size, and luxury).
Preferably the vehicle type defaults to "all vehicle types" in the
event that the customer does not enter V data from the home
page.
[0077] Customer age information is preferably provided in field
322. A drop down menu can list possible age ranges (including but
not limited to below 20, 21-24, and 25+). Preferably the age
defaults to 25+ in the event that the customer does not enter A
data from the home page.
[0078] Upon entering data in any or all of the above-described
fields, the customer can submit the data (including any default
temporal or age entries that may exist) to the processor 150 by
selecting link 324. The data entry fields and the "search" link 324
make up a data submitter through which the customer can submit at
least one data value. It should be noted that the present invention
is not limited to a data submitter as shown in FIG. 38 but
encompasses data submission techniques of all kinds, such as a data
submitter that is a list of hyperlinks with each hyperlink
corresponding to a different acceptable data value, a data
submitter that is a drop-down menu of selectable options and a
corresponding "select" link, or the like.
[0079] Additional preferable features for the home page include (1)
various promotional links 318 that correspond to any promotions
that the rental car company is offering (each promotional link 318
being selectable to initiate a reservation transaction according to
the conditions of the promotion), (2) an "enter corporate account"
field 316 through which a customer can access a corporate account
and initiate a reservation transaction according to the parameters
of a profile associated with the corporate account (preferably the
corporate account is accessed by entering a password or the like in
field 316), and (3) a "modify an existing reservation" link 320
which allows a customer to access and/or modify an existing
reservation by entering a reservation confirmation number or some
other suitable identifier when subsequently prompted. One or more
message tiles 317 may also be provided on page H (or any page other
than SH). The message tile 317 includes either a link 318 to a
promotion or a link to accessing a customer's corporate account.
Preferably the message tile 317 is positioned on either end (left
or right) of the page, preserving the center of the page for
reservation data interaction.
[0080] Returning to FIG. 9, when a customer has selected link 324
after entering a zip code in field 302, the servlet accesses the
business database to determine the state in which the zip code is
located and the branch(es) associated with that zip code. If the
received age data (which may either be the default age data or
customer-entered age data) is below the minimum age for renting a
vehicle in the zip code's state (21 in most states, 18 in New
York), then the servlet links the customer to page APOL3 (see FIG.
61). If not, the servlet queries the database 206 to determine
whether any returned branches are open at the starting date and
starting time received from the customer (which may be either
default values or customer-entered values). If no such branches are
open, the servlet links the customer to either page CL1 (if a
vehicle type has been selected, see FIG. 38), or page CL2 (if no
vehicle type has been selected, see FIG. 39). On the displayed CL
page, the indicated status for each listed branch will be
"closed".
[0081] If open branches do exist, and only one such open branch
exists, the servlet proceeds through steps 9.5-9.21. If the
customer selected a vehicle type from the home page, and the
selected vehicle is both available at the branch and available for
the customer's age, the servlet links the customer to page BD2 (see
FIG. 47) which allows the customer to learn more about both the
single returned branch (address, etc.) and the vehicle selected
(such as price, etc.). If the customer selected a vehicle type from
the home page, and the selected vehicle is available at the branch
but not available for the customer's age, the servlet links the
customer to page APOL3 (see FIG. 62) which informs the customer of
the vehicle's unavailability based on an age restriction. If the
customer selected a vehicle type from the home page, and the
selected vehicle is not available at the branch but other cars are
available at the branch, the servlet links the customer to page BD1
(see FIG. 46) or BD4 (see FIG. 49) depending upon whether the
branch is designated an airport branch. BD1 and BD4 let the
customer know of the other vehicles that can be selected at the
branch while also informing the customer about the single returned
branch. Because airport branches often have extended operating
hours, after closing vehicle drop-offs, and shuttle services,
airport branches are given special attention in the present
invention (although this need not be the case). If the customer
selected a vehicle type from the home page, and the selected
vehicle is not available at the branch, nor are any vehicles
available at the branch, the servlet links the customer to page
APOL1 (see FIG. 59) or APOL2 (see FIG. 60) depending upon whether
the branch is an airport branch. APOL1 will provide the customer
with a link outside the summary section (to be described below)
that allows the customer to change branch locations. APOL2
preferably does not provide such a link outside the summary
section. Both APOL1 and APOL2 inform the customer that the branch
has no vehicles available at the selected starting time. If the
customer did not select a vehicle type from the home page, and the
selected vehicle is not available at the branch, nor are any
vehicles available at the branch, the servlet links the customer to
page APOL1 (see FIG. 59). If the customer has not selected a
vehicle type from the home page, and the selected vehicle is not
available at the branch but other cars are available at the branch,
the servlet links the customer to page BD1 (see FIG. 46) or BD4
(see FIG. 49) depending upon whether the branch is designated an
airport branch, which lets the customer know of the other vehicles
that can be selected at the branch.
[0082] If more than one open branch is returned from the database
query at step 9.4, the next action needed from the customer is a
selection of one of the plurality of branch locations meeting the
zip code search criterion (steps 9.22-9.24). Depending upon whether
the customer entered a vehicle type, the servlet links the customer
to either page CL1 (see FIG. 38) or CL2 (see FIG. 39) which list
the locations available for selection based on the submitted
data.
[0083] FIG. 10 illustrates essentially the same process as FIG. 9
with the exception that the customer entered search text in field
302 rather than a zip code (which affects the "choose location"
pages now denoted as being either CL3 and CL4, see FIGS. 40-41).
Likewise, FIG. 11 illustrates essentially the same process as FIGS.
9 and 10 with the exception that the customer has either entered an
airport code in field 302 or entered either a zip code or search
text in field 302 after checking box 326. Because it is known that
only airport branches are returned from the database query, the
process of FIG. 11 (unlike those of FIGS. 9 and 10) does not need
any decision-making based on whether a particular branch is flagged
as an airport branch.
[0084] FIG. 12 illustrates a navigational flow from the home page
where the customer enters any combination of age, vehicle, and/or
time data--but no locational data is entered in field 302. In such
cases, the servlet links the customer to page SH (see FIG. 57)
which is a stripped down version of the home page. FIG. 13 shows
the navigational flow from page SH, and is self-explanatory. Data
entries other than locational data results in the customer being
looped back to page SH.
[0085] FIGS. 14 and 15 illustrate the navigational flow from the
"choose location" pages CL1-CL4. An exemplary screenshot of CL1 is
shown in FIG. 38. Referring to FIG. 38, CL1 lists a plurality of
branch locations 332 that meet the zip code criterion provided by
the customer. Because CL1 is reached when the vehicle type for the
reservation is known, each branch listing 332 also lists that
branch's status as to the availability of the selected car (see
vehicle availability status column 336). Each branch listing 332
also lists that branch's distance from a selected point in the zip
code provided by the customer (see branch distance from zip code
column 334). Preferably, CL1 lists not only the branches that are
acceptable for selection as determined from the current reservation
data (i.e., open branches having the selected vehicle available at
the selected time) but also branches that are unacceptable for
selection based on current reservation data (i.e., the branch
listings denoted as "closed" or "sold out"). While such branches
are not acceptable for selection via link 338, the customer may
desire to change other reservation data to make a particular
location acceptable. For example, by selecting the link 342, a
customer will be linked to a branch details page allowing the
customer to possibly change reserve time (steps 14.14-14.16).
[0086] For each branch listing 332 where the selected vehicle is
available, a "select" link 338 is provided nearby that allows, upon
selection thereof, the customer to select the branch to which the
"select" link corresponds. No "select" links are provided for
branches where either the selected vehicle is unavailable or the
branch is closed during the selected start time. Each branch
listing also includes a "view branch details" link 342 that, upon
selection, links the customer to a page (a BD page) that provides
more details as to the pertinent data for the branch (i.e. hours of
operation, rental policies, shuttle service (if available), etc.)
and if a vehicle has not been selected also presents the customer
with a listing of available vehicles. Furthermore, a "next 5/prev
5" link 340 is also provided (when the number of branch listings
exceeds a predetermined number, which is preferably however many
branch listings comfortably fit on the page). Upon selection of
link 340, the CL1 page is redisplayed with the next 5 or previous 5
branch listings.
[0087] Another feature of the present invention that can be seen on
the CL1 page is summary section 330. Summary section 330 provides
the customer with a running summary of reservation data submitted
to processor 150. Summary section 330 preferably includes a listing
for L stage data 346 which can be seen in FIG. 38 as not yet
existing, T stage data 348 which is the start date/time and end
date/time provided by the customer, V stage data 350 which is the
vehicle type data provided by the customer, A stage data 352 which
is the age data provided by the customer, and RI stage data 354
which is the renter information provided by the customer. The
summary section 330 also includes, for each reservation data type
for which a complete data value has been received, a nearby
(preferably adjacent as shown) "editing" link 360. "Editing" link
360 is selectable to initiate a revision to the data with which the
link is associated. The "editing" link provides the present
invention with a unique user-friendliness and flexibility that
allows customers to easily revise any errors that may have been
made when entering data or quickly implement changes of mind. In
the example of FIG. 38, it can be seen that only the T stage data
348 has been provided by the customer, and as such, an "editing"
link 360 is situated adjacent thereto.
[0088] While it is preferred that the summary 330 include a
separate edit link for each listed data value, this need not be the
case. By providing separate edit links for each listed data value,
the user-friendliness of the summary section 330 is improved
because the customer can initially determine how to best initiate a
data value revision. However, less preferred edit link
implementations can be used, such as a single edit link within the
summary section 330 that is selectable to initiate a revision for
any of the listed data values, or the like.
[0089] Furthermore, summary section 330 preferably includes a
progress marker 344 which notifies customers of how far along they
are in the reservation booking process. In the example of FIG. 38,
progress marker 344 notifies the customer that the process is 209
complete (preferably the stages considered by the progress marker
are T, V, L, RI, and a verification stage). However, as would be
apparent to those of ordinary skill in the art, more or fewer
stages could be considered in calculating the percentage complete
for the progress marker. As can be seen in connection with the
other screenshots shown in the figures, the summary section 330
provides a useful tool through which customers can optimize the
reservation booking process.
[0090] FIG. 40 illustrates CL3 which closely matches CL1, except
column 334 is not included (because the customer has not provided a
zip code). FIG. 41 also shows an example of another hyperlink that
may appear on either CL1 or CL3--the "check other vehicles" link
360. Whenever the selected vehicle is unavailable at one of the
branch listings 332, a "check other vehicles" link 360 is
preferably provided as an action item for the branch that is
selectable to both select the corresponding branch location and
initiate a "change vehicle" edit.
[0091] FIG. 14 illustrates the navigational path starting from
either CL1 or CL3. If the customer selects one of the listed
branches, the servlet first checks whether the selected branch is
flagged as an airport branch. If so, the servlet checks whether the
return time for the reservation is after the branch's closing time.
If the return time is post-closing, the customer is linked to an
"after hours" (AH) page (see FIG. 58) which provides the customer
with the option of either accepting the selected branch's after
hours return policy (continue to step 14.6) or initiating a change
to the reservation time (link to page ChT2, described in more
detail below). At step 14.6, a VD1 page (see FIG. 44) is displayed
which notifies the customer of important vehicle information such
as base rate and total rental cost.
[0092] If step 14.2 determines that the selected branch is not an
airport branch, then the servlet proceeds through steps 14.7-14.11.
In the event the selected branch offers an after hours return
policy, the steps 14.8-14.11 are performed (which essentially
mirror 14.3-14.6 except non-airport page versions are displayed).
If there is no after hours policy at the selected branch and the
return time is after closing, steps 14.11-14.13 are followed.
[0093] Another selection possibility from CL1 or CL3 is the
selection of a "view branch details" link 342. If a link 342 is
selected, then the customer is linked to a "branch details" page
(either BD2 or BD3 depending on whether the selected branch is an
airport branch--see FIGS. 47-48). The BD pages provide detailed
information about the branch corresponding thereto.
[0094] Other selection possibilities from CL1 or CL3 are derived
from the "editing" links 360 in the summary section 330. Because it
is preferred that default values be used for T data and A data in
the absence of modification thereof by the customer, summary
sections 330 will always include "editing" links 360 corresponding
to changing the reservation's temporal data and changing the
customer's age. Selection of those "editing" links will link the
customer to pages SH (see FIG. 57) and ChA (see FIG. 56)
respectively. Also, because CL1 and CL3 will always be reached when
a vehicle type has been selected, the "editing" link 360
corresponding to V stage data will also be present and selectable
to link the customer to a "choose vehicle" page (CV1) (see FIG.
42). Furthermore, in the event that the renter information is known
(the conditionality of the "change RI" path is indicated by the
dashed lines), an "editing" link 360 corresponding thereto will be
present in the summary section 330 and selectable to link the
customer to a change renter information page (RI)--see FIGS.
50(a)-(b). Renter information (RI) (see FIG. 50 for an example of
information desired) can be obtained either through data entry from
page RI or through a customer profile learned either from customer
registration/log-in or cookie recognition. Further, any customer
profiles used with the present invention may also include
parameters such as "preferred vehicle type", "preferred branch
location" or the like to further expedite subsequent reservation
transactions.
[0095] FIG. 15 illustrates the navigational path starting from CL2
or CL4. An exemplary screenshot for CL2 is shown in FIG. 39, and an
exemplary screenshot for CL4 is shown in FIG. 41. Like CL1, CL2
includes column 334 because CL2 is reached when the customer
provides a zip code in field 302 of page H. Also, because no
vehicle information is known, a location status column 362 is
provided that identifies whether any vehicles are available at the
listed branches and whether the branch is open for business at the
selected start date/time. Also of note is the airplane icon 364
that appears beside any branch listings 332 that are flagged as
airport branches to notify customers of which branches are airport
branches.
[0096] CL4, shown in FIG. 41, is highly similar to CL2 except
column 334 (distance of branch from zip code) is not shown because
no zip code was entered by the customer when reaching CL4. Like
CL2, CL4 includes a branch status column 362.
[0097] FIG. 15 illustrates a navigational path for the present
invention starting from either page CL2 or CL4. Steps 15.2-15.13 of
FIG. 15 parallel steps 14.2-14.13 of FIG. 14, with the exception
that CV pages are reached at steps 15.6 and 15.11 instead of VD1
pages (as in FIG. 14). Furthermore, because no vehicle is selected,
steps 15.15-15.17 link the customer to a BD page that allows the
customer to make vehicle selections therefrom.
[0098] FIGS. 16 and 17 illustrate navigational paths for the
present invention starting from the CV pages, and are readily
understood upon reading the CV page information below. Exemplary
screenshots for CV1 and CV2 are shown in FIGS. 42 and 43
respectively--the only difference being that CV1 corresponds to a
reservation where the selected branch is not an airport branch and
CV2 corresponds to a reservation where the selected branch is an
airport branch. Both CV1 and CV2 include a vehicle inventory list
for the selected branch. Both acceptable vehicle types (those with
a select link 376) and unacceptable vehicle types (those without a
select link 376) are preferably listed.
[0099] Each vehicle listing 370 identifies the vehicle type
(economy, compact, etc.), a link 372 to "view vehicle details", a
description of the makes and models for the class, a price quote,
and when the vehicle is available, a "select" link 376. The price
quote preferably includes both a daily rate for the vehicle and a
total price listing reflective of the daily rate times the number
of reservation days (known from T data) plus any surcharges, taxes,
etc. By displaying both the daily rate and total price, the
customer is made more fully aware of price issues for the
reservation. With this feature of the present invention, when the
customer desires a particular vehicle, he/she can learn if any
other branch locations (some of which may be sufficiently nearby)
offer the desired vehicle. If a listed vehicle is unavailable, a
link 378 is provided which, upon selection, allows the customer to
both (1) select the vehicle and (2) link to a choose location page
(CL1 or CL3). CV1 and CV2 also both include summary section
330.
[0100] FIGS. 18 and 19 illustrate the navigational paths starting
from the pages VD1 and VD2 respectively. FIGS. 44 and 45 illustrate
examples of "vehicle details" screenshots for VD1 and VD2
respectively. Referring to FIG. 44, VD1 includes information
listing 390 that contains detailed information about the selected
vehicle. This detailed information preferably includes a make/model
description, a listing of vehicle features (such as A/C, stereo,
engine, number of doors, etc.), a price quote (preferably both a
daily rate and a total cost), etc. Links 392 and 394 allow the
customer to link to a "vehicle details" page for the next smaller
or next larger vehicle classes respectively. The "all" link 360
between links 392 and 394 corresponds to a "change vehicle" link.
The "select" link 398 is provided for customers who, upon reviewing
the details shown in listing 390, wish to select the shown vehicle.
VD1 also includes a summary section 330.
[0101] VD2 includes a listing 390 of vehicle details for a vehicle
that is unavailable for selection. VD2 is typically reached when
link 392 or 396 of VD1 is selected and calls up a vehicle class
that is unavailable. VD2 also preferably includes summary section
330.
[0102] FIGS. 20-23 illustrate navigational paths starting from
various "branch details" (BD) pages and are readily understood upon
reading the BD page information below. An exemplary BD1 is shown in
FIG. 46. BD1 shows pertinent branch information for a selected
non-airport branch when no vehicle has been selected. Listing 400
includes pertinent branch information such as operating hours and
address. Because no vehicle has yet been selected, BD1 also
includes a vehicle menu 402 that lists the vehicle inventory for
the selected branch. Menu 402 is similar to a miniature "choose
vehicle" page. Each vehicle listing includes a pricing column 380
and a "selection" column that includes links 376. The "select"
links 376 are selectable to submit the vehicle corresponding
thereto as the V data for the reservation. Each entry in the
pricing column preferably includes both the daily rate and the
total cost as explained above. BD1 also includes a summary section
330. BD4, shown in FIG. 49, closely corresponds to BD1, with the
exception that the selected branch is an airport branch, and as
such, the information in listing 400 is preferably slightly
different.
[0103] An exemplary BD2 screenshot is shown in FIG. 47. BD2 is
reached when a vehicle has already been selected. As such, BD2
includes a "selected vehicle information" listing 408 which is
similar to a miniature VD1 page. Listing 408 includes pertinent
information about the selected vehicle, a link 360 that is
selectable to link to a CV page, and a link 410 selectable to
continue the process with the selected vehicle. The pertinent
information in listing 408 preferably includes both a daily rate
and a total cost as explained above. BD2 also includes a summary
section 330. BD3, shown in FIG. 48, closely corresponds to BD2 with
the exception that the selected branch is an airport branch, and as
such, the information in listing 400 is slightly different.
[0104] FIG. 24 illustrates a preferable navigational path starting
from the "enter renter information" page (RI) and is readily
understood upon reading the RI page information below. An exemplary
RI page is shown in FIGS. 50(a) and 50(b). The RI page preferably
includes a field 420 in which the renter's name can be entered, a
field 422 for the renter's phone number, a field 424 for the
renter's e-mail address, a field 426 for the renter's credit card
type, and a plurality of fields 430 for additional information that
is generally needed from the customer by a rental car company
employee working at the counter of the branch location when the
customer actually arrives to pick up the rental car. A "continue"
link 428 submits any entered data to the processor 150. No fields
in RI need to be required, however, it is preferred that the name,
phone number, and credit card type fields be flagged as required
fields. The RI page also includes a summary section 330.
[0105] FIGS. 25 and 26 illustrate preferred navigational paths for
the present invention starting from a "verify" (V) page and are
readily understood upon reading the V page information below. FIGS.
51 and 52 are exemplary screenshots for an non-airport version (V1)
and an airport version (V2) respectively of the "verify" page. Both
V1 and V2 include a listing 440 of pertinent information for the
rental, such as important terms and conditions, after hours
information, and a total cost estimate (the information in listing
440 may include additional airport-related data such as shuttle
availability information). Summary section 330 is included in V1
and V2 to identify the data values for the different reservation
data types 346-354 that have been submitted to the processor 150.
Should the customer wish to revise any of the data entered for the
reservation transaction, the "editing" links 360 are available.
Link 442 is a "booking" link that submits the reservation to the
processor 150 for final booking. Link 444 is a "cancel" link that
cancels the reservation, and link 446 is an "upgrade" link that is
selectable to link the customer to a "vehicle details" page for the
vehicle of the next larger vehicle class.
[0106] In the event the customer decides that all information on
the "verify" page is correct and the reservation is ready for
booking, after selection of the "booking" link 442, the customer is
linked to a "confirmation" page. FIG. 27 illustrates the preferred
navigational path for the present invention starting from the
"confirmation" page (Conf). FIG. 53 illustrates an exemplary
screenshot for Conf. The Conf page includes confirmation
information 450, the confirmation information 450, and a
confirmation number 498. A "print" link 452 is provided to allow
the customer to print out the reservation confirmation number and
data values. A "create another similar reservation" link 454 is
provided to allow the customer to repetitively make new
reservations using the current reservation data as the starting
point (upon selection of link 454, the customer is linked to a
"verify" page wherein the reservation data matches the current
reservation data). Additional preferable links on the Conf page
include a "speed your time at the counter" link 456 that appears if
the customer did not fully fill out fields 430 in the RI page. Link
456 is selectable to return the customer to page RI or a shortened
version thereof that includes only the fields 430. Also, the Conf.
Page preferably includes a "modify/cancel" link that is
self-explanatory.
[0107] The preferred navigational paths starting from the "change
time" pages are shown in FIGS. 28-29 and are readily understood
upon reading the "change time" page information below. An exemplary
ChT1 page is shown in FIG. 54. ChT1 is reached when a customer has
opted to change the reservation time after already selecting a
non-airport branch location. Listing 470 preferably provides
business hours information for the selected branch and possibly
additional information such as an address. Fields 304-310 are
provided to update the reservation time. Link 472 is selectable to
submit the updated reservation time. "Show more locations" link 360
is analogous to a "change location" edit link 360 shown in summary
section 330.
[0108] An exemplary ChT2 page is shown in FIG. 55. ChT2 is highly
similar to ChT1 except ChT2 is reached when the selected branch is
an airport branch. Also, ChT2 preferably does not include a "show
more locations" link 360.
[0109] FIG. 30 illustrates the preferred navigational path for the
present invention starting from the "change age" page (ChA), an
example of which is shown in FIG. 56. Referring to FIG. 56, from
field 480 of the ChA page, the customer can change the age value
for the reservation--preferably to one of three groups 25+
(unrestricted), 21-24 (some vehicle restrictions exist), and 18-20
(only allowed to rent a vehicle in New York). The ChA page also
preferably includes the summary section 330. As shown in FIG. 30,
the navigational path from the ChA page requires additional
decision-making based on age (given the new age data, is the
customer eligible to rent any vehicles? the selected vehicle?).
[0110] FIGS. 58 illustrates a preferred screenshot for the "after
hours" page reached when the selected return time for an airport
branch is after closing. The AH page includes a listing 490 that
notifies the customer of the after hours return rules. The AH page
preferably further includes a "change time" link 360 that is
selectable to link to a ChT page, and a "continue" link 492 that is
selectable to indicate that the customer accepts the after hours
conditions. Once again, the AH page includes a summary section
330.
[0111] FIGS. 59-61 are exemplary screen shots for apology
conditions. APOL1, shown in FIG. 59, includes apology field 494
that notifies the customer that all vehicles at the selected
location are sold out. Outside of thesummary section 330, a "try
new dates" link 360 is provided along with a "search for a new
location" link 360. Also, a "return home" link 460 is provided.
"Try new dates" link 360 links the customer to a ChT page, "search
for a new location" link 360 links the customer to a CL page, and
link 460 is selectable to link the customer to the home page (H).
APOL1 also includes summary section 330.
[0112] APOL2, shown in FIG. 60, closely tracks APOL1 except a
"search for a new location" link 360 is not provided (outside of
the edit link 360 corresponding to a location change in summary
section 330).
[0113] Also, APOL3, shown in FIG. 61, listing 496 notifies the
customer that age restricts him/her from vehicle rental. Link 460
is a "return home" link.
[0114] FIG. 62 illustrates an exemplary "reservation cancellation"
page (Cancel) that includes "cancel" link 498, "don't cancel" link
500, and summary section 330.
[0115] Another aspect of the present invention is the concept of
"deep-linking" customers into a stage of the reservation booking
process commensurate with the conditions of a promotion they have
selected or a corporate account they are using. When a customer
selects a promotional link (link 318 shown in some of the
screenshots, including H and Conf), it is typical that the
promotion has one or more conditions associated therewith. For
example, a rental car company may offer a promotion for a reduced
rental price for a particular type of vehicle during a specified
time period. To promote the promotion, the rental car company may
provide hyperlinks on other websites through advertising or the
like, or may include promotional links on its own website to
attract customers.
[0116] When a customer selects such a promotional link to initiate
a reservation transaction, it is preferable that the user begin the
reservation transaction with the reservation data corresponding to
promotional conditions set equal to those conditions, to thereby
avoid unnecessarily requiring the customer to enter such data
himself/herself or creating a situation where the customer may
accidentally enter data that violates the conditions of the
promotion. For example, if a promotion has a condition that the
type of vehicle must be "standard", it is preferable that the
customer, upon selection of a link corresponding to that promotion,
be linked into the reservation booking process such that the
vehicle type is automatically set to "standard". FIG. 31
illustrates this "deep-linking" concept. In one example, a
promotion has one condition: the vehicle type must be "economy".
Upon selection of an icon or link associated with that promotion,
the customer is preferably linked to a state where V has been
automatically set to "economy", and the remaining options are to
choose a time and location. In another example, a promotion has two
conditions: the vehicle type must be "luxury" and the duration of
the reservation must start on Jul. 5, 2002 and end of Jul. 6, 2002.
Upon selection of an icon or link associated with that promotion,
the customer is preferably linked to a state where V has been
automatically set to "luxury" and T has been automatically set to
"Jul. 5, 2002 through Jul. 6, 2002", and the only remaining option
to choose is location.
[0117] Furthermore, as is apparent from the preceding navigational
paths and screenshots, the present invention provides customers
with unparalleled flexibility in entering the data necessary to
book a reservation, including the ability to possibly change one or
more promotional conditions. To avoid situations where a customer
unknowingly modifies a data value such that a promotional condition
is violated, the process of FIG. 32 preferably runs after each data
submission when the customer is on a promotional path. If a
promotional icon has been selected, the servlet checks whether any
of the data provided by the customer violates any of the
promotion's conditions (step 32.2). If no violation is found, any
remaining reservation data corresponding to a promotion condition
is automatically set in accordance with the promotion condition
(step 32.4) and the customer is deep-linked into the website of the
present invention to a page that is appropriate given the
reservation's current data status.
[0118] If a violation is found, the customer is linked to a
"notice" page (step 32.3). The "notice" page informs the customer
which data value violates the conditions of the promotion and why.
FIG. 33 illustrates the notification process wherein the customer
is given an option to revise. The notice page shown in FIG. 67(a)
includes a notification 401 that a promotional condition has been
violated, including an identification of which reservation data
violates the condition. Preferably, notification 401 also
indentifies what the promotion condition is. A "change" link 403 is
provided to allow the customer to revise the out-of-promotion data
to in-promotion data and a "continue" link 405 which allows the
customer to continue the reservation outside the promotion
condition.
[0119] Other examples of potential promotional conditions that the
servlet should be designed to handle are conditions that are ranges
of acceptable data values, such as a promotion that may be taken
advantage of any day during the month of August. Although the
automatic setting aspect of deep-linking would be inapplicable to
such range-based conditions because more specific time information
is needed from the customer, the process of FIGS. 32 and 33 should
still run to identify whether the customer has entered time data
not in the condition's range.
[0120] FIGS. 34-36 illustrate the same "deep-linking" concept as
applied to corporate accounts. Many businesses or groups of people
set up so-called "corporate accounts" wherein a profile is
established for the business/group. Data stored in a profile may be
the types of vehicles eligible to be rented within the parameters
of the corporate account, renters whose age and personal
information are remembered between visits to the website, etc. When
a customer accesses the website of the present invention and
indicates a desire to use his/her applicable corporate account (see
field 316 of page H), the same "deep-linking" concept can be used.
FIG. 34 illustrates this deep-linking concept as applied to
corporate accounts. Also, the steps shown in FIGS. 35 and 36
parallel those of FIGS. 32 and 33 for promotional "deep-linking".
FIG. 67(b) illustrates a notice page for when reservation data
violates a corporate account parameter. optionally, the notice page
of FIG. 67(b) also includes links 403 and 405 as shown in FIG.
67(a).
[0121] While the present invention has been described above in
relation to its preferred embodiment, various modifications may be
made thereto that still fall within the invention's scope, as would
be recognized by those of ordinary skill in the art. Such
modifications to the invention will be recognizable upon review of
the teachings herein As such, the full scope of the present
invention is to be defined solely by the appended claims and their
legal equivalents.
* * * * *