CA2334177A1 - Surface vehicle transportation reservation system utilizing airline flight information - Google Patents

Abstract

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 when and where it will pick up and drop off travelers; the number and type of vehicles it has; the percentage of each type which is available for new reservations; and the manner (time and/or distance) in which its base price is to be determined.
Customer desired pickup and drop off 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 single vendor, and whether the desired vehicle is available; and if so, the customer is advised accordingly, a corresponding reservation is booked, and the customer's credit card account is charged. Reservations are scanned to extract those for which corresponding pickup or dropoff times are within a specified number of hours in the future. Where a pickup place is an airport, the extracted reservations are cross-checked against status information respecting corresponding airline flights to determine those reservations for which a corresponding flight arrival time is delayed or advanced, or the flight has been diverted.
Reservation changes are made to reallocate vehicles of the same vendor, or to change the reservation to a different vendor, in accordance with such flight information changes and vehicle availability.

Description

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.

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.

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 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.

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-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.

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 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 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 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;

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.

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 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.

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.

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.

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 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.

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 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).

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).

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.

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-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.

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 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 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 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 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.

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.

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 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;

(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 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 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:

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-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 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 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.

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) 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 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 ~ 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.

~ 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 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:

~ 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.

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.

~ 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 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 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.

~ 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.

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.

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 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 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 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.

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 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 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.

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 ) .

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 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.

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.

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.

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 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.

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.

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.

~ 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 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:

~ 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.

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.

~ 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 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 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 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 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.

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".

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.

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.

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 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 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 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.

Claims (76)

1. A method for providing reservation services to surface vehicle transportation service vendors and entities having a need for surface vehicle transportation services, comprising the steps of:
authenticating a plurality of vendor data streams each received from a data source associated with a vendor of surface vehicle transportation services via a communication medium, each of said vendor data streams comprising information identifying the corresponding vendor and including information as to the availability of transportation assets of said vendor, which availability may vary with time;
authenticating a plurality of customer data streams each received from a data source associated with a customer of surface vehicle transportation services via a communication medium, each of said customer data streams comprising informa-tion identifying the corresponding customer and including information as to a travel itinerary of a traveler associated with said customer, which requirements may vary with time;
processing said vendor data streams and said customer data streams on essentially a real time basis to identify particular ones of said vendors having transportation assets available meeting corresponding transportation service require-ments of said customers, reprocessing said customer data streams in response to changes in the customer requirements contained therein, and reprocessing said vendor data streams in response to changes in the transportation asset availability data contained therein; and upon identification of each particular vendor, communi-cating to said particular vendor information respecting the corresponding travel itinerary, and communicating to the corresponding customer information respecting the corresponding particular vendor.

2. The method according to Claim 1, wherein each of said vendor data streams includes information as to the service locations for which the corresponding vendor provides transpor-tation services, each of said customer data streams includes information as to the itinerary locations for which transporta-tion services are required in connection with a particular travel itinerary, and wherein during said processing step said particular vendors are identified by comparing said itinerary locations with said service locations.

3. The method according to Claim 2, wherein said processing step includes the step of declaring a vendor -customer match when at least two itinerary locations each correspond to a service location of the same vendor.

4. The method according to Claim 2 or 3, wherein said locations are stored and processed as postal zip codes.

5. The method according to Claim 4, wherein when a particular vendor having a transportation asset available meeting a corresponding customer transportation requirement cannot be identified, said processing step is repeated utiliz-ing only a predetermined initial number of digits of each corresponding location zip code.

6 . The method according to Claim 1, 2 or 3, wherein said communicating steps include the step of booking a corresponding surface transportation reservation.

7. The method according to Claim 6, comprising the additional step of, after said booking step, automatically rebooking said corresponding surface transportation reservation in response to a change in the corresponding itinerary, utilizing the changed information as to said itinerary as well as unchanged information respecting said reservation.

