Note: Descriptions are shown in the official language in which they were submitted.
CA 02334177 2001-02-05
SURFACE VEHICLE TRANSPORTATION RESERVATION SYSTEM
UTILIZING AIRLINE FLIGHT INFORMATION
BACKGROUND OF THE INVENTION
This invention relates to a method and system for
providing reservation and/or reservation-related services to
(i) surface vehicle transportation service vendors and (ii)
travelers and entities having a need for surface vehicle
transportation services. The invention preferably also pro-
vides surface vehicle. transportation reservation and related
services to entities which act as intermediaries between
vendors who supply travel and travel-related services on the
one hand and entities and persons who have a need for such
services on the other hand; such intermediaries being known as
travel aggregators.
The invention is particularly suited for use by, but not
limited to, limousine, car, van, private bus, and tour services
as vendors of such transportation services (and is adaptable
for use by private marine transportation vendors such as
ferries and party charter boats), and company travel depart-
ments and travel agents and individual traveler aggregators as
customers of surface transportation services; and is adapted to
facilitate the exchange of availability and reservation
information between such vendors and customers on an essen-
tially real time basis.
2
CA 02334177 2001-02-05
Company travel departments have moderate to high volume
requirements to arrange travel for their employees. These
requirements include needs for airline flight, limousine/car
service, rental car, hotel, and possibly other reservations and
arrangements as well, with various suppliers of such services
at various destinations both within and outside the United
States. Due to the nature of business, it is frequently
necessary to make changes in such reservations on short notice.
Due to the nature of airlines, flight departure and arrival
times are frequently deviated; that is, the flights are
frequently delayed and sometimes arrive early, and are at times
diverted to other destinations for weather-related or emergent
reasons.
Dealing with the making and changing of such reserva-
tions is labor intensive. Thus while company travel depart-
ments may in some instances make certain of the aforementioned
reservations, they frequently utilize the services of travel
aggregators for travel and travel-related reservation purposes.
While travel aggregators are organized to process large
amounts of travel and travel-related reservation information,
the aspect of such reservation services which is particularly
labor intensive and therefore expensive for them to process
involves arranging surface transportation reservations for
persons traveling by air and making changes in such reserva-
tions. Similar surface transportation burdens are borne by
company travel departments, travel agents, and individual
travelers when they make such reservations directly.
3
CA 02334177 2001-02-05
These surface transportation reservation burdens are due
in large part to the need for multiple telephone calls and
associated record-keeping to (a) determine airline flight
departure and arrival times, (b) keep track of delays in the
departure and arrival times and diverted flights, (c) keep
track of changes in the traveler's itinerary, (d) locate
surface transportation vendors who service the airports
involved, (e) determine the vendor's charge for the particular
surface transportation service desired, (f) determine whether
the vendor has a driver and the desired type of transportation
equipment (collectively the "transportation asset") available
at the time and between the locations for which transportation
is needed, (g) redetermine items (d), (e) and (f) on essen-
tially a real time basis in response to item (b) and (c)
changes, and (h) communicate, on essentially a real time basis,
information respecting all of the foregoing items to all
interested surface transportation vendors, aggregators, and
customers.
It has become standard practice, for example, for
limousine (or van or private bus) services to employ personnel
whose assigned task is to make numerous telephone calls to
airlines utilized by customers of the limousine service, to
ascertain the status of departing and arriving flights to which
the service is to bring, or from which the service is to pick
up the customers; and to reallocate transportation assets in
response to corresponding changes in traveler pickup and
dropoff times. These tasks, which involve only some of the
4
CA 02334177 2001-02-05
aforementioned items, consumes a considerable amount of
personnel time and significantly increases the cost of operat-
ing the limousine service.
Similarly, it has become standard practice for company
travel departments, travel agents, and global distribution
systems ("GDS"s) or aggregators needing to make reservations
for limousine (or van or private bus) services at remote
airports to employ personnel to make numerous telephone calls
to locate vendors of such services, and to determine (i)
whether the desired transportation assets) is available for
the time it will be needed, and (ii) the charges for the
particular transportation services) and destination involved.
Thus there is need for a reservation system for linking
those needing surface transportation services with providers of
such services, both directly and via intermediaries such as
travel agents and aggregators.
Accordingly, an object of the present invention is to
provide a method and system which can coordinate the various
entities and persons having surface vehicle transportation
travel needs with the various vendors of surface vehicle
transportation services, on essentially a real time basis.
5
CA 02334177 2001-02-05
SUMMARY OF THE INVENTION
As herein described, according to one aspect of the
invention there is provided a method for providing surface
transportation reservation services utilizing transportation
assets which are vehicles provided and operated by various
vendors. Each vendor provides traveler pickup and dropoff
service at a number of nodes within a service region. Each
node has a physical location associated with it.
Service information is obtained from each vendor
identifying the nodes serviced by that vendor. Price informa-
tion is obtained from each vendor providing a basis for
determining the vendor's basic price for transportation of a
traveler between selected pairs of nodes.
Travel information is obtained from a customer as to the
pickup and dropoff places associated with a particular surface
trip to be taken by a traveler associated with the customer.
From that travel information the required pickup and dropoff
nodes are determined.
The required pickup and dropoff nodes are compared to
the nodes serviced by the vendors to identify the particular
vendors which have transportation assets available to service
those nodes.
When at least one such particular vendor is so identi-
fied, the customer is advised of the availability of surface
transportation between the pickup and dropoff nodes; a reserva-
6
CA 02334177 2001-02-05
tion is booked for the trip with the particular vendor; and a
confirmation of the booking is communicated to the customer.
As herein described, according to another aspect of the
invention there is provided a method for facilitating surface
vehicle transportation of travelers from airports for trips
utilizing airlines.
Travel information records including flight information
and airport pickup times are stored in a reservation memory.
Current flight Information concerning the status of airline
flights is obtained from a flight information source. Selected
records are extracted from the stored reservation information.
The flight information in the selected records is
compared with the current flight information to determine
whether any of the corresponding flights are deviated flights,
and the reservation memory is updated to reflect the current
anticipated arrival times and places of any such deviated
flights.
According to another aspect of the invention there is
provided a method for providing reservation services to surface
vehicle transportation service vendors and entities having a
need for surface vehicle transportation services.
In this method a plurality of vendor data streams is
accepted, each stream being received from a data source
associated with a vendor of surface vehicle transportation
services via a communication medium. Each of the vendor data
streams comprises information identifying the corresponding
vendor.
7
CA 02334177 2001-02-05
A plurality of customer data streams is also accepted,
each data stream being received from a data source associated
with a customer of surface vehicle transportation services via
a communication medium. Each of the customer data streams
comprises a travel itinerary.
The vendor data streams and customer data streams are
processed to identify particular vendors having transportation
assets available meeting the surface transportation require-
ments of the itinerary. This is done by matching the places
serviced by each of the vendors with the places between which
surface transportation is required according to the travel
itinerary.
When a particular vendor is identified by the matching
process, information is communicated to that vendor as to the
corresponding travel itinerary, and information is communicated
to the corresponding customer as to the vendor.
According to another aspect of the present invention
there is provided a method for providing surface transportation
reservation services on essentially a real time basis, utiliz-
ing transportation assets comprising vehicles provided and
operated by various vendors. Each vendor provides traveler
pickup and dropoff service at a plurality of nodes within a
service region. Each node has an associated physical location
and time interval.
Service information is obtained from each vendor
identifying the nodes serviced by that vendor. The vendor also
provides time and/or distance sensitive price information for
8
CA 02334177 2001-02-05
determining the vendor's basic price for transportation of a
traveler between selected pairs of nodes. In addition, each
vendor provides time-dependent asset information as to its
available transportation assets.
Travel information is obtained from a customer as to the
pickup and dropoff places associated with a particular trip to
be taken by a traveler associated with the customer. The
traveler may be the customer himself or herself, an employee of
the customer, or another person for whom the customer is making
a reservation. In the case of a travel agent aggregator as the
customer, the traveler may be making a reservation through a
travel agent serviced by the aggregator. Similarly, in the
case of an Internet user aggregator as the customer, the
traveler may be an individual serviced by that aggregator.
The required pickup and dropoff nodes are determined
from the travel information and compared with the nodes
serviced by the vendors to identify one or more particular
vendors which have transportation assets available to service
the required nodes.
Upon identification of at least one such particular
vendor, the customer is advised of the availability of surface
transportation between the pickup and dropoff nodes and
authorization to book a corresponding reservation is solicited.
Upon receipt of such authorization from the customer, a
reservation for the trip is booked with the particular vendor
and a confirmation of the booking is communicated to the
customer. Such authorization may be solicited, for example, by
9
CA 02334177 2001-02-05
providing an authorization button on a display screen, upon
which button the user associated with the customer may click to
authorize the reservation to be booked.
According to another aspect of the invention, when a
pickup node associated with a particular trip has a physical
location at an airport, airline flight information is obtained
as to the arrival time of a corresponding flight, and a change
in the corresponding itinerary is declared when the flight is
deviated.
According to another aspect of the invention, a trans-
portation reservation system is provided which utilizes airline
flight information.
Customer reservation information is stored in a reserva-
tion memory. The reservation information includes scheduled
flight information and airport pickup or dropoff times respect-
ing the transportation needs of customers to and from airports.
The reservation information is stored in the reservation memory
by a transportation reservation storage means.
A flight information access means obtains current flight
Information concerning the status of scheduled airline flights
from the Internet and/or another source such as a third party
provider with access to FAA (Federal Aviation Administration)
data or the like. The current flight information is stored in
a flight information storage means which is coupled to the
access means.
An extraction means scans the reservation memory to
extract reservation information, which includes scheduled
CA 02334177 2001-02-05
flight information, respecting those particular reservations
for which corresponding customer pickup or dropoff times are
within a predetermined number of hours in the future. A cross-
checking means is coupled to said extraction means and respon-
sive to the scheduled flight information respecting the
particular reservations. The cross-checking means cross-checks
the scheduled flight information against current flight infor-
mation stored in the flight information storage means respect-
ing corresponding flights, to determine whether the correspond-
ing flights are deviated.
A delay-diversion processing means is coupled to the
cross-checking means and updates the reservation memory to
reflect the current anticipated arrival or departure times or
the diverted status of the corresponding flights.
In a preferred embodiment of the invention, the delay-
diversion processing means includes means for displaying any
changes in flight arrival and departure times for said particu-
lar reservations and for reallocating vehicles in accordance
with such changes, and cancels reservations corresponding to
diverted flights unless the new destination airport is within
a predetermined transportation service range.
IN THE DRAWING
Figure 1 is a functional block diagram of a surface
vehicle transportation reservation system for travelers,
according to a preferred embodiment of the invention;
11
CA 02334177 2001-02-05
Figure 2 is a high level signal flow diagram of a major
portion of the system of Figure 1, showing the movement of
information between the surface vehicle transportation reserva-
tion system server complex thereof and peripheral components of
the system;
Figure 3 is a high level process organization diagram
showing the interrelationship of the major processes utilized
in the surface vehicle transportation reservation system server
complex of Figures 1 and 2;
Figure 4 is a high level flow chart showing the steps
carried out by the Master Process Module shown in Figure 3;
Figures 5A through 5J constitute a high level flow chart
showing the steps carried out by the Vendor Module shown in
Figure 3;
Figures 6A through 6C constitute a high level flow chart
showing the steps carried out by the Security Module shown in
Figure 3;
Figures 7A through 7T constitute a high level flow chart
showing the steps carried out by the Reservation Module shown
in Figure 3;
Figures 8A through 8I constitute a high level flow chart
showing the steps carried out by the Flight Module shown in
Figure 3; and
Figures 9A and 9B constitute a high level flow chart
showing the steps carried out by the rebate process of the
Reservation Module shown in Figure 3.
12
CA 02334177 2001-02-05
GENERAL DESCRIPTION
A preferred embodiment of the present invention provides
a reservation method and system for limousine services and
other surface transportation services of vendors which supply
both a vehicle and a driver.
Each vendor specifies a combination of time intervals
(i.e. all the time, except for certain night hours, except for
certain months, etc.) within which and places where it will
pick up and drop off travelers; and communicates the number of
vehicles of each type (car, van, bus, etc. including passenger
capacity of each vehicle) which it has and the percentage or
number of each type which is available for new reservations.
The places may be specified by name of airport, name of town,
popular place such as a major league baseball park, and/or
postal zip code.
Each vendor also specifies a series of radii around a
central location within which it will pick up and drop off
travelers, and the basic price per vehicle for each mile
traveled and/or each hour or fraction thereof of travel time.
Customer desired pickup and dropoff locations are
compared to those serviced by vendors to determine those
vendors for which both the pickup and dropoff locations for a
particular trip are within the region serviced by a vendor.
The information which was most recently provided by each such
vendor is then checked to determine whether the desired vehicle
is available; and if so, the customer is advised accordingly
13
CA 02334177 2001-02-05
and upon receipt of customer authorization, a corresponding
reservation is booked and the customer's account is charged.
Information concerning the status of scheduled airline
flights is obtained from the Internet or a third party pro-
s eider. Reservations are scanned to extract those for which
corresponding pickup or dropoff times are within a specified
amount of time (e. g. twelve hours or less) in the future.
Where a pickup place is an airport serviced by scheduled
airlines, the extracted reservations are cross-checked against
status information respecting corresponding airline flights to
determine whether each corresponding flight is deviated.
Reservation changes are made to reallocate vehicles in accor-
dance with such flight information changes and vehicle avail-
ability.
Where a vehicle is not available from the original
vendor due to a delay in arrival time, or where a flight is
diverted to an airport outside the service area of the original
vendor, (i) the original reservation is canceled, and (ii) a
determination is made as to whether another vendor which
services the required pickup and dropoff locations and times
has the desired vehicle available, and if so a new reservation
is booked.
Definitions
As used in this application, unless otherwise indicated
by a specific statement or by the context, the following terms
have the meanings set forth below.
14
CA 02334177 2001-02-05
AAM - Active Agent Manager Object (object-oriented
programming).
ADB - Authentication Database.
Aggregator - An entity which facilitates and concentrates
information respecting homogeneous groups such as travel agents
(Travel Agent Aggregator) or Internet users (Internet User
Aggregator) into a coherent group. A travel agent aggregator is
the reservation processing entity for the travel Industry.
Aggregators typically support hundreds or thousands of CRS
terminals on a global level.
AO-Intelligent Agent Object (object-oriented program-
ming) .
Asset - A vehicle and driver pair that can be reserved
for a specific time of day and interval. An asset is associated
with a maximum passenger count and, when booked, is identified
with at least one paying traveler. Additional travelers for a
vehicle are not an item chargeable by the vendor.
Book-out - The act of a carrier closing out a booking,
usually when the reservation has been fulfilled. Recording of
reservation status pertaining to the booking and final recon-
ciliation of charges is made at book-out time. Wait time and
the stop charges could have changed from the original book-
ing. All pricing and commissions are recalculated using the
data supplied during the book-out process. The recalculated
values become the final cost . The customer' s account is charged
at the end of the book-out process.
CA 02334177 2001-02-05
Booking - A reservation for surface transportation made
by or on behalf of a traveler. A booking is the allocation of
an asset for movement from a pickup location to a dropoff
location and is for a continuous period of time.
Cancel-Rebook - The cancellation of the original booking
and the order of a new booking with the same or similar
information for the same or different traveler. A Cancel-Rebook
pair is to be counted as a single booking. The booked reserva-
tion is assigned a new reservation confirmation number by the
surface vehicle transportation reservation system and the
canceled booking is assigned a cancellation number.
CDT - Corporate travel department. The CDT can be a
group of corporate employees or a group of trained agents
supplied by a commercial travel agency.
Commission - A fee paid to a travel agent or a vendor for
making a reservation on behalf of a customer. A vendor can
make a reservation with another vendor at any time; and when
that occurs, the vendor receives the same commission for the
reservation as a travel agent would receive. Vendors make
typically make reservations for their customers on the destina-
tion side of a trip.
Commissioned Vendor - A vendor who receives a commission,
e.g. as a result of a farm-out to another vendor or as a result
of making a reservation on behalf of a customer.
16
CA 02334177 2001-02-05
Complementary Trip a/k/a Comp. - The act of a vendor relieving
a traveler's requirement to pay for a trip. Usually done in
response to a traveler complaint.
Concurrency Control - Control of a process to preclude users
from accessing the reservation system in a manner which would
cause the actions of one user to interfere with those of
another user.
Customer - An entity that utilizes surface vehicle
transportation reservation services and surface vehicle
transportation services for the benefit of itself or one or
more travelers associated with it.
CR Content - Computerized Reservation Content - Number of
bookings. The number of bookings an entity does with a GDS is
called CR Content.
CRS - Centralized Reservation System. This is the
reservation system used by the airlines.
Customer - An entity having a need for surface vehicle
transportation services that is entered into the surface
vehicle transportation reservation system for purposes of
specifying preferences and to track activity. A customer may
be a traveler, a travel agent, a travel agent aggregator, an
Internet user, or an Internet user aggregator.
Deviated Flight - A f 1 fight that has changed from its orig
finally scheduled flight time or path; including but not limited
to flights which have been delayed, flights which are to arrive
17
CA 02334177 2001-02-05
early, and flights which have been diverted to other destina-
tion airports.
Door to Door Share Ride- A vehicle route where the passenger
specifies where and when to be picked up or dropped off and
shares the vehicle with passengers in a similar geographical
location and overlapping time interval.
Dropoff - The point where a traveler leaves a vehicle on
a permanent basis.
EFT - Electronic Funds Transfer.
Entity - A natural person, a proprietorship, a general
partnership, or an artificial person such as a corporation,
limited liability company, limited partnership, or trust.
Essentially on a real time basis - On a basis which processes each
change in the information to which the term relates, within
less than an hour, preferably within 10 minutes, after the
change occurs.
Extra Stop - A deviation from the movement of a vehicle in
fulfillment of the traveler's booking, to pick up or discharge
additional passengers or as directed by travelers.
FA - Flight Agent (object-oriented programming).
Farm-out - The act of one vendor passing an active
reservation to an associated vendor. The associated vendor
performs the trip as a subcontractor of the original vendor.
Pricing to the customer remains the same as if the original
vendor provided the transportation asset for the trip.
18
CA 02334177 2001-02-05
FDB - Flight database.
GDS - Global Distribution System. An aggregator of
travel agents.
IATA - International Association of Travel Agents
ID - Identification number or code.
Instantiated - In the f field of obj ect-oriented programming,
creating an instance of a particular object type.
Interface - A software methodology to group operations that
operate on similar data or share relationships.
Lane - A lane is a path between two service points with
which a vendor can associate a vehicle type and price informa-
tion.
Line Run Share Ride - A typical bus or van route where the
vehicle makes stops at predetermined points for pickup and
dropoff at predetermined times.
Network - A collection of wholly owned or independent
vendors that operate cooperatively.
Network Vendor - An individual constituent of a Network.
No Show - A term given to a customer who does not show
up for a scheduled trip.
Node - A node is a place on earth at a point in time.
Open List - A system feature that functions like a standby
list. The Open List system is in place to facilitate the
passing of overflow reservations from one vendor to another
vendor in the reservation system, the passing process being
19
CA 02334177 2001-02-05
referred to in this application as Farm-Out. Travelers also
have access to the Open List system to obtain last minute
bookings. A traveler's Open List booking is considered to be
active when a carrier accepts the reservation and a reservation
number is assigned to it by the system.
Payee - A person or entity entitled to payment for a
surface vehicle transportation trip or a payment related
thereto, such as a commission payment.
Payor - A person or entity responsible for payment for a
surface vehicle transportation trip.
Pickup - The location where a traveler first enters a
vehicle.
PNR - Passenger Name Record.
Point of Sale - A commissioned entity that sells a booking.
Profile - A collection of preferences for an individual
traveler or corporate entity used in pre-filling trip parame-
ters.
Rack Rate - The list price for a trip.
RDB - Reservation database, the data of which resides
on a data server.
Reservation Account - An account with a financial institu-
tion into which payments received from or for customers (for
surface trip reservations) are deposited, and from which vendor
charges for the trips are paid.
RA - Reservation Agent (object-oriented programming).
CA 02334177 2001-02-05
Reservation Server Complex - The group of servers which carry
out the reservation method and which comprise the reservation
system of the preferred embodiment of the present invention.
SA - Security Agent (object-oriented programming).
Service Point - A location having a name, longitude,
latitude, street address, city, state, zip code and/or zip+4
code.
Share Ride - A bus or van type of booking in which
travelers share the same vehicle, each at a reduced fare.
Transportation asset - The vehicle and operator (such as a
driver) utilized in fulfillment of a trip; typically a sedan.
Buses, limousines, and handicap accessible vans are other
examples of types of transportation assets.
Traveler - A person who takes a trip.
Trip Reversal - The booking of a return reservation util-
izing information respecting the original reservation and the
return pickup date and time, and optionally the return airline
and flight number.
User - An entity which is granted access to the surface
vehicle transportation reservation system. A user is normally
a customer or vendor, or an employee of , or other person having
a business association with a customer or vendor.
VA - Vendor Agent (object-oriented programming).
21
CA 02334177 2001-02-05
Vendor a/k/a Carrier - The corporate entity that fulfils the
requested trip. A vendor operates surface transportation
vehicles.
Vendor Discount - A negot fated percentage of f the rack rate
of a vendor.
Wait-time - A traveler directed pause or necessary delay
in the movement of an asset for a period of time longer than a
carrier specified threshold.
System Overview
A preferred embodiment of the method and system of the
present invention utilizes a Surface Vehicle Transportation
Reservation System Server Complex (the "Reservation Server
Complex") which communicates on essentially a real time basis
with surface vehicle transportation service providers ("ven-
dors") which supply surface vehicles such as limousines, vans
and buses as well as operators such as drivers for such
vehicles.
The Reservation Server Complex also communicates with
customers wishing to make travel reservations for surface
trips, either on their own behalf, on behalf of entities
associated with them (such as employees in the case of corpo-
rate travel departments, or travel agents in the case of travel
agent aggregators, or Internet users in the case of Internet
user aggregators), or on behalf of travelers having an associa
tion with such entities.
22
CA 02334177 2001-02-05
These communications may take place utilizing the
Internet, telephone lines, and/or other communication links.
Devices such as routers, modems, and network interface circuits
may be used to facilitate connection to these communications
links.
The surface transportation service vendors communicate
to the Reservation System Complex information as to the service
area they cover, the vehicle/driver facilities ("transportation
assets") they have available, and the prices they charge.
Vendor price information may include different prices for
different nodes having the same physical location, i.e. for
different time periods, such as different day and night rates
and/or different rates for different seasons. By specifying a
zero price for a particular node, a vendor may exclude that
node from its service area.
The customers communicate to the Reservation Server
Complex information as to the traveler itineraries for which
surface transportation reservations are desired. These
itineraries comprise desired pickup and dropoff places and
times as well as any desired stops. In this application the
combination of each pickup, dropoff, or stop place and the
associated time is referred to as a "node".
A determination is made as to whether the nodes speci-
fied by a customer for a particular surface trip (or portion of
a surface trip comprising at least two nodes) of a traveler or
group of travelers are within the area serviced by a single
vendor; and if so the vehicle availability information previ-
23
CA 02334177 2001-02-05
ously obtained from each such vendor is accessed to determine
whether the desired type of vehicle is available for the
particular trip, and information is communicated to the
customer as to the identity of each vendor having an available
transportation asset and the basic price that vendor charges
for the trip. Where ride sharing is permitted, the making of
further reservations is prohibited after the passenger capacity
of each available transportation asset is reached. Similarly,
for a non-share ride by travelers with linked reservations, the
making of such reservations to an extent that would exceed the
passenger capacity of each available transportation asset is
prohibited.
Upon authorization of the customer, a reservation for
the trip is booked with a selected vendor and a corresponding
charge (the basic charge plus a reservation service charge) is
submitted to a Credit Card Processor for the customer's credit
card account.
Upon completion of the trip information is obtained from
the selected vendor as to additional charges for the trip, such
as tolls, parking, etc. The customer's credit card account or
other account is charged via the Credit Card Processor or by
other means, with the proceeds being credited to a Reservation
Account associated with the Reservation Server Complex. From
the Reservation Account the vendor is paid the total amount of
the charges for the trip, less a reservation system service
charge.
24
CA 02334177 2001-02-05
Customers are not permitted to make a reservation on too
short a notice, i.e. for a pickup time less than a predeter-
mined notice time after the reservation is sought to be made.
The amount of notice required for each type of transportation
asset is specified by each vendor; and if not so specified,
default notice times are used.
Customers are permitted to change or cancel surface trip
reservations. However, cancellation is not permitted if the
pickup time is less than a predetermined notice time prior to
the pickup time, as specified by each vendor - with a default
notice time of, for example 1 hour for a three or four passen-
ger transportation asset, if no notice time is specified by the
vendor.
Information concerning the status of scheduled airline
flights is available via the Internet from sources such as the
websites of scheduled airlines and/or a third party Flight Data
Provider with access to FAA (Federal Aviation Administration)
data, or the like. One or more of such sources is repetitively
accessed and the corresponding current flight information is
locally stored.
Customer reservations which have been stored in a
reservation database are scanned to extract those for which
corresponding pickup or dropoff times are a predetermined time
(typically twelve hours or less) in the future. The locally
stored current flight information is accessed to determine
whether the extracted flights are deviated, and if so the
CA 02334177 2001-02-05
reservation database is updated accordingly and the reserva-
tions as to which there are deviated flights are flagged.
For deviated flights the corresponding reservation is
canceled unless the new destination airport is within the
service area of the particular vendor with which the reserva
tion was made; and a new reservation is made if there is
another vendor for which the affected nodes are within its
service area, and that vendor has an available transportation
asset and sufficient notice time.
Determination of Whether Nodes Are Within Vendor Territory
All airport, popular place, and/or other pickup, dropoff
and stop locations specified by a customer for a particular
trip (or portion of a trip) are converted into postal zip codes
for purposes of determining whether there are one or more
vendors servicing those locations. Such locations are also
converted into geographic codes for mapping purposes to
determine distances between nodes.
Each vendor may specify the airports it services, the
postal zip codes within which it will pick up and drop off
travelers, and a distance radius about a central geographic
code or location within which it will pick up and/or drop off
travelers, and/or make stops. All such locations are converted
into postal zip codes and/or geographic codes.
The geographic codes corresponding to the desired
pickup, dropoff and stop locations for the trip are compared to
the codes comprising the vendor territories, and a determina
26
CA 02334177 2001-02-05
tion is made as to each vendor whose service area includes the
codes corresponding to those locations. If no match is found,
the vendor central zip codes are "expanded" or "zoomed" to
larger areas by comparing only a first predetermined number of
zip code digits with a corresponding number of digits of the
zip codes of the desired pickup, dropoff and stop locations.
For example, if five digit zip codes are initially used for
comparison purposes without producing a match, then only the
first three digits of each vendor zip code are compared with
the first three digits of the desired locations.
DETAILED DESCRIPTION
System Configuration
The configuration of a surface vehicle transportation
system according to a preferred embodiment of the invention
appears in Figure 1. In this embodiment reservations are made
for travelers by (i) a multiplicity of reservation system
customers for passenger transportation services provided by
(ii) a multiplicity of vendors each having a number of trans-
portation assets comprising cars, vans, buses, and the like and
drivers for the same, utilizing (iii) a Surface Vehicle
Transportation Reservation System Server Complex or Reservation
Server Complex 1014.
The customers may comprise some or all of the following,
all of which may communicate with the Reservation Server
Complex via the Internet (through modems, routers, network
27
CA 02334177 2001-02-05
circuits, direct Internet connections, or other communication
means )
a. Corporate travel departments 1003.
b. Individual travel agents 1004,
c. Individual travelers 1005,
d. Travel agent aggregators 1012 which can achieve
economies of scale by combining the reservation needs of a
substantial number of individual travel agents such as 1007,
1008, 1009. The travel agents and travel agent aggregator
communicate by means of the Internet, regular or high speed
telephone lines, leased lines, or other communication means.
e. Internet user aggregators 1013 which can achieve
economies of scale by combining the reservation needs of a
substantial number of individual Internet users such as 1010
and 1011. The Internet users and Internet user aggregator
communicate by means of the Internet or other communication
means.
A multiplicity of individual surface vehicle transporta-
tion service providers, i.e. individual vendors 1000 also
communicate with the Reservation Server Complex 1014 via the
Internet (through modems, routers, network circuits, direct
Internet connections, or other communication means).
Similarly, larger vendors, i.e. integrated surface
vehicle transportation service providers 1006, communicate with
the Reservation Server Complex 1014 and have multiple reserva-
tion stations such as 1021, 1022, 1023, a data server 1024 to
store information respecting the corresponding integrated
28
CA 02334177 2001-02-05
vendor's business and operations, and an application server
1020 to support the reservation stations, interface with the
Reservation Server Complex 1014, and support other business
activities of the vendor. This arrangement is that of a
typical back-office computer system of a large vendor. With
this arrangement, incoming and outgoing reservation information
can be processed from multiple workstations. Accessibility to
the interactive data feeds of flight and reservation informa-
tion would be available to any computer on the integrated
vendor's network. This decentralized availability of informa-
tion would streamline reservation and related business activi-
ties in comparison to the stand-alone version 1000 and would
reduce or eliminate any need for manual transfer of data.
Each aggregator can access the Surface Vehicle Transpor-
tation Reservation Data Server 1018 to ascertain its content of
vendors and available transportation assets.
Thus the Reservation Server Complex 1014 communicates
with both reservation system customers such as 1003, 1004,
1005, 1012, and 1013 and vendors such as 1000 and 1006. The
Reservation Server Complex also communicates with a Flight Data
Provider 1001 and a Credit Card Processor 1002 via the Internet
or another communication link. The interaction between the
Reservation Server Complex and the Credit Card Processor is
used for credit validations, approvals and distributions
electronically made to a financial institution account associ-
ated with the Surface Vehicle Transportation Reservation System
Server Complex 1014.
29
CA 02334177 2001-02-05
The Reservation Server Complex 1014 comprises a firewall
server 1015 which protects the computer equipment within the
complex against intrusion by unwanted persons or programs
seeking to penetrate and possibly damage the computer software.
The Authentication Server 1016 verifies the status of incoming
data as emanating from an authorized customer or vendor. The
Web Server 1019 maintains a website of the Reservation Server
Complex with a common interface which can be used for reserva-
tion and related purposes by the customers and vendors. The
Application Server 1017 carries out the processes for the
making and changing of re:~ervations and related activities.
The Data Server 1018 stones and retrieves reservation and
reservation-related information for use by the Application
Server and the Web Server.
The Flight Data Provider furnishes information as to
arrival and departure of scheduled airline flights, which is
used by the Reservation Server Complex 1014 to determine which
reservations need to be changed or canceled to reflect changes
in such flights when a node of a trip involves a deviated
flight.
The Application Server software converts the data
supplied by the Flight Date Provider to a form readily usable
by the vendors and (in some instances) customers. Each vendor
receives real-time updates to this flight data, which updates
may be used by the vendors to monitor the status of flight
arrivals and departures at preselected airports in the vendor' s
service area.
CA 02334177 2001-02-05
The Reservation Server Complex interacts with the Credit
Card Processor to charge (or credit in the case of properly
canceled reservations) the accounts of customers and to credit
(or charge in the case of properly canceled reservations) the
accounts of vendors in accordance with the making and changing
of reservations.
Information Flow
Figure 2 shows the information flow between the Reserva-
tion Server Complex 1014 and some of the customers shown in
Figure 1. However, similar information is exchanged with all
customers. Figure 2 also shows information flow between the
Reservation Server Complex and the vendors as well as the
Flight Data Provider and the Credit Card Processor.
As shown in Figure 2, the Reservation Server Complex
receives reservation request information from customers such as
1003, 1005, and 1012, and transfers trip confirmation informa-
tion to those customers.
The reservation information normally comprises (i) the
pickup address, date and time (or for airport pickup, the
airport name, airline, flight number, and scheduled arrival
date and time), (ii) the type of vehicle desired and, if there
are multiple travelers, the number of travelers, (iii) the
dropoff address, date and time (and for airport dropoff, the
airport name and airline, and optionally the flight number, and
scheduled arrival date and time), (iv) the address of any
31
CA 02334177 2001-02-05
desired stops, and (v) credit card information unless such
information has previously been supplied.
The confirmation information normally comprises (i) as
to each vendor having an available transportation asset, the
vendor name, type of vehicle, and basic price, (ii) an invita-
tion for the customer to select a particular vendor if more
than one vendor has a transportation asset available for the
trip, and to make a reservation, and (iii) a confirmation that
the reservation has in fact been made and that the basic price
has been charged to the customer's credit card. Similar
information is provided in the event of a reservation change,
including a reservation cancellation.
The information flow between the Reservation Server
Complex 1014 and the vendors 1000 and 1006 comprises (i)
transportation asset availability and price to the server
complex and (ii) reservation information to the vendors.
The transportation assets availability and price
information comprises:
a. The area serviced by the vendor, which may be
designated:
(1) By the postal zip codes of the areas serviced;
(2) By "wild-carded" zip codes in which the last two
digits of a five digit zip code, or the last one to six digits
of a nine digit zip code are replaced by a "wild card" symbol
such as an asterisk;
(3) By airport names;
32
CA 02334177 2001-02-05
(4) By names of municipalities or subdivisions
thereof;
(5) By a radius of a specified number of miles
around a more or less central postal zip code or geographic
code; or
(6) By any combination of the foregoing designa-
tions.
b. The number of vehicles operated by the vendor in the
service area, such as three or four passenger cars, vans,
buses, handicapped vans, etc.
c. The number or percentage of each type of vehicle
which is available for reservations. In the event of calcula-
tion on a percentage basis, the total number of vehicles of
each type in the vendor's fleet is also specified. This
information may be supplied from time to time, but is prefera-
bly supplied on as frequent a basis as is practicable for the
vendor.
d. The manner in which the vendor wishes its basic price
determined, viz.:
(1) A specified price per hour or day;
(2) A specified price per mile;
(3) A fixed price for travel between specified pairs
of nodes; or
(4) Any combination of the above pricing methods.
e. The vendor's credit card account information.
The Flight Data Provider 1001 supplies information to
the Reservation Server Complex 1014 as to the status of
33
CA 02334177 2001-02-05
arriving and departing flights as well as the scheduled
departure and arrival times of future flights, including
whether the flight is on time or is deviated, and the currently
anticipated arrival or departure time for each flight.
The Credit Card Processor 1002 receives credit authori-
zation and charge/credit requests (primarily for charges to the
accounts of customers and credits to the accounts of vendors)
submitted by the Reservation Server Complex 1014, and issues
authorizations or acknowledgments and settlement confirmations
in response to the requests.
Program Organization
The computer programs which carry out the reservation
method according to the preferred embodiment of the invention
are executed by the various servers of the Reservation Server
Complex 1014. The overall supervisory portion of these
programs resides on the Application Server 1017.
Figure 3 schematically illustrates the major processes
of the programs executed by the Reservation Server Complex
1014. These comprise a Master Process Module 1030, a Security
Module 1031, a Reservation Module 1032, a Flight Module 1033,
and a Vendor Module 1034.
The Master Process Module 1030 initiates system opera-
tion, supervises the other modules, and calls for programs and
subroutines as they are needed.
The Security Module 1031 filters customer and reserva-
tion search result lists to include only those items that the
34
CA 02334177 2001-02-05
user should have access to. The Security Module also prevents
unwanted access to the Reservation Server Complex software by
hackers, bots and other persons and programs which seek to
intrude into the system for improper purposes. This module
also determines whether a communication to the software is to
be permitted to go through, and limits access to software
elements and data records in accordance with the authorized
security level of the entity seeking access.
The Reservation Module 1032 attends to the processing of
reservation requests, including providing availability informa
tion, booking reservations, monitoring the status of reserva
tions, rebooking reservations, canceling reservations, and
billing customers.
The Flight Module 1033 keeps flight information and
filters that information to determine those flights which
impact reservations which are being made or which have been
made, and generates instructions for the program to take
appropriate responsive action.
The Vendor Module 1034 processes information received
from vendors, communicates reservation information and changes
to the vendors, and attends to reservation-related financial
transactions.
Master Module Process
As shown in the flow chart of Figure 4, the process
carried out by the Master Module 1034 is as follows:
CA 02334177 2001-02-05
At Step 100 the system creates a connection to a
Reservation Database (RDB), the data of which resides on the
Data Server 1018, for use in initializing the system. This
connection is used for initialization of all functions and is
released once the initializations are complete. This connec-
tion is configured to have all changes automatically stored in
the database once the database initialization command is
finished executing.
As part of Step 100, a data cache object is instantiated
and data is loaded from the RDB utilizing the initialization
connection. To improve system performance, data in the data
cache is searched and used before the database is accessed.
The program then proceeds to Step 101.
Step 101 effects the creation and initialization of each
of the system's module implementation objects. Each module's
logic is encapsulated in Intelligent Agent Objects (object-
oriented programming). Each Intelligent Agent Object (AO)
exposes its functions for invocation via a defined set of
interface functions. Only those defined interface functions
are accessible by processes outside of each Agent Object.
The Deviation Control Process of the Flight Module 1033
is also started at step 101.
There exists one object for each of the Flight, Reserva-
tion and Vendor system modules. Step 101 utilizes the informa-
36
CA 02334177 2001-02-05
tion in the data cache created in Step 100 to determine the
number of instances of each type of Agent Object to create.
Each Agent Object is initialized with the Reservation
Database connection created in Step 100 and the data cache
created in Step 101. The Agent Object creates its own persis-
tent connection to the Reservation Database using logon
information obtained from the initialization database connec-
tion in Step 100. The Agent Object's database connection is
configured to NOT automatically save changes to the database.
One empty instance of an Active Agent Manager Object
(AAM) is created for each type of Agent Object created. The
AAM implements the system's concurrency and threading design
for use by the dispatch function in Step 102. The previously
created Agent Object is added to the proper AAM based upon the
type of AO.
Steps 102, 103, 104, 105, 106, 107 and 108 implement the
control process of the system. The control process scans the
input communications lines for a pending request, analyzes the
request, and dispatches the request to the proper Agent Object
for processing.
The dispatch process uses the system's concurrency
threading design from Step 101 to enable multiple requests to
be processed concurrently. Each request is inspected to
determine the intended destination module. The proper AAM is
37
CA 02334177 2001-02-05
chosen based upon the destination module and the next inactive
Agent Object obtained from the selected AAM.
The inactive Agent Object is marked as active and is
passed the request for processing. The dispatch process
proceeds to process another outstanding request while the
selected Agent Object is processing the previous request.
Once an active Agent Object completes processing, the
AO's database connection results are committed or rolled back
in response to the operation's success status. The Agent
Object is returned to the AAM, marked as inactive and conse-
quently freed up for future processing.
Vendor Module Process
The Vendor Module 1034 functions are encapsulated in an
Agent Object of type Vendor Agent (VA). Steps 201, 202, 203,
204, 205, 206, 207, 208, 209, 210, 211, 212, 213, 214, 215, and
216 implement the Vendor Module control process. This process
scans the input communication lines for a pending request,
analyzes the request, and dispatches it to the proper function
for processing. After processing the function returns to the
Master Process.
Accept Standby
The Accept Standby process enables a non-originating
vendor to accept a reservation which is on the Open List of an
originating vendor.
As shown in Figure 5D, the system provides an Open List
search facility in Step 220, for vendors willing to accept Open
38
CA 02334177 2001-02-05
List reservations. Non-originating vendors may accept an Open
List reservation by initiating the acceptance process.
Step 220 invokes the Security Module 1031 to ensure that
the customer has access to the Open List search process. In
Step 221 a non-originating vendor initiates the Open LIst
acceptance process once a wait-listed reservation, i.e. one on
the Open LIst, is selected for that purpose.
The system removes the Open LIst reservation from the
Open List in step 221. This action prevents other vendors from
accepting the same reservation and implements concurrency
control.
The original reservation information is queried from the
database in Step 222. A new reservation is formulated using a
trip-input function of the Reservation Module 1032, by specify-
ing the accepting vendor as the selected vendor in Step 223.
In Step 224 the Reservation Module's cancel-rebook function is
invoked specifying the original and new reservations. The
cancel rebook function is flagged to preserve the original
pricing of the reservation so the customer is protected. The
original reservation is canceled and marked as being an Open
List reservation. The new vendor is sold the new reservation
with a new reservation ID. The normal reservation sell process
is executed.
Step 225 makes a debit against the originating vendor to
account for the Open List fee.
39
CA 02334177 2001-02-05
As shown in Figure 5E, where the Open List reservation
was initiated by a traveler, Steps 226 and 227 notify the
initiating traveler of the acceptance of the reservation and
the identify of the vendor who accepted it via an automated
mobile phone call, fax or email.
Reservation search
Step 230, as shown in Figure 5F, invokes the Security
Module 1031 to ensure the user has access to the search
process.
The system facilitates a number of reservation searches
for the vendor. At Step 233 the returned list from all
searches is filtered using the Security Module's Reservation
Access function. The vendor can search for reservations by the
following criteria: time span, reservation type, and/or
reservation status.
Steps 231 and 232 determine if a time span selection is
required. The following are time span searches:
~ Since a specified date and time
~ Before a specified date and time
~ All reservations for today
~ All reservations for tomorrow
~ All reservations for yesterday
~ Reservations only for a particular date and time
~ Reservations canceled within a time span.
~ Reservations within a time span (inclusive)
CA 02334177 2001-02-05
Step 235 provides for the following searches by reserva-
tion type or status, other than a time related search:
~ Open List reservations
~ Unconfirmed reservations
~ All reservations
In Step 234, the resulting list search requirements are
stored and recalled on a periodic basis. The information is
automatically refreshed every five minutes. However, the
system processes can lengthen or shorten the refresh time based
upon the workload of the Reservation Server Complex 1014.
Reservation confirmation
As shown in Figure 5G, Step 240 invokes the Security
Module 1031 to ensure the user has access to the reservation
confirmation process.
The business logic of the process requires a vendor to
pro-actively acknowledge that a reservation has been accepted.
The vendor must select the reservation and press the Confirm
button on a menu screen. In Step 241 the business logic
ensures that the reservation is active and has not been
canceled or fulfilled. At Step 242 the business logic marks
the reservation as confirmed and returns to the vendor a unique
confirmation number for the reservation. This confirmation
number is also recorded in the Reservation Database for
historical purposes.
2 5 Reservation Book-out
41
CA 02334177 2001-02-05
As shown in Figure 5H, Step 250 invokes the Security
Module 1031 to ensure the user has access to the book-out
process.
Book-out is the process by which a vendor indicates that
a reservation has been completed. In Step 251 the business
logic ensures that the reservation is active and has not been
canceled or fulfilled.
At book-out time the vendor has the option of including
additional charges such as tolls, parking, etc. and/or overrid
ing the estimated trip pricing with actual values. Additional
charges may also be specified during the book-out process. At
Step 252 the following items may be specified during the book-
out process:
~ Credit card name, number, expiration date
~ No show indication
~ Complimentary trip indicator
~ Stop charge
~ Wait time charge
~ Toll charge
~ Number of stops
~ Total wait time
~ Parking charge
~ Trip time
~ Vehicle number
~ Incidental charge and note
~ Driver name
42
CA 02334177 2001-02-05
~ General note
The trip is re-priced at Step 253 using the actual trip
information collected at Step 252.
At Step 254 the amount to be charged is recalculated
based upon the book-out values entered by the vendor, and the
customer' s credit card account is settled once a reservation is
booked out successfully. That is, the charge previously sub-
mitted to the Credit Card Processor 1002 for authorization is
settled (the charge is applied to the customer's credit card
account).
Flight Filter by Reservation
As shown in Figure 5I, Step 260 invokes the Security
Module 1031 to ensure the user has access to the reservation
flight collection process.
The Vendor Module 1034 provides for access to the
collection of data respecting flights for reservations held by
the current vendor. This information is utilized by the Flight
Module 1033 to report the status of only those flights for
active reservations a vendor has. The following conditions are
applicable:
~ Step 260 verifies that the current user is a
vendor. The Security Module 1031 is invoked to
determine the user's vendor status and the ven-
dor's identification number.
~ At Step 261 the Reservation Database is queried
for all reservations held by the current vendor,
by vendor ID, within two hours prior to the
current time and twelve hours in the future.
43
CA 02334177 2001-02-05
~ At Step 262 each reservation is inspected and a
unique list of aircraft identifiers is gathered
for the entire list.
~ The list of collected flights is then returned to
the caller for further processing.
Customer discounts
As shown in Figure 5J, Step 270 invokes the Security
Module to ensure the user has access to the customer discount
set/get process.
Step 270 verifies that the current user is a vendor.
The Security Module 1031 is invoked to determine the user's
vendor status and the vendor's identification number. At Step
271 the customer for which the discount plan is to be Set/Get
is selected. The user can search for customers by last name or
ID and the customer access function of the Security Module 1031
is invoked to restrict the returned list to only those custom-
ers a vendor has access to in Step 272.
The system facilitates entering the customer discount
plan. The effective date of the discount as well as a list of
volume price breaks and discount percentage tables are input at
Step 273.
At Step 274 all discount plans are implemented using end
dating and are effective indefinitely. The business logic
implements end dating by removing all records having dates
prior to the indicated effective date. The new pricing
information is assumed to take effect when indicated and to be
44
CA 02334177 2001-02-05
valid until it is changed. Then Step 274 adds records for the
previous data values using the new effective date less a
predetermined short period of time, such as one second. The
Reservation Database is inspected to combine any duplicate
records that may have been created with the same values and end
time. The new records are added to the database with an end
time of 12/31/2099 23:59:59, i.e. far in the future.
Place Standby
As shown in Figure 5B, at Step 281 the system supports
an Open List feature. The Open List feature maintains a
waiting list of reservations for each applicable vendor, and
has a Farm-Out aspect wherein one vendor may accept a reserva-
tion on the Open List of another vendor. Open List also
enables last minute travelers to make reservations that would
normally fall outside the time validation parameters of the
vendors (e.g. a reservation attempted to be made too close to
the pickup time).
Open List is a highly sophisticated and secure wait list
feature. The customer and/or traveler is protected from price
changes once the corresponding trip is placed on the Open List .
Due to the nature of the Farm-Out aspect of Open List
there is a vendor change implicit in the Open List logic.
Step 281 invokes the Security Module 1031 to ensure the
user has access to the Open List process. Access is granted in
Step 282. The system does the following for a Farm-Out
scenario:
CA 02334177 2001-02-05
~ A reservation is made in the normal fashion for a
vendor.
~ The original reservation is delivered and con-
firmed by the original vendor.
~ The original vendor makes a determination that the
reservation should be placed on the Open List to
be farmed out, selects it from his list of active
reservations, and initiates the Open List cycle.
~ At Step 283 the system verifies that the reserva-
tion on the Open List is active. Processing will
stop if the reservation is in any other state.
~ At Step 284 the system records the reservation ID
and the time the reservation is put on the Open
List, in the Reservation Database.
Search Standby
As shown in Figure 5C, the system provides an Open List
search facility for vendors interested in accepting as Open
List reservation.
Step 290 invokes the Security module 1031 to ensure the
user has access to the Open List search process.
Step 291 system queries the Open List for open reserva-
tions within a threshold time period (e.g. 12 hours prior to
pickup time) .
At Step 292 the Open List reservations are filtered to
include only those reservations that the inquiring vendor
supports, i.e. those reservations having pickup and dropoff
nodes within the vendor's service area.
The reservation list is further filtered to remove all
reservations that were placed on Open List in Step 293 by the
inquiring vendor.
46
CA 02334177 2001-02-05
Security Module
The Security Module 1031 functions are encapsulated in
an Agent Object of type Security Agent (SA). The Security
Agent facilitates user logon and validates that the user has
access to individual features, reservations and customers in
and of the system. The processes carried out by the Security
Module are shown in Figures 6A to 6C.
Authentication
As shown in Figure 6A, Step 301 implements the authenti-
nation process. Each user must be authenticated onto the
system prior to being granted access to its features and data.
The authentication process looks up the user in the Authentica-
tion Database (ADB) by performing a case sensitive match to all
other user names in the ADB. If a match is found the ADB is
read and the password in the user record is compared ( including
case matching) with the supplied password. A valid user is
declared if both passwords exactly match.
Once successfully authenticated, the user is assigned a
security token. User information is encoded into the security
token to improve performance by eliminating the need to
constantly look up information in the Authentication Database.
The security token maintains the "state" of the user. The
following are features of the security token:
~ Contains all the roles the user is allowed to
play.
~ Contains all the rights the user is assigned.
47
CA 02334177 2001-02-05
~ Contains the default time zone, country code,
state code and currency code of the user.
~ Contains the user name and user ID.
~ Contains the vendor ID and network vendor ID if
the user is assigned to a vendor.
~ Contains the point of sale ID if the user is
assigned to a point of sale.
~ Contains the GDS the user is assigned to if the
user is assigned to a GDS as a point of sale.
~ The token has an expiration time set to 24 hours
from logon time. This prevents the user from
never logging out.
Roles and rights
The security system is based upon a roles and rights
paradigm. There are specific access rights for each function
in the system. There exist a limited number of roles users can
play. Each role is assigned one or more access rights and each
user is assigned one or more roles.
Unauthorized personnel can access restricted customer
information if the user has granted knowledge of his or her
password. All customer access functions in the system accept
an optional password. Each function attempts access under
"normal" conditions. If access is denied and a password was
supplied, the password access is attempted.
2 5 Subsystem access
At Step 302 each user is granted access to one of three
subsystems (viz. the Vendor Module, the Reservation Module, and
the Flight Module) once the user is authenticated on the
48
CA 02334177 2001-02-05
system. The user's rights and roles control each subsystem
access. All users have access to the Authentication subsystem.
Customer authorization access
As shown in Figure 6B, at Step 310 the SA exposes a
Customer Information Access Authorization function. To protect
one user's information from unauthorized access by others, all
customer searches and accesses are filtered by user assignments
to points of sale, vendors and customers. In step 310 the SA
extracts user detail information pertaining to the assignment
of the user to each of the aforementioned entities.
At Step 311 the SA then examines the requested informa-
tion for a match on the extracted information and the user's
information. The permitted accesses are:
~ A customer can access his or her own information.
~ A user associated with a point of sale can access
a customer made by that point of sale.
~ A vendor can access any customer for that vendor.
~ A network vendor administrator has access to any
customer for any vendor assigned to their network,
even across vendors.
~ A user is allowed access to restricted customer
data if the user has the customer's logon pass-
word.
~ A Reservation Server Complex administrator has
access to all customers.
~ All other access is denied.
A user is granted access to requested information by
return of the process to the call in Step 312 if the user meets
one or more of the criteria in Step 311. The information is
49
CA 02334177 2001-02-05
made unavailable in Step 313 if the user does not meet any
criteria and consequently the user is denied access to the
information.
Reservation Authorization Access
As shown in Figure 6C, at Step 320 the SA exposes a
reservation information access authorization function. To
protect one user's information from illegal access by others,
all reservation searches and accesses are filtered by user
assignments to points of sale, vendors and customers. In Step
320 the SA extracts user detail information pertaining to the
assignment of the user to each of the aforementioned entities.
At Step 321 the SA then examines the requested informa-
tion for a match on the extracted information and the user's
information. Access is permitted as follows:
~ A user associated with a customer can access his
or her own reservation(s).
~ A user associated with a point of sale can access
a reservation made by that point of sale.
~ A vendor can access any reservation for that
vendor.
~ A network vendor administrator has access to any
reservation for that network, even across vendors.
~ A Reservation Server Complex administrator has
access to all information.
~ A vendor cannot access any reservation with
respect to which the vendor is a commissioned
vendor. This would allow a commissioned vendor to
modify another vendor's reservation. Once the
reservation is sold it is out of the commissioned
vendor's hands.
CA 02334177 2001-02-05
~ A Reservation Server Complex administrator has
access to all reservations.
~ All other access is denied.
At Step 322 the user is granted access to the informa-
tion by return of the process to the call if the user meets one
or more of the criteria in Step 321. At Step 323 the informa-
tion is made unavailable if the user does not meet any of the
criteria and consequently the user is denied access to the
information.
Reservation Module
The functions of the Reservation Module 1032 are
encapsulated in an Agent Object of type Reservation Agent (RA) .
The Reservation Module process is implemented as shown
in Figures 7A to 7T. The Reservation Module 1032 scans the
input communications lines for a pending request, analyzes the
request, and dispatches it to the proper function for process-
ing.
Steps 4000, 4001, 4002, 4003, 4004, 4005, 4006 4007,
4008, 4009, 4010, 4011 and 4012 implement the Reservation
Module control process. This process scans the input communi-
cations lines to the Reservation Server Complex 1014, subject
to the control of the Security Module 1031 and Master Process
Module 1030, for a pending request applicable to the Flight
Module, analyzes the request, and dispatches the request to the
proper function for processing. After processing, the function
returns to the Master Process Module 1030.
51
CA 02334177 2001-02-05
Availability check
As shown in Figure 7C, at Step 4030 the Availability
Check process has three main functions, viz:
~ To price a trip once a match is found;
~ To check vendor support of a trip; and
~ To check asset availability for an individual
vendor for a specific vehicle type or across all
vendors and vehicle types.
At Step 4030 the Availability Check process invokes the
Security Module 1031 to ensure the user has access to this
process.
A number of different techniques are used to find
vendors who are able and willing to furnish a transportation
asset for a trip. These techniques include checking lanes,
vendor service radius, vendor service on a per mile basis, and
vendor service on a per hour basis.
A service point is defined as a location on the earth.
It has a name, longitude, latitude, street address, city,
state, zip code and/or zip+4 code. A service point may be a
well-defined place such as Yankee Stadium or it may be an
airport such as Newark International Airport (airport code
EWR) .
At Step 4031 the Trip Input process is invoked to
accept, format and validate the reservation data. Operations
are discontinued in the event of invalid data.
52
CA 02334177 2001-02-05
At Step 4032 the trip end points are extracted from the
reservation information. The vendor's lanes for the vehicle
type are extracted from the Reservation Database.
Vendor market support
The following details the methodology for determining
whether or not a particular vendor supports a particular trip:
Zip code wild carding
The system allows vendors to "wild card" zip codes to
simplify their market definition process. A wild-carded zip
code is one wherein only the first three digits of a five-digit
or nine-digit zip code are specified, the remaining digits
being replaced by a wild card symbol, preferably an asterisk.
The shortened version of the zip code is assumed to match all
other zip codes that also begin with the same three digits.
During Availability Check the system can take into
account wild-carded zip codes to find expanded matching service
areas for vendors.
Lane Search for Vendors(sJ
A lane is a path between two service points . Prices and
vehicles types are associated with each lane, and time periods
when service is available may be associated as well. Vendor
and transportation asset availability are determined as
follows.
At Step 4032 the first pickup point and the last dropoff
point (the "trip end points") are extracted from the trip's
53
CA 02334177 2001-02-05
node list . From these end points the time period for which the
vehicle will be needed can be estimated by the vendor.
At Step 4032 all lanes for each vendor are read from the
Reservation Database and filtered by vehicle type.
The availability of a vendor for the trip is checked by
comparing the service points of all lanes in the Reservation
Database for each vendor against all pickup, dropoff and stop
service points for the trip. When no vendor matches are found
in the initial search, an expanded search is conducted utiliz-
ing a zoom out feature. Availability Search processing stops
when (i) the initial search results in at least one vendor
match, or (ii) the expanded search is concluded.
The following search order occurs and implements the
zoom out feature:
~ At Step 4033 an exact match for all data is looked
for first: street, city, state, zip and country.
~ At Step 4034 an exact match is looked for in only
the street if the street specifies an airport
(airport search?.
~ At Step 4035 an exact match is looked for in the
zip code only.
~ At Step 4036 an exact match is looked for in the
city and state.
~ At Step 4037 a match is looked for in a wild
carded zip code.
At Step 4038, when one or more vendor lane matches are
found, information as to the available vendors, with the vendor
having the lowest total price for the lanes of the trip being
54
CA 02334177 2001-02-05
marked by (highlighting or otherwise) is transferred to Step
4039.
At Step 4039 a determination is made as to whether the
vendor has entered a price of $0.0 for an applicable node,
which price indicates that the vendor has excluded the trip
from its inventory - in which event that vendor is deleted from
the list of available vendors for the trip.
Thus each vendor can specify a large service area with
zip code wildcarding while omitting areas that he does not want
to service, such as high crime areas, by specifying a $0 price
for lanes having nodes in that area. At Step 4040 a vendor is
declared to be unavailable for a trip if a lane included in a
match and has the price of $0Ø
Additional pricing techniques are utilized if a lane
match is not found. Pricing on a per mile basis is performed
at Step 4048 and pricing on a per hour basis is performed at
Step 4047. At Step 4041, once a match is found the trip is
priced using the Trip Price process of the Reservation Module
1032. The Trip Price process allocates commissions, transac-
tion fees, and rebates; and calculates discount amounts.
Radius Vendor Search
At Step 4042 the system utilizes a mapping and routing
process to locate a vendor by determining whether the trip
service points are within an area defined by a list of vendor
specified radii around a more or less "central" point which is
CA 02334177 2001-02-05
usually the vendor's operational headquarters. Availability of
a vendor is declared if all service points of the trip fall
within an area def fined by one or more of the vendor' s specified
radii. Step 4044 prices the trip using mileage and radii
prices. Otherwise, at Step 4043 a per hour pricing model is
used.
At Step 4045 the trip is then priced using per mile
pricing. The trip distance and time is determined by a mapping
and routing process with appropriate time allowances for
vehicle return and clean-up.
Per Hour Availability
At Step 4045 the process automatically switches to a per
hour pricing paradigm upon request of the user or if the
specified trip exceeds the vendor specified threshold of
distance or time. The trip distance and time is determined by
a mapping and routing process with appropriate time allowances
for vehicle return and clean-up.
Tilp Time Span Calculation
The process supports the vendor specification of minimum
pickup and drop-off margins (time added to each end point of a
trip to account for traffic, clean-up and return to base, etc) .
Additionally each lane may have a specific margin on each node
thereof. The greater of (i) the vendor's overall margin
preferences and (ii) the time parameters specified by the
vendor for the lane involved, is selected.
56
CA 02334177 2001-02-05
A pickup and dropoff time margin is added to the
predetermined trip time prior to the Availability Check. The
minimum required pre-trip pickup margin for the selected lane
is subtracted from the initial pickup time and the minimum
required dropoff margin for the selected lane is added to the
predetermined last dropoff time for the trip.
At Step 4049 the trip time span is calculated as the
time between the first pickup node time and the last dropoff
node time. All times are maintained relative to Greenwich Mean
Time ( "GMT" ) .
Asset Availability Check
After each vendor whose service area encompasses the
trip nodes has been identified, and the time span of the trip
has been determined, the vendor's transportation asset avail-
ability is checked to determine whether a vehicle of the type
required is available for the desired reservation.
Transportation asset availability data is stored in the
Reservation Database as a time ordered sequence of availability
counts. The availability data is organized by vendor and
vehicle type (keyed by vendor ID and asset type ID).
The stored availability data is the number of vehicles
available for reservation from the last data point (non-
inclusive) up to and including the time of the next data point
(inclusive).
The process selects the minimum count of vehicles for
the indicated vendor and vehicle type during the time span of
57
CA 02334177 2001-02-05
Since each lane is associated with an estimated time and
distance, the lane information can also be used for per hour
and per mile price calculations.
Reservation Sell
The reservation process that actually reserves the
vehicle is termed the "sell". The following steps are per-
formed to sell a trip.
As shown in Figure 7G, at Step 4060 the Reservation Sell
function invokes the Security Module 1031 to ensure the user
has access to this process.
At Step 4061 the Trip Input function is invoked to
gather and validate information respecting the trip. At Step
4062 processing does not proceed if the information is not
validated. The process calls Step 4030 to invoke the Asset
Availability function.
At Step 4063 the vendor's vehicle availability and the
price of the trip are determined. This process is different
than the Availability Check previously described, in that the
vehicle availability check of the Sell process locks the
availability records to ensure that the transportation asset (s)
remains available during the remainder of the Sell process.
At Step 4064 the transportation asset is de-allocated
from the vendor's availability list by decrementing the
availability counts of all related records during the time span
of the trip as determined by the reservation information
59
CA 02334177 2001-02-05
provided by the customer and the lane information provided by
the vendor. New records are created corresponding to the trip
end points, if the end point dropoff time does not match any
existing record. A resolution of a short period of time such
as one second, for example, is utilized for end dating of
records.
At Step 4065 the incidental charges for the trip
including disbursements are determined. These incidental
charges are stored with, or linked to the reservation informa-
tion.
At Step 4066 a unique reservation confirmation number is
generated and returned to the user.
At Step 4067 the reservation is marked as active and new
to indicate that the vendor needs to transfer the reservation
information to its system.
At Step 4068 the Credit Card Authorization function is
invoked to perform authorization of the estimated trip price.
At Step 4069 processing stops and the reservation is not made
if authorization is not received from the Credit Card Processor
1002.
At Step 4070 the selected customer's profile is in-
spected to determine if the customer has requested automatic
confirmation of the reservation. An e-mail or facsimile
communication is automatically formatted and sent if such a
request has been made.
CA 02334177 2001-02-05
At Steps 4072 and 4073 the reservation confirmation and
related changes to the database are effected if an error was
not encountered during processing. At Step 4071, in the event
of any error during processing, all changes are automatically
rolled back, leaving the trip unsold, credit card unprocessed
and availability as-is.
Reservation Cancel
At Step 4100 the Reservation Cancel function invokes the
Security Module 1031 to ensure the user has access to this
process.
At Step 4101 additional validation checks are performed
to ensure that enough time is available to facilitate the
cancellation. For example, a customer is not permitted to
cancel a reservation less than a predetermined amount of notice
time prior to the pickup time, as specified by the affected
vendor (1 Hr. as default if the vendor has not specified such
a notice time) .
The validation checks are:
~ The cancellation request is received in advance of
the pickup time by an amount at least equal to the
notice time specified by the vendor (Step 4101);
~ The cancellation request is received in advance of
the pickup time by an amount at least equal to the
notice time required by the Reservation Server
Complex 1014 (typically 1 hour) (Step 4101); and
~ Only an active reservation can be canceled (Step
4102 ) .
61
CA 02334177 2001-02-05
At Step 4104 a unique cancellation number is generated
and returned to the user if a cancellation number was not
supplied by at Step 4103 the calling function. The cancella-
tion ID, canceling user, and cancellation request time are
recorded in the Reservation Database.
At Step 4105 the status of the reservation is changed to
canceled and the reservation record is marked as needing to be
sent to the vendor.
The transportation asset (s) associated with the canceled
reservation are reallocated by a process which is the reverse
of the Reservation Sell process allocation method. At Step
4106 available asset counts are incremented to reverse the
prior decrementing thereof.
At Step 4107, if there are other reservations linked to
the canceled reservation, the user can elect to cancel all
linked reservations. Each linked reservation is read from the
Reservation Database and the Reservation Cancel function is
invoked for each reservation in turn, with the cancellation
number of the first reservation being supplied in order to
prevent new cancellation numbers from being generated.
Linking of Reservations
Reservations can be linked to each other in a number of
ways. By linking reservations, the system can take automatic
actions such as canceling all reservations in a group, in
62
CA 02334177 2001-02-05
response to user requests. Reservations can be linked in the
following ways:
~ A unique number can be assigned to each reserva-
tion as a group identifier.
~ A cancel-rebook situation automatically links the
canceled reservation to the rebooked reservation
and vice-versa.
~ Two reservations are identified as originating and
returning reservations when Trip Reversal is
utilized to book a returning reservation.
The changes to the Reservation Database associated with
cancellation are effected if an error was not encountered
during processing. In the event of any error, at Steps 4108
and 4110 all changes are automatically rolled back, leaving the
trip uncanceled and transportation asset availability as-is.
Reservation Change
As shown in Figure 7M, at Step 4200 the Reservation
Change function invokes the Security Module 1031 to ensure the
user has access to this process.
At Step 4201 validations are performed to ensure enough
time is available to facilitate the change. Both the Reserva-
tion Server Complex 1014 and the selected vendor have minimum
time to change thresholds. The larger of the two are utilized
to ensure there is enough time to make the change . Assuming all
checks pass, an "OK to Change" condition is declared. Addi-
tionally, the fare class of the reservation is inspected to
ensure that the minimum change time requirements of the chosen
class are not violated.
63
CA 02334177 2001-02-05
At Step 4202 the status of the reservation is validated
to ensure it is an active reservation.
At Step 4203 the Trip Information Input process is
invoked to gather and validate information as to the trip for
which a reservation is to be changed. Processing does not
proceed if the validation of the information fails. The Trip
Information Input process utilizes any information passed to it
from the traveler's itinerary to pre-fill fields, and performs
automatic availability determination. At Step 4204 processing
stops if the new data does not pass the validation checks.
At Step 4205, if there is a change to the vendor
information, then a Cancel-Rebook situation is declared. At
Step 4206 the Reservation Cancellation process is invoked to
cancel the original reservation, and the Reservation Sell
process is invoked to sell the changed reservation. Otherwise
the original reservation is canceled while being flagged that
this is only a change and not a real cancellation; so that
cancellation charges, notice times and ID requirements are
relaxed. This change method allows assets to be reallocated in
a common portion of the process. At Step 4207 the Reservation
Cancel process is invoked to release the old reservation
information while taking into account that a Sell will follow
immediately. The reservation confirmation number is also
preserved.
64
CA 02334177 2001-02-05
At Step 4208 the reservation is marked as changed, to
indicate that the vendor needs to transfer the information to
the vendor's system; and the reservation remains active.
The changes to the database are effected at Step 4209 if
an error was not encountered at Step 4210 during processing.
In the event of any error, at Step 4211 all changes are
automatically rolled back, leaving the trip unchanged and
availability as-is.
Reservation Search
As shown in Figure 7P, at Step 4300 the Reservation
Search function invokes the Security Module 1031 to ensure the
user has access to this process.
At Step 4301 a user has the capability to look up
reservations by ID or customer name, passenger last name, or
date range. At Step 4302 each reservation that is found is
checked for a linked reservation, and the linked reservations
are also read from the Reservation Database.
At Step 4303 the returned reservation list is filtered
to remove any reservations that the user does not have access
to. The Reservation Access function of the Security Module
1031 is utilized to effect this function.
CA 02334177 2001-02-05
Trip Reversal
Trip Reversal is a feature that facilitates the captur-
ing and selling of a return trip.
As shown in Figure 7Q, at Step 4400 the Trip Reversal
function invokes the Security Module 1031 to ensure the user
has access to this process.
At Step 4401 the return date and time is accepted from
the user, the user's itinerary, or the airline reservation
system's PNR record. At this step the return flight information
can also be specified by the user. At Steps 4402 and 4403
return trip airport pickup location, time and date will be pre-
filled if the return flight information is specified.
Alternatively, at Step 4403 the process can look up the
return flight schedule and pre-fill the airport pickup time and
data based upon when and where the flight is schedules to
return.
At Step 4404 each node in the reservation is then
reversed in time order sequence, adjusting the time to reflect
the new return time. At Step 4405 the last dropoff node of the
original reservation becomes the first pick up node of the new
reservation, with the return date and time as its node time.
Each node of the original reservation has a time difference (OT
or Delta time) calculated from the last dropoff time to each
preceding node. The new nodes are generated by reversing the
time ordered sequence of the original nodes and setting the
66
CA 02334177 2001-02-05
time associated with each new node to the new first pickup time
plus the sum of the corresponding DT intervals from the
original trip.
At Step 4406 the Trip Input function is invoked to allow
the user to review and/or modify the trip information. At Step
4407 the Reservation Sell function is then invoked to reserve
the new trip.
Trip Input
The Trip Input module accepts trip parameters and
formats them into a valid reservation record. User conve
niences such as automated address completion, customer lookup
and preferences are supported here.
As shown in Figure 7S, at Step 4510 the Trip Input
function invokes the Security Module 1031 to ensure the user
has access to this process.
Customer Search
At Step 4511, to facilitate pre-filling information, a
user has the capability to look up customers by ID or last
name. The returned customer list is filtered to remove any
customer that the user does not have access to. The customer
access function of the Security Module 1031 is utilized to
provide such filtering.
67
CA 02334177 2001-02-05
Profiles
At Step 4512, once a customer record is located, the
user will be granted access to the customer's profiles.
Profiles are records in which customer preferences can
be saved, restored and used to pre-fill fields. Customer
information saved in a profile includes:
~ Vehicle preferences.
~ Confirmation preferences.
~ An unlimited number of preferred addresses, any
one of which can be selected to pre-fill either a
pickup or dropoff address.
~ Preferred pickup and dropoff addresses.
~ Preferred vendors.
~ Vendor payment terms.
~ Vendor discount number.
~ Cost center.
~ Voucher.
~ Two preferred credit cards, either one of which
may be selected at reservation time.
~ Preferred driver name.
~ Directions.
Input and Validation
At Step 4513 input data is entered by the user or pre-
filled from the Passenger Name Record obtained from the travel
agent or the traveler's itinerary. The supplied information is
populated into the data input fields and a working reservation
object is generated.
68
CA 02334177 2001-02-05
The Trip Input process performs validations at Steps
4514, 4515, 4516, 4517, 4518, 4519, 4520, and 4521 on all data
entered. The following are the validations performed. It is
a assumed that each of these data elements were also input by
the user.
Vehic% type
At Step 4514 the selected vehicle type is compared to
all vehicle types in the data cache. A valid vehicle type is
declared when a match is found.
Discoun t
At Step 4525, if a discount was specified, it must be
valid for the selected vendor and customer who is to receive
credit for the trip. There must also be a customer who gets
credit for the trip or the discount is not valid.
Nodes and stops
At Step 4516 validation and related processing is done
to:
~ Ensure that there are at least two nodes.
~ Perform address completion using the Address
Validation/Completion process.
~ Ensure the City/State pair match the postal zip
code specified, giving preference to the zip code.
~ Convert the local time associated with each node
to Greenwich Mean Time.
~ Ensure that each node is unique in the reservation
by comparing the node Greenwich Mean Time and
address information to the corresponding time and
information associated with each other node in the
reservation.
69
CA 02334177 2001-02-05
~ Invoke the Address Validation/Completion process
to reduce the user input time, each time a node is
entered, whether it is for a pickup or a stop,
~ Detect additional, chargeable stops from the input
data, by scanning each passenger's pickup and
dropoff points) and determining uniqueness based
upon the street, city/state, postal zip code, and
time of each node. Additional chargeable strops
are identified as any unique node other than the
first pickup and last dropoff nodes.
The user may specify additional stops that are outside
of a normal lane of the transportation asset. An additional,
chargeable stop is declared whenever more than two non-unique
nodes are identified in a trip.
The user may request additional, chargeable wait time.
Passengers
At Step 4517 validation and related processing is done
to:
~ Ensure there is at least one passenger.
~ Ensure the number of passengers does not exceed
the capacity for the selected vehicle, taking into
account the driver of the vehicle.
~ Ensure the airline code entered is valid by
checking the three character airline code against
a stored list of valid airline codes. Ensure the
remaining information (flight number) is between
one and four numeric digits.
~ Ensure that if either an airline or a flight is
specified, both the airline and flight are speci
fied.
~ Ensure each passenger has a single pickup and a
single dropoff node.
~ Ensure that if a customer ID was specified for the
passenger, that the passenger's name matches the
customer ID on file.
Times
CA 02334177 2001-02-05
At Step 4518 validation and related processing is done
to:
~ Reorder all nodes in time ordered sequence.
~ Ensure that all nodes have different times and
addresses; i . a . to ensure that a vehicle cannot be
required to be in the same place at different
times or in different places at the same time.
~ Ensure that the pickup time of each passenger is
before the dropoff time.
~ Ensure that the travel time from the operational
headquarters of the selected vendor to the first
pickup node as specified by the selected vendor is
less than the difference between the current time
and the pickup time.
~ Ensure that a passenger cannot be picked up and
dropped off at the same node.
~ Ensure that the difference between the current
time and the first pickup time greater than a
threshold set by the selected vendor.
~ Ensure there is enough time allocated for the trip
by utilizing the Mapping and Routing process to
estimate the time for the trip, utilizing the
locations of the first pickup node and the last
dropoff node.
~ Ensure there is enough time to make the first
pickup, using the Mapping and Routing module to
estimate the time to the first pickup from the
operational headquarters of the selected vendor.
~ Ensure there is enough time for the trip, taking
into account any additional lead time specified by
the selected vendor for the selected lane. For
example, the vendor may require additional notice
for certain types of vehicles and/or certain
amenities.
~ Ensure the last dropoff time is after the first
pickup time plus any applicable wait time.
Credit card
At Step 4519 validation and related processing is done
to:
71
CA 02334177 2001-02-05
~ Clean up credit card input fields; remove all
spaces, commas and dashes.
~ Check the customer's credit card information (and,
if applicable, credit card information received
form vendors) using the Credit Card process
validation function.
~ Verify that all required credit card information
is present, including credit card number, holder
name and expiration date.
~ Verify that the expiration date is not prior to
the current month.
~ Verify that the proper number of digits have been
entered for the selected credit card type.
If all validations pass at Step 4520, then at Step 4521
the Trip Input process performs an automatic selection of the
customer who is to receive credit for the trip for statistical
purposes. The first customer in the passenger list associated
with the reservation is chosen as the primary candidate. If
the customer is part of a corporation having regional subdivi-
sions, the customer's regional subdivision is credited with the
trip. Otherwise the customer's name is utilized.
Flight Module
The functions of the Flight Module 1033 are encapsulated
in an Agent Object of type Flight Agent (FA).
The Flight Module facilitates vendors or customers
checking the current status of flights that are within United
States airspace but can also check the current status of other
flights so long as the information needed is available from the
Flight Data Provider 1001.
72
CA 02334177 2001-02-05
Steps 5000, 5001, 5002, 5003, 5004, 5005, 5006 and 5007
implement the Flight Module control process. This process
scans the input communications lines to the Reservation Server
Complex 1014, subject to the control of the Security Module
1031 and Master Process Module 1030, for a pending request
applicable to the Flight Module, analyzes the request, and
dispatches the request to the proper function for processing.
After processing the function returns to the Master Process
Module 1030.
The Master Process Module 1030 starts the Flight
Deviation Control Process of the Flight Module 1033 as a free
running process. This process runs continuously and periodi
cally (typically every five to ten minutes) checks for deviated
flights. The Flight Deviation Control Process begins at Step
5600.
Flight display format
At Step 5101 the arrival time of each flight is adjusted
to reflect the arrival time in the time zone of the destination
airport; and at Step 5102 the departure time of the flight is
adjusted to reflect the time at the originating airport.
At Step 5103 the following information is formatted for
the flight records:
~ Flight record ID. This is a unique number as
defined by the Flight Data Provider 1001.
~ Aircraft ID.
~ Originating airport.
73
CA 02334177 2001-02-05
~ Departure time.
~ Aircraft status.
~ Arrival airport.
~ Arrival time.
~ Original arrival time.
~ Original arrival airport.
~ Early or late time.
Flight List Lookup
The Flight Module 1033 provides for the lookup, filter-
ing and display of a list of flight records. At Step 5200 the
Flight List Lookup function invokes the Security Module 1031 to
ensure the user has access to this process. Flight records
accessed by a customer are limited to records of those flights
for which the place of pickup or dropoff of a reservation made
by or for that customer is an airport and the pickup or dropoff
is associated in the reservation with a respective arrival or
departure of the flight. Additionally, provision is made for
ad-hoc lookups by airport, full or partial flights.
Each flight record in the selected list is processed at
Steps 5201, 5202 and 5205 to determine if there is a deviation.
A deviation is declared when the flight's current arrival time
exceeds a threshold time variation (earlier or later) from the
original flight arrival time. For example, a deviation is
declared if the arrival time changes to one more than a
threshold amount by a vendor (e. g. ten minutes) after or more
than a threshold amount by a vendor (e. g. ten minutes) before
74
CA 02334177 2001-02-05
the originally scheduled arrival time. A deviation is also
declared it the current destination airport is not the same as
the original destination airport.
At Step 5201 the Reservation Database is read to deter-
mine the search criteria. Information from the Flight Data
Provider 1001 is searched using these criteria. The returned
list of flights is used for format and display purposes.
At Steps 5203 and 5204, a flight is added to the display
list if a deviation is declared and the user has elected to
view only deviated flights. The flight is added to the display
list regardless of its deviation status if the deviated flight
filter is disabled. At Step 5204 each flight record is
formatted for display, using the Flight Display function of the
Flight Module 1033.
At Step 5206 the resulting list search requirements are
stored and recalled on a periodic basis. Step 5205 ensures
that all flights in the list are displayed before updating the
data. The flight information is automatically refreshed every
five minutes. However, at Step 5207 the Reservation Server
Complex 1014 is programmed to increase the refresh interval
when the workload of the complex is heavy, and to decrease the
refresh interval when the workload of the service is light.
At Step 5208 automatic flight update and display is
stopped upon request of the user.
2 5 Add-hoc Flight Lookup
CA 02334177 2001-02-05
The Flight Module 1033 provides users with access to
information respecting a single flight upon request. At Step
5300 the Flight List Lookup function invokes the Security
Module 1031 to ensure the user has access to this process.
At Step 5301 the aircraft ID is accepted from the user.
Step 5302 verifies that the aircraft ID is properly presented,
and begins with at least three characters followed by at least
one numeric digit. The database is queried at Step 5303 for a
match of all current aircraft IDs that have the same beginning
characters as the input request, the returned data (if any)
being a list of one or more flight records. At Step 5304 each
flight record is formatted for display and returned to the user
utilizing the Flight List Lookup function.
Integrated Flight Lookup
As shown in Figure 8F, the Integrated Flight Lookup
process begins at Step 5500. The Flight Module 1033 provides
users with automated lookup of flights for which reservations
exist in the Reservation Database. At Step 5400 the Integrated
Flight Lookup function invokes the Security Module 1031 to
ensure the user has access to this process.
At Step 5401 the Flight Filter by Reservation function
of the Vendor Module 1034 is invoked to collect a list of
flights that for all the active reservations for a specific
vendor. At Step 5402 the list of flights is then passed to the
76
CA 02334177 2001-02-05
Flight Lookup function of the Flight Module 1033, so that the
results can be formatted for display.
Flight Deviation Control
As shown in Figure 8G, the Flight Deviation Control
process starts at Step 5600.
The Master Process Module 1030 starts the Flight
Deviation Control process during initialization. This process,
which runs continuously until stopped, scans all reservations
in the Reservation Database for the current vendor and reallo-
Gates transportation assets for reservations that have flights
that have deviated beyond a time threshold from their origi-
nally scheduled arrival information, or that have been di-
verted.
At Step 5601 all reservations currently in the system
are scanned to gather a corresponding list of flights. The
reservations are filtered by pickup and dropoff time and a time
limit of up to 12 hours from the current time is used as the
threshold for inclusion in the flight list. The 12 time limit
is taken from an internal variable and may be changed as
desired.
The flight information of each pickup reservation
included in the corresponding list is compared against the
current list. A flight is added to the current list if it is
not already present in that list.
At Step 5602 a numerical index variable is incremented
for each flight in the flight list and compared to a list count
77
CA 02334177 2001-02-05
numerical value corresponding to the length of the list. All
flights are declared processed when the index variable value
reaches the list count value.
At Step 5603 information respecting the next flight is
retrieved from the flight list and the index variable is
incremented. The flight information is stored in a local
variable.
At Step 5604 the processed flight list is scanned to
determine if information respecting the current flight has been
processed already.
At Step 5605 information respecting the current flight
is added to the processed list if this is the first time
information respecting that flight has been processed.
At Step 5606 an aircraft ID is formulated by concatenat-
ing the three letter airline code with an ASCII representation
of the flight number; and the Flight Database table is scanned
by aircraft ID.
At Step 5607 the last update time of all flights in the
Flight Database is scanned and the latest update time is
selected. The difference between the latest update time and
the current time is compared to a threshold value. A data
provider alert is declared if the time between last update and
the current time exceeds the threshold value; that is, if more
than the threshold amount of time has elapsed since the prior
update.
78
CA 02334177 2001-02-05
At Step 5608 the results of the Flight Database scan by
aircraft ID are examined to determine if any flight information
was found. A result set count of zero indicates that there was
no information for the requested aircraft ID in the database.
At Step 5609 all flight times are adjusted to reflect
the corresponding flight times as specified in the local time
zone of the airport for which the time is applicable, and to
check for date rollover. Arrival times are adjusted using the
time at the destination airport and departure times are
adjusted using time at the originating airport.
A date rollover is declared when an arrival time is six
hours past the last update time of the flight in question.
This is done because the Federal Aviation Administration does
not provide the arrival date and the same is therefore not
available from the Flight Data Provider ; and as a result
reference to an a.m. arrival could refer to arrival the current
day or the next day. This ambiguity is largely avoided by the
date rollover procedure.
A date rollover is also declared when an original
arrival time is six hours past the insert update time of the
flight in question. That is, the first time a record is seen
it is "inserted" . The next time that record is seen, it is
regarded as an existing record that has "changed" and the
stored data respecting that record is therefore modified or
"updated".
79
CA 02334177 2001-02-05
At Step 5610 a visual, electronic, and/or audible data
alert notification is output to the customer.
At Step 5611 the destination airport of the flight to
which the reservation relates is compared to the original
destination airport from the Reservation Database flight
information. A divert is declared if both airports do not
match.
At Step 5612 a visual and/or audible notification of the
new destination airport of the flight is output to the cus-
tourer.
At Step 5613 the current reservation list is scanned to
select all those reservations that have the diverted flight
specified as a pickup node place. Each such reservation is
rebooked if the new destination airport is within the operating
range of the original vendor; otherwise the reservation is
canceled.
At Step 5614 the current reservation list is scanned to
select all those reservations that have the deviated flight
associated with a pickup node. The pickup time for each such
reservation is set to the new flight arrival time if it differs
from the originally specified time. At Step 5615 all transpor-
tation assets currently allocated for reservations that have
the affected flight specified as pickup information are
reassigned to the new pickup time.
CA 02334177 2001-02-05
At Step 5616 the process waits a predetermined period of
time as specified by the Reservation Server Complex 1014 before
performing another scan. This sleep time is typically five to
ten minutes and may be varied as needed based upon the Reserva
tion Server Complex workload.
Rebate Program
A rebate program is a process that returns a portion of
the purchase price of a product (i.e. goods and/or services) to
the purchaser thereof, under specified conditions.
In the preferred embodiment the product supplier is a
third party integrator and the purchaser is an integrated
vendor 1006 (Figure 1) . That is, the rebate feature is applied
to the use of a fulfillment system such as the Surface Vehicle
Transportation Reservation System Server Complex 1014 to assist
in the sale of travel-related software and software integration
services by (i) a product supplier such as a third party
software integrator to (ii) a provider of merchandise (i.e.
goods and/or services) such as an integrated surface vehicle
transportation service provider (vendor) 1006, as shown in
Figure 1.
The travel-related software and software integration
services are utilized by the integrated vendor 1006 to more
efficiently automate its operations.
In the preferred embodiment the rebate feature works as
described below.
81
CA 02334177 2001-02-05
An earned rebate value agreed to by the integrator
supplier and each enrolled integrated vendor merchandise
provider, is assigned to each fulfillment-related, i.e.
reservation-related) action performed by the fulfillment system
(the Reservation Server Complex 1014) with the authorization of
the integrated vendor merchandise provider. Such actions
comprise the booking, rebooking and farm-out of reservations.
Thus rebate credit is earned by the integrated vendor each time
a reservation is booked or rebooked with, or farmed-out by that
vendor.
For example, a software integrator product supplier may
sell software and related consultation services to an inte-
grated vendor 1006 at a price of $100,000. The supplier and
the vendor may agree that the vendor can earn a rebate of up to
25% of the purchase price, i.e. $25,000, depending upon the
extent of its participation in the reservation system compris-
ing the Reservation Server Complex 1014. The agreement may
provide that there will be a 0.004%, i.e. $1 rebate for each
reservation that is booked or rebooked with, or made or farmed-
out by that vendor utilizing the reservation system (up to a
maximum of 25% or $25,000), over a three year period. The
product supplier and each participating integrated vendor are
enrolled in the rebate program by the supplier communicating
the rebate information to the Reservation Server Complex 1014.
The integrated vendor initially pays the $100,000 pur-
chase price for the travel-related software and realted
consultation services. At the end of each twelve month period
82
CA 02334177 2001-02-05
thereafter the Reservation Server Complex communicates to the
third party product supplier information as to the accrued
rebate value earned by the integrated vendor, i.e. the number
of reservations booked or rebooked with or farmed-out by that
vendor during the preceding twelve month time period. The
product supplier then rebates a corresponding dollar amount to
the integrated vendor.
This arrangement provides the third party supplier with
an additional sales tool, encourages the integrated vendor to
participate in the reservation system, and helps to generate
business for the reservation system.
As shown in Figure 9, the rebate program is incorporated
in the reservation system in the manner described below.
The product supplier communicates the rebate program
information respecting the participating integrated vendor for
retrieval in Step 6001, so that when retrieved that information
validates the existence of the rebate program as to that vendor
in Step 6002. The integrated vendor is not entitled to a
rebate if the product supplier has not completed the enrollment
process by communicating the rebate details as part of the
rebate program information.
The number of transactions (reservations booked or
rebooked or farmed-out) the enrolled integrated vendor has had
or has made utilizing the Reservation Server Complex 1014 is
retrieved at Step 6003 once a rebate program is determined to
83
CA 02334177 2001-02-05
be in place. The rebate program in place for this specific
vendor is retrieved at Step 6004.
Step 6005 retrieves the rebate details, which comprise:
~ Fixed amount to rebate.
~ Percentage of purchase price to rebate.
~ Maximum rebate amount.
~ Current rebated amount.
~ Percentage of rebated amount to allocate to
purchaser.
~ Percentage of rebated amount to allocate to
merchandise provider.
The total amount to rebate is calculated at Step 6006
using the percentage of purchase price method if the fixed
amount to rebate is zero. If the fixed amount to rebate is
non-zero the total amount to rebate is set to the fixed amount
to rebate.
In Step 6007 the disbursement amount accrued for payment
by the third party product supplier to the enrolled vendor
merchandise (transportation services) provider is calculated by
multiplying the total amount to rebate by the percentage of the
rebated amount to allocate to the vendor; said percentage being
obtained by multiplying the percentage rebate per reservation-
related action by the number of such actions during the accrual
time period.
In Step 6008, the amount allocated to the integrated
vendor is added to the vendor s previously accrued rebate
84
CA 02334177 2001-02-05
amount, and the result is checked to see if it exceeds the
maximum amount to rebate as defined by the rebate plan.
Accounting transactions consisting of the following
items are recorded at Step 6009 and communicated to the product
supplier only if the total accrued rebate amount for the
enrolled integrated vendor is less than the maximum allowed by
the rebate plan:
~ Incremented transaction count for that vendor.
~ Rebate amount accrued during the most recent
accrual period.
~ Amount to be rebated to the enrolled vendor.
~ Date and time.