8. The method according to Claim 1, 2 or 3, wherein at least some of said itineraries require pickup at corresponding airports, comprising the additional steps of including in said customer data streams information as to scheduled flights and arrival airports;
obtaining and storing current flight Information concerning the status of said flights from a flight information provider;
extracting from said flight information, flight data respecting those particular flights for which corresponding customer pickup or drop-off times are within a predetermined number of hours in the future;
determining from said flight data whether the corre-sponding flights are deviated; and updating the flight information utilizing said flight data to reflect the current anticipated arrival or departure times or the diverted status of the corresponding flights.

9. The method according to Claim 8, comprising the additional steps of communicating to each of said particular vendors any changes in flight arrival and departure times respecting each corresponding travel itinerary, and reallocat-ing corresponding ones of said transportation assets in accordance with such changes.

10. The method according to Claim 6, comprising the additional step of, after a reservation has been booked, communicating to each vendor with whom one or more reservations have been booked, flight information as to said booked reserva-tions.

11. The method according to Claim 10, wherein flight information as to deviated flights is communicated to each affected vendor within a predetermined time interval prior to the scheduled airport pickup time for the corresponding reservation.

12. The method according to Claim 6, wherein at least some of said itineraries require pickup at corresponding airports, comprising the additional steps of including in said customer data streams information as to scheduled flights and arrival airports;
obtaining and storing current flight Information concerning the status of said flights from a flight information provider;

extracting from said flight information, flight data respecting those particular flights for which corresponding customer pickup or drop-off times are within a predetermined number of hours in the future;
determining from said flight data whether the corre-sponding flight departure or arrival times are deviated; and updating the flight information utilizing said flight data to reflect the current anticipated arrival or departure times or the diverted status of the corresponding flights.

13. The method according to Claim 12, comprising the additional step of canceling each surface transportation reservation corresponding to a diverted flight unless the new destination airport is within a region serviced by the same vendor with which the reservation was made.

14. The method according to Claim 6, comprising the additional step of determining the passenger capacity of each transportation asset for which a reservation has been made, and prohibiting the making of a reservation utilizing said asset after its capacity has been reached.

15. The method according to Claim 6, comprising the additional step of prohibiting the making of a reservation for a pickup time less than a predetermined time after the time the reservation is sought to be made.

16. The method according to Claim 6, comprising the additional step of prohibiting the making of a reservation for a pickup time less than a predetermined notice time after the reservation is sought to be made, said notice time being specified by a corresponding vendor.

17. The method according to Claim 6, comprising the additional step of prohibiting the cancellation of a reserva-tion less than a predetermined time prior to the scheduled pickup time.

18. The method according to Claim 6, comprising the additional step of prohibiting the cancellation of a reserva-tion less than a predetermined notice time prior to the scheduled pickup time, said notice time being specified by a corresponding vendor.

19. The method according to Claim 6, comprising the additional step of, in response to an instruction from a customer, booking a return surface transportation reservation utilizing the original reservation information and return pickup information.

20. The method according to Claim 6, comprising the additional steps of booking a return surface transportation reservation, linking the same to said corresponding surface transportation reservation, and canceling said return reserva-tion when the original reservation is canceled.

21. The method according to Claim 6, comprising the additional step of grouping multiple surface transportation reservations for group travel, and booking the same as a group.

22. The method according to Claim 21, comprising the additional step of booking multiple transportation assets sufficient to accommodate a corresponding group.

23. The method according to Claim 6, wherein said assets are booked with more than one vendor.

24. The method according to Claim 6, comprising the additional step of grouping multiple surface transportation reservations for travel by a group of unassociated travelers, and booking the same as a group.

25. The method according to Claim 6, comprising the additional step of storing an open list for customers when no transportation is currently available in accordance with the corresponding itineraries.

26. The method according to Claim 1, 2 or 3, comprising the additional step of storing billing information as to customer in the form of a customer profile.

27. The method according to Claim 1, 2 or 3, comprising the additional step of computing a basic price charge for at least some of said vendors, by applying a charge per unit time specified by each such vendor to the difference between the pickup and dropoff times for each corresponding transportation lane.

28. The method according to Claim 1, 2 or 3, comprising the additional step of computing a basic price charge for at least some of said vendors, by applying a charge per unit distance specified by each such vendor to the distance between the pickup and dropoff places for each corresponding transpor-tation lane.

29. The method according to Claim 1, 2 or 3, wherein a surface transportation trip comprises travel via a transporta-tion asset corresponding to one or more lanes, each lane extending between two nodes, comprising the additional steps of storing in a vendor pricing table information as to the basic price per unit distance charged by at least some of said vendors for travel between various nodes serviced by each vendor, determining a standard distance between the nodes associated with said lane, multiplying the basic price by the standard distance to determine the basic price for said lane of travel, and adding the basic prices for the lanes of the trip to determine a basic price for the trip.

30. The method according to Claim 29, wherein said standard distance is determined by reference to the postal zip codes associated with the physical location of said nodes.

31. The method according to Claim 30, wherein said zip codes are determined by reference to a table based on the name of a location associated with each corresponding node.

32. The method according to Claim 30, comprising the additional step of adding incidental charges to the basic price for a trip to determine a total price for the trip.

33. The method according to Claim 31, comprising the additional steps of submitting said total price to a credit account processor for approval and, after receipt of such approval, charging a credit account of the corresponding customer for said total price.

34. The method according to Claim 31, comprising the additional step of calculating a commission for an entity which has booked a reservation for a trip, a commission based on a predetermined percentage of predetermined elements of the price of the trip.

35. 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 providing traveler pickup and dropoff service at a plurality of nodes within a service region, each node having a physical location associated therewith, comprising the steps of:
obtaining from each vendor service information identify-ing the nodes serviced by that vendor and price information providing a basis for determining the vendor's basic price for transportation of a traveler between selected pairs of those nodes;
obtaining from each vendor time-dependent asset informa-tion as to available transportation assets for each node;
obtaining from a customer travel information as to the pickup and dropoff places associated with a particular surface trip to be taken by a traveler associated with the customer;
determining from said travel information the required pickup and dropoff nodes;
comparing the required pickup and dropoff nodes to the nodes serviced by the vendors to identify the particular vendors which have transportation assets available to service the required nodes;
upon identification of at least one such particular vendor, advising the customer of the availability of surface transportation between said pickup and dropoff nodes and soliciting authorization to book a corresponding reservation;
and upon receipt from the customer of authorization to make the reservation, booking a reservation for the trip with the particular vendor and communicating a confirmation of the booking to the customer.

36. The method according to Claim 35, comprising the additional steps of:
determining from said price information and pickup and dropoff nodes a basic price for the corresponding lane of each trip;
increasing said basic price to reflect any additional vendor charges associated with the trip;
communicating the total vendor price for the trip to the customer which reserved the same;
submitting said total vendor price and any reservation system service charges to a credit account processor to obtain authorization to charge a credit account of said customer for the trip; and upon receipt of bookout information from said particular vendor verifying fulfillment of the reservation for said trip, charging the credit account of the customer for the trip and crediting an account of the vendor for the total vendor price less any reservation system service charges.

37. The method according to Claim 35, comprising the additional step of soliciting from said customer a return reservation wherein a dropoff node of each lane of the original trip is a pickup node of the corresponding lane of the return trip and a pickup node of said lane is a dropoff node of the corresponding return trip lane, and upon receipt of said authorization booking the return reservation utilizing vendor information respecting each corresponding original trip lane.

38. The method according to Claim 35, wherein the asset information for each vendor comprises information as to the number and type of vehicles of that vendor and the percentage of each type which is available.

39. The method according to Claim 35, 36, 37 or 38, wherein said comparing step comprises the step of determining the postal zip codes corresponding to the physical locations of all of said nodes and comparing the zip codes associated with the required pickup and dropoff nodes to the zip codes associ-ated with the nodes serviced by the vendors.

40. The method according to Claim 39, wherein said comparing step includes the step of, when a match of the zip codes associated with the required pickup and dropoff nodes to the zip codes associated with the nodes serviced by the vendors is not found, expanding the region encompassed by the zip codes associated with the nodes serviced by the vendors, by utilizing only a first predetermined number of digits of the vendor zip codes, and repeating the comparing step utilizing said expanded region zip codes.

41. The method according to Claim 36, wherein said price determining step comprises the steps of determining the postal zip codes associated with the physical locations of the pickup and dropoff nodes of each such corresponding trip lane, determining from said zip codes a standard distance between the corresponding physical locations, and multiplying the standard distance so determined by a charge per unit distance specified by the corresponding vendor.

42. The method according to any one of Claims 35 through 38 and 41, comprising the additional step of, after said booking step, automatically rebooking said reservation with said particular vendor in response to a change in the corre-sponding itinerary, utilizing the changed information as to said itinerary as well as unchanged information respecting the booked reservation.

43. The method according to Claim 42, wherein a pickup node associated with said particular trip has a physical location at an airport, and said rebooking step includes the steps of obtaining from an airline flight information provider the arrival time of a corresponding flight, and declaring a change in the corresponding itinerary when the flight is deviated.

44. The method according to Claim 43, wherein said rebooking step includes the steps of, in response to the declaration of a change in the corresponding itinerary:
determining an altered pickup node based on the arrival time and place specified by said flight information provider;

modifying said reservation to conform with said altered pickup node and said dropoff node if said particular vendor has a transportation asset available therefor; and canceling the reservation and booking a reservation with an alternate vendor having an available transportation asset for said altered pickup node and said dropoff node, if said particular vendor does not have a transportation asset avail-able therefor.

45. The method according to Claim 44, comprising the additional step of modifying the dropoff node corresponding to said altered pickup node in response to a customer instruction.

46. The method according to any one of Claims 35 through 38 and 41, comprising the additional step of, for each reserva-tion which includes an airport pickup, communicating to each affected vendor flight arrival information as to those pickups with respect to which corresponding flights have been deviated.

47. The method according to Claim 46, wherein the step of communicating to each affected vendor comprises the steps of:
obtaining from an airline flight information provider the arrival time of a corresponding flight;
declaring a change in the corresponding itinerary when the flight is deviated;
determining an altered pickup node based on the arrival time and place specified by said flight information provider;

modifying said reservation to conform with said altered pickup node and said dropoff node if said particular vendor has a transportation asset available therefor; and canceling the reservation and booking a reservation with an alternate vendor having an available transportation asset for said altered pickup node and said dropoff node, if said particular vendor does not have a transportation asset avail-able therefor.

48. The method according to any one of Claims 35 through 38 and 41, comprising the additional step of prohibiting the making of a reservation for a pickup time less than a predeter-mined time after the time the reservation is sought to be made.

49. The method according to Claim 48, comprising the additional step of prohibiting the making of a reservation for a pickup time less than a predetermined notice time after the reservation is sought to be made, said notice time being specified by a corresponding vendor.

50. The method according to Claim 49, comprising the additional step of prohibiting the cancellation of a reserva-tion less than a predetermined notice time prior to the scheduled pickup time.

51. The method according to Claim 50, wherein said notice time is specified by a corresponding vendor.

52. The method according to any one of Claims 35 through 38 and 41, comprising the additional step of, in response to an instruction from a customer, booking a return surface transpor-tation reservation utilizing the original reservation informa-tion and return pickup information.

53. The method according to Claim 35, 36, 37 or 38, wherein when said price information includes a zero price for a particular node, that particular node is excluded from the nodes serviced by that vendor.

54. The method according to Claim 1, 2, or 3, wherein at least some of said customer data streams includes information as to the surface transportation vehicle service requirements of said traveler.

55. The method according to Claim 54, wherein said surface transportation vehicle service requirements comprise information as to the type of vehicle and any amenities desired.

56. A method for providing reservation services to surface vehicle transportation service vendors and entities having a need for surface vehicle transportation services, comprising the steps of:
accepting a plurality of vendor data streams each received from a data source associated with a vendor of surface vehicle transportation services via a communication medium, each of said vendor data streams comprising information identifying the corresponding vendor;
accepting a plurality of customer data streams each received from a data source associated with a customer of surface vehicle transportation services via a communication medium, each of said customer data streams comprising a travel itinerary;
processing said vendor data streams and said customer data streams to identify particular ones of said vendors having transportation assets available meeting the surface transporta-tion requirements of said itinerary, by matching the places serviced by each of said vendors with the places between which surface transportation is required according to said travel itinerary; and upon identification of each particular vendor, communi-Gating to said particular vendor information respecting the corresponding travel itinerary, and communicating to the corresponding customer information respecting the corresponding particular vendor.

57. The method according to Claim 56, wherein said vendor data stream includes price information applicable to said itinerary, comprising the additional step of determining from said price information a basic price for surface transpor-tation between said places.

58. A method for providing surface transportation reservation services utilizing transportation assets comprising vehicles provided and operated by various vendors, each vendor providing traveler pickup and dropoff service at a plurality of nodes within a service region, each node having a physical location associated therewith, comprising the steps of:
obtaining from each vendor service information identify-ing the nodes serviced by that vendor and price information providing a basis for determining the vendor's basic price for transportation of a traveler between selected pairs of those nodes;
obtaining from a customer travel information as to the pickup and dropoff places associated with a particular surface trip to be taken by a traveler associated with the customer;
determining from said travel information the required pickup and dropoff nodes;
comparing the required pickup and dropoff nodes to the nodes serviced by the vendors to identify the particular vendors which have transportation assets available to service the required nodes;
upon identification of at least one such particular vendor, advising the customer of the availability of surface transportation between said pickup and dropoff nodes; and booking a reservation for the trip with the particular vendor and communicating a confirmation of the booking to the customer.

59. The method according to Claim 1, 2 or 3, wherein a surface transportation trip comprises travel via a transporta-tion asset corresponding to one or more lanes, each lane extending between two nodes, comprising the additional steps of storing in a vendor pricing table information as to the basic price per unit time charged by at least some of said vendors for travel between various nodes serviced by each vendor, determining a standard time for travel between the nodes associated with said lane, multiplying the basic price by the standard time to determine the basic price for said lane of travel, and adding the basic prices for the lanes of the trip to determine a basic price for the trip.

60. The method according to Claim 1, 2 or 3, wherein a surface transportation trip comprises travel via a transporta-tion asset corresponding to one or more lanes, each lane extending between two nodes, comprising the additional steps of storing in a vendor pricing table information as to the basic price charged by at least some of said vendors for travel between various nodes serviced by each vendor, and adding the basic prices for the lanes of the trip to determine a basic price for the trip.

61. A method for providing surface vehicle transporta-tion reservation services to customers for trips utilizing airlines, comprising the steps of:
storing customer reservation information comprising flight information and airport pickup times respecting the transportation needs of customers from airports, in a reserva-tion memory;
obtaining current flight information concerning the status of airline flights from a flight information source;
storing said current flight information;
extracting from the stored reservation information, flight information respecting those particular reservations for which corresponding customer pickup times are within a prede-termined number of hours in the future;

cross-checking said extracted flight information against the stored current flight information to determine whether any of the corresponding flights are deviated flights; and updating said reservation memory to reflect the current anticipated arrival times and places of any such deviated flights.

62. The system according to Claim 61, comprising the additional steps of displaying any changes in flight arrival times and places for said particular reservations and changing said particular reservations in accordance with such flight arrival time changes.

63. The system according to Claim 61 or 62, comprising the additional step of canceling reservations corresponding to diverted flights unless the new destination airport is within a predetermined distance from the original destination airport.

64. A method for facilitating surface vehicle transpor-tation of travelers from airports for trips utilizing airlines, comprising the steps of:
storing travel information records including flight information and airport pickup times in a reservation memory;
obtaining current flight Information concerning the status of airline flights from a flight information source;
extracting selected ones of said records from the stored reservation information;
comparing the flight information in the selected records with the current flight information to determine whether any of the corresponding flights are deviated flights; and updating said reservation memory to reflect the current anticipated arrival times and places of any such deviated flights.

65. The system according to Claim 64, comprising the additional step of changing those of said selected records for which corresponding flights are deviated flights, to reflect any changes in the anticipated arrival times and places of said deviated flights.

66. The system according to Claim 64 or 65, comprising the additional step of modifying those of said selected records for which corresponding flights are diverted flights, to cancel reservations corresponding to diverted flights unless the new destination airport is within a predetermined distance from the original destination airport.

67. A transportation reservation system for surface vehicles which utilizes airline flight information, comprising:
a reservation memory for storing customer reservation information comprising scheduled flight information and airport pickup or drop-off times respecting the transportation needs of customers to and from airports;
transportation reservation storage means for storing said reservation information in said reservation memory;
flight information access means for obtaining current flight information concerning the status of scheduled airline flights from the Internet or a third party provider;
flight information storage means coupled to said access means for storing said current flight information;

extraction means for scanning said reservation memory to extract reservation information comprising scheduled flight information respecting those particular reservations for which corresponding customer pickup or drop-off times are within a predetermined number of hours in the future;
cross-checking means coupled to said extraction means and responsive to the scheduled flight information respecting said particular reservations for cross-checking said scheduled flight information against current flight information stored in said flight information storage means respecting corresponding flights, to determine whether the corresponding flight depar-ture or arrival times are deviated; and delay-diversion processing means coupled to said cross-checking means for updating said reservation memory to reflect the current anticipated arrival or departure times or the diverted status of said corresponding flights.

68. The system according to Claim 67, wherein said delay-diversion processing means includes means for displaying any changes in flight arrival and departure times for said particular reservations and for reallocating corresponding ones of said vehicles in accordance with such changes.

69. The system according to Claim 67 or 68, wherein for diverted arrivals, said delay-diversion processing means includes means for canceling reservations corresponding to diverted flights unless the new destination airport is within a predetermined transportation service range.

70. A method of selling a product by issuing rebates on the price of said product with the assistance of a fulfillment system, said product emanating from a product supplier, said fulfillment system utilizing merchandise furnished by merchan-dise providers, comprising the steps of:
enrolling said product supplier and those of said merchandise providers who elect to purchase said product and receive rebates thereon, using enrollment software associated with said fulfillment system;
assigning an earned rebate value agreed to by the supplier and each enrolled merchandise provider, to each fulfillment-related action performed by the fulfillment system with the authorization of the merchandise provider; and communicating to the supplier the accrued rebate value earned by each enrolled merchandise provider.

71. The method according to Claim 70, wherein said product is a software product and said merchandise comprises transportation services furnished by transportation service providers.

72. The method according to Claim 71, wherein said fulfillment system is a surface vehicle transportation reserva-tion system utilizing transportation assets, each such asset comprising a vehicle and a driver therefor, and said software product comprises travel-related software and software integra-tion services.

73. The method according to Claim 70, 71, or 72, wherein said fulfillment-related actions comprise the booking, rebooking and farm-out of reservations.

74. A method of selling a software product by issuing rebates on the price of said product with the assistance of a reservation system, said product emanating from a software product supplier, said system utilizing transportation services furnished by transportation service providers, comprising the steps of:
enrolling said software product supplier and those of said transportation service providers who elect to purchase said software product and receive rebates thereon, using enrollment software associated with said reservation system;
assigning an earned rebate value agreed to by the supplier and each enrolled transportation service provider, to each reservation-related action performed by the reservation system with the authorization of the service provider; and communicating to the supplier the accrued rebate value earned by each enrolled transportation service provider.

75. The method according to Claim 74, wherein said reservation system is a surface vehicle transportation reservation system utilizing transportation assets, each such asset comprising a vehicle and a driver therefor, and said software product comprises travel-related software and software integration services.

76. The method according to Claim 74 or 75, wherein said reservation-related actions comprise the booking, rebooking and farm-out of reservations.