CA2243831A1 - Automated travel service management information system - Google Patents

Abstract

A method (1000) of automatically managing travel service information is provided. The method generates a business entity profile and individual profile for customer (1004, 1006), and stores the information in a relational database. Customer reservation services information retrieved from all available sources is also stored in the same database (1010). Consequently, the customer reservation services information and the profile information is made available, simultaneously, for use by an agent in processing a customer's travel request (1013).

Description

AUTOMATED TRAVEL SERVICE
MANA~ N~ ATION SYSTEM

H~Ir~T~ FTr~r~n OF T~ l~v~ ON
This invention relates ~el~e~lly to the field of customer reservation services, and more particularly, to an automated travel service manay - L in~ormation system and method of oper~tion.

SU~a 111 ~JTE SHEET (RULE 26) RACKG~OUND OF T~ 1 N V ~ ON
Travel agencies train and employ agents to coordi~ate customers' travel p}ans with travel-related services supplied by airlines, hotels, auto rental agencies, etc. Typically, in order to determine the availability of these services and make reservations, travel agents may access (via a remote workstation) one o~ a number of proprietary travel reservation systems.
For example, in order to determine the availability of seating on a specific airline flight, an agent may access the SABRE System, which is a ~_ ~ Ler reservation system (CRS) developed and marketed by American Airlines. Other c~ uLer reservation systems are also available, such as Worldspan0 owned by Pars Marketing Partnership, Apollo~
owned by Galileo International Partnership, and System One~ owned by Amadeus Global Travel Distribution.
Although a .. h~r of ~ ietary computer reservation systems are available, from a travel agency's viewpoint, these systems are inefficient and not cost effective to use. For example, work-related travel arrangements may be (and usually are) subject to certain restrictions ; -~-d by a customer's employer. Employers often limit airline travel ~pen~;tures to tourist class or business class rates. Also, employers often negotiate discounted rates for their employees, such as hotel or automobile rental rates, and then limit travel expenditures to those discounted rates. Although existing proprietary ~ ~Ler reservation systems may m~intain such employer-i -se~ restriction information, in order to obtain that type of information from a particular system, an agent needs to know that system's unique information codes. ~owever, most agents are typically trained to access and use only one or two proprietary computer reservation systems, because cross-training agents to use all of the unique systems would beexL~ ?ly costly for the agency.

SUBSTITUTE SHEET (RULE 26) WO 97~275~6 PCT/US97/00765 Furthel~J,e, although a nl h~r of proprietary c- ~ Ler re~ervation systems are available for use by agencies, these systems are not integrated to provide all o~ the available services at one time. Consequently, if an agent desires ~o make a complete set of travel arrangements for a customer, the agent has to access a system multiple times. For example, in order to arrange for a customer's airline travel, automobile rental, and hl~tel accommodations, a travel agent typically acc~s~s the proprietary system to reserve airline seating and o]btain prices and tickets, then again using different ~ -n~ to obtain prices and reserve a rental car, and a third time to o~tain prices and reserve a hotel room.
Since an agent's productivity decreases with increases in rQquest ~,o~cssing time, the present sequential method o~
processing travel requests is highly inefficient. Such inefficiencies result in increased operational costs and reduced profitability for the agency. Additionally, the agent cross-tr~ini ng required for three proprietary systems, significantly increases the agency's costs.
Presently, in order to minimise operational costs, travel agencies typically assign ~p~-; fic agents to process travel requests made by specific customers and business organizations, and for specific travel-related functions. However, these specialized uses of agents are neither very efficient nor cost-effective. For example, one agentls ~o~ ate customer may request travel arran~ s for several employees, while at the same t:Lme, one or more of the other agents in the office may ~e idle.

5~ TE SHEET(RULE26) SUMMA~Y OF TH~ T~v~ ON
Accordingly, a need has arisen for an automated travel management information system which incorporates all available customer reservation service information into one database, including customer preference information.
In accordance with a preferred embodiment of the present invention, a method of operating an automated travel service management information sy~tem i5 provided which maintains a business entity profile and/or an individual profile for each agency customer, in a relational dat~hA~e. The system also maintains information retrieved from a plurality of ~Ler reservation systems, in the relational database. In response to a customer's travel request, the system automatically retrieves, and displays for decision-making by an agent, al~ pertinent information retrieved from the customer's business entity profile and/or individual profile, and the a~o~iate _ Ler reservation system(s).
An important te~h~ical advantage of the present invention is that travel service information from a plurality of ~G~yuLer reservation systems is stored and readily available in a single database format.
Conseguently, travel agents do not re~uire cross-training to use a plurality of c ~Ler reservation systems, and their pro~uctivity can be increased.
Another important technical advantage of the present invention is that customer preference information is also stored and readily available in a dat~h~e.
Consequently, an agent can take the customer preferences ~e.g., restrictions) into a~unL while making travel arrangements.

SU~I~l~TE SHEET (RULE 26 W O 97~7556 PCTrUS97/00765 ~T~F n~.~CRTPTTON OF T~ n~AWTNGS
For a better understAn~l~ n~J of the present invention, re~erence may be made to the a~ ,~nying drawings, in which:
FIGURE 1 is a top level block diasram which illustrates an envi~cs - L in which an auto~ated travel manay~ - L information system can operate, in accordance with a preferred ~_a; -nt of the ~ -nt invention;
FIGURE 2 is a simplif~ed diagram of a computer-~ased system that can be used to implement the automated travel management information system shown in FIGURE 1;
FIGURE 3 is a simplified top level block diagram which illustrates a plurality of ~nl-Al and automated functions that can be performed at the travel agency lS S]lOWn in FIGURE 1, in accordance with the preferred hoA im-~rtt Of the present invention;
FIGURES 4-16 are exemplary flowcharts of software routines for the business entity reservations function or component shown in FIGURE 3;
FIGURES 17-lg are exemplary flowcharts of software routines for the global distribution function or : ~nt shown in FIGURE 3;
FIGURES 20-21 are exemplary flowcharts of software routines for the special services function or ~ nent shown in FIGURE 3; and FIGURE 22 is a flow diagram that illustrates a method of operating an automated travel management information system, in accordance with a preferred e~bo~; -nt of the present invention.
;

SUBSTITUTE SHEET (RULE 26~

W O 97/27556 PCTrUS97/00765 DFTA~T.~n ~rRTp~IoN OF T~ TN~n~NTTON
The preferred ~ nt of the present invention and its advantages are best understood by referring to FIGURES 1-22 of the drawings, like numerals being used for like and co.~ .o~l;n~ parts of the various drawin~s.
FIGURE 1 is a top level block diagram that illustrates an envi.~ -nt in which an automated travel management information system can function and operate, in accordance with a preferred iment of the present invention. Referring to FIGURE 1, an automated travel management information system ~hereinafter, referred to as the ~system~) 10 is shown. System 10 is preferably used to provide customer travel services, by one or more travel agents employed ~y agency 12.
A plurality of _ ~Ler reservation systems 14 can be l; n~e~ electronically with agency 12 via a Z ~ n i cations ~.oc D -~or 15. In the preferred embodiment,.the - ications processor 15 is preferably a - ications proce~or and file server data storaqe interface referred to herein as a travel information analysis ~TIA) subsystem. As described above, each _ ~Ler reservation system 14 may be one or more -c ?rcially available c~Ler reservation systems, such as, for example, the SABRE, Worldspan~, Apollo0, or System one~ systems. C uLer reservation systems 14 provide travel service inventory information, such as airline ~light, rail, hotel, limousine, and rental automobile availability and rates. TIA subsystem 15 functions as a z- lnications interface and temporary data storage medium, between each of computer reservation systems 14 and system 10. Preferably, the inventory information provided by computer reservation systems 14 is ultimately received for processin~ by system 10.
Generally, system 10 preferably functions to centralize the travel service information received from each of -__ uLer reservation Systems 14. Consequently, SUBSTITUTE SHEET (RULE 26~

WO 97127~6 PCT/US97/~0765 althouc3h each computer reservation system formats its travel service information and c ~n~ structures dl~ferently, system 10 functions to integrate the dLfferent information and commands into one format for S u~e by all travel agents.
One or more travel agency customers 16 can c~ icate with one or more travel agents via any one of a ~,~ h~ of - i cations subsystems 17. Each c ications subsystem 17 preferably fUnctions to provide two-way communications between a customer and an agent. For example, one such communications subsystem may be a telephone system, a second such subsystem may be a facsimile machine, and a third such subsystem may be a ~uLer-driven system providing E-mail c~ ications.
Travel service rec~est information from a customer is preferably input as data to system 10, by an agent.
In the preferred : ho~i ?nt, system 10 includes a relational da~h~c~, which resides in a data storage medium (to be described in detail below). A business entity profile data structures 18 and/or an individual entity profile d~ta stru~Lule~ 20 is included in the relational dat~h~s~ in system 10, for each individual and business travel customer of the agency. Each such profile preferably contains, at a ini , that cu~stomer's respective personal and travel preference ineormation. For example, a customer's business entity profile 18 can contain that ~usiness' name and address, the travel coordinator's name, travel ~Yr~n~ iture restrictions, vendor preferences, and neqotiated discount ra~e information. An individual entity profile 20 preferably contains, at a minimum, an individual customer's personal information and travel preferences, suc:h as, for example, the customer's name and address, employer, seating preference, -~in~ or non-smoking preference, a list of preferred vendors (e.g., airlines), etc:.

S~ TE SHEET(RULE26) _ W O 97127556 PCTrUS97/00765 System 10 maintains the business and individual entity profile information, along with all available customer reservation information, in the relational database. System 10 pro~ce~C this information and, where n~c~ ~y, converts the information to a st~n~dized format. Conse~uently, via system 10, a customer~s pro~ile and the customer reservation in~ormation are made available to an agent, all at the sam~ time the travel arrangements are being ~ade.
C~nc~uently, the agent's productivity is increased, because the agent is not required to ~c~e~~ more than one cc,~uLer reservation system. Additionally, when ;~k; ng the travel arrangements, the agent can take the customer's preferences into a~c~u~ which is beneficial for the customer, the agency, and their relationship.
FIGURE 2 is a simplified diagram of an exemplary computer-based system 21 that can ~e used to implement the automated travel management information system shown in FIGURE 1. Referring to the : ho~i - L shown in FIGURE

2, the computer-based system 21 can include a process server 22, a data storage device 24, a mainframe computer 26, a local file server 28, and a plurality of workstations or desktop c_ -Lers 30.
Process server 22 preferably functions to process travel-related data and _ ~n~ information. A Sun Solaris 2.3 system has ~een s~ es~fully utilized as ~ocess server 22. Data storage device 24 c~n ~e a mass storage subsystèm of tapes and/or disk drives, which is electrically coupled to process server 22. In the preferred hoA; -nt, a relational datAb~ resides in data storage device 24. Conseguently, ~lo~SS server 22 may retrieve, process and store the information in the relational dat~h~se residing in data storage device 24.
The mainframe computer 26 may be link~
electronically to process server 24 through a local or wide area network (LAN/WAN), for automated uploading and S~J~S 111 ~ITE SHEET (RULE 26) WO 97127556 PCT~US97/0076 downloading of information therebetween. Any general purpose or medium sized ~Ler, which includes a central ~L~c~ssing unit (C~U) and suitable RAM, ROM and I/O circuitry, can be utilized for r-i nframe 26.
Local ~ile server 28 may be 1; nk~ electronically to proce~s server 22 by the same or a different local or wide area netwdrk, or by telecommunication lines through a modem ~not explicitly shown). Additionally, as shown (for illustrative purposes only) in FIGURE 2, process server 22 can be linke-1 by a "gateway" interface c~ ~ications proc~csor to local file server 28. Local file server 28 is preferably ~nnn~cted to a plurality of workstations or desktop - uLers 30. A user o~ system lO, such as a travel agent or a system user, may input and receive travel- and customer-related information, and system information, respectively, through any o~ the workstations 30. Pre~erably, each ~oLh~Lation 30 is a desktop _ uLer having at least a 486 processor or an operational equivalent. Systems ~L ~ ~mming for the automated travel services mana~. ~ L information system may be performed using a high level ~lG~L, ing language, such as C~.
The business entity profile information (18) and individual profile information (20), for each of the agency's customers, is preferably stored in the relational dat~hA~e residing in data storage device 24.
Process server 22, -inframe computer 26, local file server 28, and workstations 30 are prefera~ly li n~
together. Consequently, each of these devices can directly access (e.g., store and retrieve) the ~usine~s and individual profile information, if nec~ss~y.
Computer-~ased system 21 is el~_L~o,~ 1y 1 in~ to th~ co~u~er reservation systems 14 preferably via TIA
subsystem lS (FIGURE 1). Conse~uently, system 10 can receive, store (e.g., in the relat;on~l dat~h~c~), process, and display (e.g., via workstation 30) all SIJ~S 111 ~TE SHEET (RULE 26) W 097/27556 PCTrUS97/00765 .

available customer reservation service information. In another aspect of the invention, computer-ba5ed system Zl can also be linked electronically to each of customers 16 via a respective digital c~ -ications link (17) so that each customer's travel request can be proc~ss~
automatically by system 10, as ~ to having the customer interact with system 10 th~ough an agent.
FIGURE 3 is a simplified top level block diagram which illustrates a plurality of manual and automated ~unctions that can be performed at the travel agency shown in FIGURE 1, in accordance with the preferred embodiment of the present invention. Referring to FIGURE

3, the functions described with respect to FIGURE 1 can be separated into a plurality of manual, software, and hardware _ ,_r,ents: an A~' jni~tration component 32, a management c~ t 34, a vendor relations component 36, an airline r~ Ling _ -ny (ARC) processing component 38, an implementation _ _ -nt 40, a management information system (MIS) _ ,_ ~nt 42, a t~chnology support __ ~nt 44, a busines~ entity reservations component 46, a global distribution component 48, and a special services _ ,-nent 50.
In the preferred ~ of the present invention, system 10 functions primarily to process software functions associated with the business entity reservations -_ pollent 46, global distribution co~onent 48, and special services c - - t 50. The a' i n ictration component 32, management component 34, vendor re}ations component 36, ARC processing component 38, implementation component 40, MIS component 42, and technology support ~ nent 44 are primarily manual or software-assisted functions, or functions performed by ~chAn;cal or electronic systems other th~n by ~ystem 10.
These other systems are described herein to illustrate an agency's operational enviL~ -nt and provide a c~ear understA~in~ of the present invention.

S~J~S 111 UTE SHEET (RULE 26) W 09712~556 ~cTn~ss7~ao76s Specifically, the Al' i ni ~tration component 32 includes such functions as secretarial support, local 3rea network (LAN) ~; ni ~tration, telephone support, managing the ~acilities of travel agency 12, and purchasing a~Lu~Liate supplies for the agency.
The management _ - ~nt 34 includes such functions as managing the agency's fin~n~ec, providing a budget, and managing the agency's human resou~es.
The vendor relations component 36 includes s~ch functions as developing relationchips with various travel services vendors, such as airlines and hotels. Vendor relations component 36 also includes the function of managing vendor agreements, such as negotiating a~reements and ensuring that the agreements are enforced.
The ARC processing ~ on~nt 38 includes the function of interfacing between the agency and airline reporting companies. These ARCs oversee such functions as airline payments of agency ~ ions, and collections of fees from the agencies on ~hAlf of airlines.
The implementation component 40 includes such functions as managing and coordinating the inclusion of e~cisting and new customers into a reser~ation center database, such as, for example, the Global Travel Services Center (GTSC) dat~h~e. Travel agencies can contract out ceFtai~ tasks to a reservation center, rather than perfo. ; ng the task in-house.
The MIS c- ~ ent 42 includes such functions as maintaining a management information system, which, for e~cample, can generate a ~G~ L on the amounts each customer has spent on travel services during a predetermined period of time.
The tP~hnology ~U~OL L component 44 includes such functions as working directly with customers to develop and understand new t~hnologies.

S~ ~S 111 ulTE SHEET (RULE 26) W O 97127556 PCTnUS97/00765 System 10 proc~s~s the software routines of the business entity reservations l_ ~ n~nt 46, global distribution ç~ -nent 48, and special services component 50. These components are preferably implemented as computer-driven software routines that assist an agent in g decisions on travel arra~-~ nts, in response to a customer's request.
Generally, in accordance with the .~- ho~; ~nt shown in FIGURE 3, the busine~5 entity reservations component 46 preferably includes a plurality of 511~- , onents or software subroutines, such as a domestic reservations ,: ~nt 56, an international reservations component 58, and a ~u~p~L ~ _.ent 60.
The domestic and international reservations components (56 and 58) include such functions as arranging travel reservations in r~,~~ ~e to a customer's request, changing the reservations in ~e~G..se to the customer's request, and c~n~el; ng the reservations, if an agent is requested to do so.
~he ~o~L ,~ nt 60 includes such functions as performing quality assurance (QA) for travel services, updating customer information in the business entity and individual profiles, and providing the services of an in-house service representative.
The global distribution component 48 manages a subsystem, which an agency can use to distribute travel-related documents, such as airline tickets and written hotel reservations. The global distribution component 48 preferably includes a ticketing cv ~o..ent 62 and a packaging/delivery _ ~n2nt 64. The ticketing component 62 functions to cause a ticket to be printed for travel services, on a~lv~ iate paper stock. The packaging/delivery c _nent 64 includes the ~ntl~l functions of packaging the tickets and delivering them to customers. The global distribution : ol.ent 48 also SIJ~ 111 UTE SHEET (RULE 26) , W O 97127556 PCTnUSg7~0076~

functions to oversee the disposition of tickets that have been reL~l.,ed by customers.
The special services ~G~l.~nt 50 pre~erably includes a customer service - -nt 66, a group &
meetings component 68, an international rate desk (IRD) - ~~ ~~t 70, a travel-24 r~ -nt 72, and a VIP
= ~ ..cnt 74. ~he customer serv~ce _ nt 66 functions to guestion agency cust~ ~ ~ as to their satisfaction with the agencies' services. The group and m~eetings ~ .ent 68 includes the function of arranging meeting and ~.-- ~ntation facilities for customers on travel. The IRD ~ - ~nt 70 functions to determine and verify rates for travel services in other ~o~--L ies. The travel-24 ~_- onent 72 functions to provide the agency's lS customers with twenty-four hour travel ~ervices, such as making and c~n~el in~ reservations after normal business hours.
FIGURES 4-16 are exemplary flowcharts of so~tware-driven functions that can be performed for a travel agency, in con~unction with an agent, by the business entity reservations - ron~nt 46 shown in FIGURE 3.
Specifically, FIGURES 4-11 il~ustrate exemplary methods that can be per~ormed by the ~ - Lic reservations cl onent 56. FIGURES 12-16 illustrate exemplary methods that can be performed by the au~OlL ~ nt 60.
FIGURE 4 i5 an exemplary flowchart for the domestic reservations software-assisted routine 56, which is shown in FIGURE 3. The domestic reservations routine preferably makes travel services originating in, or lacated exclusively within, the national boundaries of the ~,.L,~ in which the agency i~ located.
Referring to FIGURE 4, system 10 initiates the domestic reservations routine 56 at block 78. At block 80, a travel re~uest from a customer is received (via a _~ ~ni cations subsystem 17 in FIGURE 1) by an agency, and, under the control of a receive/route request S~Jd~ TE SHEET (RULE 26) so~tware-assisted routine 80 (described in detail below with respect to FIGURE 5), system 10 routes the travel request to an agent for processing. At block 82, the agent begins processing the request with the assistance of system 10. Preferably, an agent ~-. icates with system 10 via a workstation 30. For example, an agent can input system ,_ ~n~c and travel information by pressing a~p iate keys ~typing) on a workstation keyboard, or ~clicking~ on an option in a Windows-type display. In return, the workstation can display travel information, which is provided by system 10 for use by the agent in ~king travel arrangements.
Specifically, under the ~Ol~r ol of a travel request processing software-assisted routine 82 (described in detail below with respect to FIGU~E 6), system la displays ~or the agent (prefera~ly via a workstation 30) the requesting customer's business and/or individual profile information, along with all customer reservation service information the agent may need to complete the desired travel arrangements. Subse~uently, after completing the travel arra~ - Ls (typically with the customer's con~ e"ce), the a~ent inputs a~Lo~iate co ~n~ via the workstation, and system 10 stores the travel arrangement information in the relational database in storage device 24. The agent then terminates r _ n i cations with the customer.
At block 84, system 10 initiates a software-assisted routine 84 (described in detail below with respect to FIGURE 10) that prompts an agent (preferably via a display on workstation 30) to perform certain follow-up tasks related to the initially co~pleted travel arrangements. At block 86, system 10 determines whether or not the completion of the customer's initial travel arrangements should re~uire the assistance or services of a travel services vendor (e.g., airline, etc.). For example, in order to save time, an agent may desire to SUBSTITUTE SHEET (RULE 26~
-W<~ 971275iG PCT~US97~0076~;

complete tentative travel arra~-y- -~ts with the customer on the phone, and firm up the arra..~. - Ls subsequently ~ith the travel vendor(s). If such inside services are ~-equired, at block 88, system lO initiates an inside services software-assisted routine 88 (described below ith respect to FIGIJRE 13~ that ~L~ _ ~s an agent to c:ontact the vendor(s) and thereby CG--~ -te the travel ~rra~ s.
Othersris~, at bloc3c ~0, system 10 initiates an automated ~uality assurance (QA) software routine, which c:hecks certain aspects of the travel arra--~ ~ Ls made.
A ~; -rcially available QA software routine may be used, such as the AQUA QA software routine. For example, the ~A software routine can search all available computer reservation systems for lower rates than those that were booked by the agent. If the QA software identifies such an ~error,~ the software prompts system 10 to generate a ~flag~ which indicates that some ~o ~e~Live action should ~e taken.
At block 92, system lO determines whether or not an ~error~ identified by the QA software ~ho~ be corrected.
If so, at block 94, system lO prompts an agent (via a workstation display) to make the correction (e.g., book the service at the lower rate). If, however, at bloc~
92, no such ~error~ is identified, then system 10 dete ; n~ whether or not any so-called ~mid-office functions~ should be performed. If so, at block 96, system lO performs (or can prompt an agent to perform) certain quality assurance functions, such as, for example, periodically searching for a lower rate from vendors, up until the time a ticket for the service is printed. Otherwise, the domestic reservations software rnutine is terminated FIGURE 5 is an exemplary flowchart for a receive~route travel reguest software-assisted routine 80, which can be used by an agency to receive and route a SUBSTITUTE SHEET (RULE 26) W O 97/27556 PCTrUS97/00765 travel request to an agent for processing. Referring to FIGURE 5, at block 104, system 10 (preferably using a conventional CTI or o Ler telephony integration system) dete~ i n~e whether or not an in~o~lng telephone call is ~live~ (as opposod to a call carrying fac~imile information or an e ~ ge). I~ so, at block 106, system 10 instructs the CTI system to route the call to a travel agent. Otherwise, if the call is not ~live,~
system 10 operates to routs the call to an appropriat~
receiving medium (e.g., facsimile -~h i n~ or e-mail posto~fice in a local networ~). At bloc~ 112, the system prompts an agent or other agency employee to access the receiving medium (e.g., answer the cal~, or read the facsimile or c ~ CA~e) and identify the type of transaction involved in the request. An example of such a transaction is a reguest to re-book an existing hotel reservation.
At block 114, the agent identifies precisely what the caller is requesting. At block 116, the agent determines whether or not the call includes a request for travel services. If so, the software-assisted routine is terminated, and system 10 ~e~u~..~ to the software routine shown in FIGURE 4. Otherwise, at block 118, the agent either process~ the request or transfers the re~uest to 2S another agent for ~ G~e~sing.
FIGURE 6 is an exemplary flowchart for a software-driven su~routine 82, which functions to make or change a travel arrally~ ?nt, in recponcp to a customer's request.
Essentially, under the control of the ~o~ess request subroutine 82, system 10 operates to trans~er travel and profile information between the relational database in storage device 24 and the agent ~ocessing the travel request.
A customer may provide travel request in~ormation directly to an agent, or system 10 can store the information tPmrorarily in the relation~ 1 database, under S~J~ 111 ~JTE SHEET (RULE 26) -WO 97~27556 ~c~r~us97/~765 the control of an automatic queuing software subroutine.
A ~queue~ can be defined as a working list of items or tasks that are awaiting action. At block 126, system 10 determines whether or not a ~ueue (e.g., an item or task s on the list~ has been ~trigyered~ or fla~ged by the system ~r action. Preferably, each agent at a particular aqency can be associated with a unique set of queues that designate the types of tasks that the agency has assigned to that agen~. When a ~ueue is triggered or f lagged, system 10 notifies the pertinent agent (via a workstation display) that a particular task or set of tasks is to be performed. At block 128, the notified agent responds to perform the task associated with the queue. The software subroutine is then terminated.
Otherwise, at block 130, the travel agent determines whether or not the ~u~l~..L reguest can be associated with an existing p~C-~n~r name record (PNR). A PNR is a record of travel arrangements made in the past for a customer, which can be identified by the customer's name.
Preferably, PNRs are stored by system 10 in the relational database of storage device 24. Consequently, via a workstation 30, a travel agent can retrieve and i ~iately review any previous travel arrangements a customer has made.
If the current travel request cannot be associated with an existing PNR (e.g., a new customer), at block 132, the agent can enter a command (via a workstation), which instructs system 10 to initiate a new reservation software subroutine 132 (described below with respect to FIGURE 8). Otherwise, at block 134, the agent can enter a command that instructs system 10 to initiate a change reservation softwa~e subroutine 134 (described below with respect to FIGURE 7).
FIGURE 7 is an exemplary flowchart for a software-as~isted subroutine 134, which can be used by an agent to change an existiny travel reservation. Preferably, under SU~ 111 UTE SHEET (RULE 26) .

W O 97/27556 PCTrUS97/00765 the ~onLlol of the change reservation subroutine 134, system 10 ~LI, Ls a travel agent to make one or more changes to an existing set of reservations.
At block 142, before any changes can be made, system 10 initiates a service tracking software subroutine.
Since an agency typically can bill a customer for all services provided, the service tracking so~tware automatically ~ r ds each transaction that occurs if any arrangements are being changed. The fiervice tr~k- ng information is preferably stored by system 10 in the relational database 24.
At block 144, system 10 searches the relational database for the requesting customer's PNR. At block 146, the system ~L~, LS the agent to dete ine whether or not the request includes CAn~el; n~ all existing travel reservations. If so, at block 147, the agent inputs a - ~n~ that instructs system 10 to record the cancellation as such, in the relational database. The software subroutine 134 is then terminated.
Otherwise, at ~lock 148, system 10 ~L~ , Ls the agent to obtain and input ~via a workstation 30) the customer's requested ~usiness entity changes. For example, a business customer may be requesting the agent to change the c~mrAny's billing code to be charged for an existing reservation.
At bloc~ 150, sy~tem 10 ~L~ , ~5 the agent to determine whether or not a change in air travel arran~f -nts has been re~uested. For example, the customer may have requested a flight change. If so, at ~loc~ 152, system 10 retrieves the customer's profile information and customer reservation service information, from the relational dat~h~?, and displays that information to the agent. The agent inputs the change information to system 10, which stores the information in the relational dat~h~sQ for hooki ng, S~JtsS 111 UTE SHEET ~RULE 26) W 097/27556 PCTnUS97/00765 Essentially, the method used to determine and store air change information (blocks 150 and 152) preferably is also used to determine and store changes requested ~or rail, auto and hotel arrangements (~locks 154-164).
At bloc~ 166, ~ystem lo ~L~ _ LS the agent to dete~ whether or not the customer requires any change to a ~sre~i~l needs~ arra~ nt alrèady made, such as, for examp}e, any sr~ci~l facilities requested ~or a ]?hysically-disadvantaged cu~tomer~ or a spqAi~lly prepared meal. If so, at block 168, the agent inputs the requested changes to system 10, which stores the information in the relational dat~h~~~ for booking.
At block 170, system 10 preferably displays, for the agent, a summary of the customer's chAn~e~ and ~tnrh~nged t:ravel arrangements. At the same time, the system also displays an employer~s business policies, ~1;~el;nes, or restrictions for travel, if any. Co"cequently, the agent can review the latest travel arrangements for a customer, in order to detel ; n~ if they meet the employer's re~uirements. At block 172, the agent inputs any non-c:ompliant arranqements (sometimes required by an individual customer or an oYi~ y) to system 10, which stores the information in the relational database.
At block 174, system lo updates the customer's PNR
in the relational dat~h~ce, with the latest travel arran~,- ~ t changes, and displays the updated PNR to the agent for review. At block 176, the system ter i~tes the service tracking routine, and the present software routine 134 is terminated.
FIGURE 8 is an exemplary flowchart for a software-assisted subroutine 132, which can be used by an agent to make a new travel reservation. Essentially, under the control of the new reservation subroutine 132, system 10 y-~ ~Ls a travel agent to make a new set of travel 3~ reservations for a customer. At block 184, for accurate billing, system 10 initiates the service tracking SUt~ 1111 3TE StlEET (RULE 26) WO 97127~56 PCT~US97/00765 subroutine described above. At block 186, system 10 retrieves the customer's individual pro~ile information, and the employer's profile information (if any) from the relational dat~e, and displays the information to the agent via a workstation. At bl-ock 188, system 10 ~L~S
the agent to review the profile information. At block 190, system 10 creates a PNR for the customer in the relational dat~hAse, and stores the profile information in the PNR. At block 192, system 10 ~u~yLs the agent to obtain and input (via a workstation 30) any business entity information required by the customer's employer (e.g., billing code to be charged).
At block 194, system 10 deter ;nes whether or not an air travel reservation is required. If so, at block 1~6, system 10 ~LI lLs the agent to input the air reservation information to system 10, which stores the information in the relational data~ase for ~on~i ng, Essentially, the method used to determine and store ~ir reservation information ~blocks 194 and 196) preferably is also used to det~l ine and store new information for requested rail, auto and hotel arrangements (blocks 198-208).
At block 210, system 10 prompts the agent to determine whether or not the customer requires any ~special~ travel arrangements to be made. If so, at block 212, the agent inputs the requested changes to system 10, which stores the information in the relational dat~
for ho~
At block 214, system 10 preferably displays, for the agent, a ~ D~y of the customer's travel arra~ ts.
At the same time, the system also displays any employer's business policies, guidelines, or restrictions for travel, if any. Consequently, the agent can review the new travel arrangements for a customer, in order to determine if they meet the employer's requirements. At block 216, the agent inputs any non-compliant S~,~,5i 111 ~ITE SHEET (RULE 26) W Og7S~556 ~CTnUS97/00765 arrangements, if any, to system 10, which stores the - ;information in the relational database. At block 218, system 10 displays the new PNR to the agent for review.
~t block 220, the system terminates the service tracking routine, and the present ~oftware routine 132 _s t~::r i nAted.
FIGURE 9 is an exemplary flowchart for software-a,ssisted routine lZ8, which can be used by an agent to perform certain arra..~ L follow-up tasks. As described above, system 10 stores certain ~ollow-up tasks in an agent's queue or worklist, in the relational datAh~e?. System 10 relates each task in the queue with a specific PNR, since the PNR readily identifies the requesting customer. Under the ~llL.ol of the follow-up software subroutine 128, system 10 ~ _Ls the travel agent to perform the actions listed in the agent's queue.
Specifically, at blocX 228, system 10 initiates the service tr~ki n~ software routine described above. At block Z30, system 10 ~ Ls the agent to retrieve the PI~R information ARcoci~ted with each task listed in the aqent's queue. At block 232, system 10 ~L~ , ~5 the agent to identify the action(s) required in the queue. At b~ock 234, system 10 ~ Ls the agent to identify whether or not a travel services vendor should be contacted, in order to complete the selected action(s).
I~ so, at block 236, system 10 prompts the agent to contact the vendor. Otherwise, the software routine pro~e~C to block 252.
At block 238, the system ~1~ Ls the agent to ~i~c~ pertinent travel service options available with the vendor. At block 240, system 10 ~ s the agent to determine whether or not the re~uested travel service is a-.~ilable from that vendor. If so, at block 244, system 10 ~l~ ~s the agent either to book or ~wait listr the r 35 requested service for that customer. Otherwise, at block 242, system 10 ~l~LS the agent to dete~ ~ne whether or SIJ~S 111 ~JTE SHEET (RULE 26) W 097127~56 PCTrUS97/00765 not the agent should contact an alternate vendor. If so, the agent is ~LI , Led to contact the vendor (block 236).
If not, at block 252, system 10 prompts the agent to determine whether or not the agent should contact the customer.
At block 246, system 10 ~ ~m~Ls the agent to confirm that any special arran~. -nts made have been booked with the pertinent vendor. At block 248, system 10 plG~S
the agent ~o determine if any non-bu~ine~ entity restrictions apply to the travel arran~ ~ Ls that have been made (e.g., hotel check-out required by 12:30 p.m.).
At block 250, the agent inputs information (via a workstation) about the results of the tasks completed.
System 10 stores the results information (e.g., completed or ~lnc- leted tasks) in the relational dat~base.
Returning to block 252, if the agent determines that a customer Cho~ be contacted, for any reason, the softw~re routine pror~C to block 254, and the customer is contacted by tel~rh~n-, facsimile, etc. At block 256, system 10 ~.l Ls the agent to ~ jCC1~5 any open issue with the customer. For example, the agent may ~7~ s the possibility o~ changing ~he customer's seating arran~ - L, if a more desirable seat h.o--o~ available.
At block 258, the agent is ~L~ Led to input information about whether each outst~nrl;ng issue has been resolved.
If not, the software returns to block 232, where the action or task to be completed is identified. The software continll~C to block 234.
Otherwise, if all outst~;nq issues have been identified as resolved by the agent, at block 260, the system updates the customer's PNR with the most current travel arrangement information. At block 262, the system ~1~Ls the agent to document the complete discussion with the customer. At block 264, the system terminates the service tracking routine, and at block 266, the present software routine 128 is te- in~ted.

SU~ 111 L1TE SHEET ~RULE 26~

WO 97/27S~6 PCrnUS97~ 65 FIGURE 10 is an exemplary flowchart for a software routine 84, which can be used by an agent to complete any PNR-related tasks that were not performed during the initial customer contact. Referring to blocX 272 in S FIGURE 10, for agency hi I 1 i n~ , system lo initiates the service tr~k; n~ software routine described above. At block 274, the system ~ Ls the agent to determine, and input information about, whether or not any tasks A-cso~iA~ed with ~he requesting customer's PNR
O ~1 ~ ;n to ~e completed. If so, at b}ock 276, the system y~ Ls the agent to complete the unfin;che~ task(s).
Otherwise, at block 278, the system retrieves the travel arra..~ -nt infor~ation from the PNR stored in the relational database, and ~l -~es the information with a predetel ;ne~ set o~ ~c~ality~ criteria. At block z80, using the -~ -~ison information, the system determines ~whether or not the agent has made any ~errorsr or deviances from the ~quality~ criteria. If so, the system ~.. Ls an agency employee (prefera~ly a supervisory agent) to see that the ~e~ re corrected at block Z82. The system continues to check the ~uality~ of the agent's work, on the pertinent request, until all the Uerrors~ are ~ -' co~ ~Led.
At block 284, the system ~ 5 the agent to determine whether or not an electronic ~recap~ (e.g., ~acsimile or c -il message~ of the det~ travel arra..~ -~ts should be sent to the customer. If so, at block 286, the system cJenerates and transmits the ~recap~
over an a~L~ iate medium to the customer's facsimile receiver or e-mail post-o~ice box.
Otherwise, at block 288, the system determines whether or not any action still ~ -i nc to be performed, in order to ccmplete this travel request. For example, a hotel may still have to be called to verify rates or c~uarantee a reservation. If so, at block 290, the system designates which resource--agent or --hi ne--will be SIJ~;~ JTE StlEET (RULE 26) responsible for completing the open action(s). At block 292, system lO ou~.Ls a '~ueue~ to the designated resource, which notifies the agent, or activates the 7~rhi~ to complete the task(s) in the ~queue.~
At block 296, the system .,I.L~uLs a 'gueue" to initiate a QA program, such as, for example, the AQUA QA
software routine. The QA software is used by an agency to ensure that it is providing high guality services. At block 296, the se3:vice trAçki nq software routine is terminated. The present subroutine 84 is then terminated.
FIGURE 11 is an exemplary ~low chart for a software-assisted routine 94, which can be used by an agency to correct any error that has been identified by the QA
software routine illustrated ~y FIGURE lO. As described above, a QA software routine may ~trigger~ one or more queues when a quality assurance "~ is detected. A
particular agent is preferably designated to complete the tasks in one or more unic~ue queues. At block 304, the ~ystem retrieves a unique set of ~aueues for an agent. At }:lock 306, the system dete~ i n~-S whether or not any actions relating to any PNR are listed on the agent's queue(s). If not, the so~tware routine 94 is terminated.
Otherwise, at block 310, the system initiates the service tracking software. At block 312, the system displays the ~open~ PNR to the a~l-~y iate agent. At block 314, the system also displays any ~error" remarks generated by the QA ~- G~L to the agent. These "errorn remarks signify that the P~R contains certain errors associated with ~oce~sing, e~ o~ Ling, or ticketing, in le~yor.se to a travel re~luest. At block 316, the system determines whether or not the PNR contains critical error~ remarks. If not, at block 318, the remarks are displayed for review by an agent. At block 320, the 3S system ~m~ls the agent to determine whether or not the customer needs to be contacted. If so, at block 324, the SU~5~ ITE SHEEl (RULE 26) W O 97~7556 PCT~US97~0765 system initiates a follow-up software routine, such as the routine 128 illustrated by FIGURE 9. Otherwise, at block 322, the system ~Ls the agent to take the action required to L~ ~e the ~errorr. For example, if the QA P10YL has det~ ined that the dates for the travel arraS.~ n1:9 described in a PNR do not ~ e;,~Jnd to the dates specified in the travel request, the agent is ~ ed to re book the arrangements for the proper dates. At bloc~ 326, the ~y6tem ~tor~ those changQs, if any, in the PNR in the relational datAhA~.
At block 328, the system prompts the agent to determine whether or not the corrected PNR information should be retrieved and operated on by the QA routine.
If so, at block 3~2, the information is transmitted for lS processing to the Q~ routine. Otherwise, at block 330, the system indicates that the transaction has been completed. At this point, the customer typically has either committed to complete the travel arra.,y -~ts or ~eclined. At block 332, the system terminates the ~ervice tracking routine, and the software returns to block 306.
Returning to block 334, for a critical QA ~error,~
the software routine performs essentially the same method performed for a non-critical ~error~ (blocXs 320-328) except at block 342, the system transfers the PNR
~queue(s)~ directly to the QA ~oy~am. The system then pro~AC to block 332.
FIGURES 4-11 illustrate the operation and functions of the domestic reser~ations -..ent 56. Notably, the method for the international reservations -~ _ ~nt 58 c:an be performed with the method used for the domestic reservations component 56. The primary difference between the two reservation _ - ?nts is that one can be used to make and change domestic travel arra~.y~ ?nts, and the other can be used to make and change international SU~SIllUTE SHE~T~RULE26) WO 97/27556 PCTrUS97/00765 arrangements. The two components' software and manual functions are substantially the same.
FIGURES 12-16 are exemplary flowcharts of software-driven functions that can be performed for a travel agency, in conjunction with an agent, by the support co~l.e..L 60 shown in FIGURE 3. Specifically, FIGURE 12 is an exemplary flow chart for a software-assisted routine 344, which can be used by an agent to perform pre-ticketing quality assurance. Pre-ticketing QA can be used by an agency to perfo~m a final check on a customer's travel arrangements, before the customer's tickets are issued.
At block 348, the system initiates the service tracking software ~.OYL described earlier. At block 350, the system y I ,Ls the agent to select a queue (or QA category) that lists one or more QA ~he~C that should be perfo~med on the customer's arr~n~- -~ts. At block 352, the system ~r ~ ~ Ls the agent to select a check to be performed, from the selected gueue or category. Each 20 check selected preferably ~ ~lc to a travel ~rrangement that should be verified or reviewed, such as, for example, the fares and seating availability on flights. At block 354, the system ~L~, Ls the agent to perform the selected check.
At bloc~ 356, the system ~,. ,Ls the travel agent to determine whether or not any ~-hi-- _ 6 still should be made to the travel arr~- J. -nts. If 80, at block 358, the system ~, ,Ls the agent to determine whether or not the changes to be made are o~ the type the agent can make.
For example, if reservations have been made for the wrong date, the agent can determine the correct dates and book the change. If the agent cannot make the change, at block 360, the system stores those ~errors~ in the relational database for ~ e~O~ Ling ~ul~Gses. Otherwise, at block 362, the system ~- ,Ls the agent to make or book the change.

SUBSTITUTESHEET(RULE26) W ~971~7~56 PCTnUS97/0076 At block 364, the system (iteratively) ~Ls the agent to determine whether or not the check being processed is the last ch-ck listed in the queue or category. If not, the software loops back to block 352.
Otherwise, at block 366, the system dete ines whether or not any action is required to be taken on the check being made. If so, at block 368, the system tra~smits a queue to an a~v~Liate resource (e.g., travel agent or su~o~L
sta~f ), which ; n~ ; c~tla~ that c~rtain action ~ho~ be ta~en on the customer's arrangements.
At block 370, the system terminates the service trac~ing routine, and the present software routine is terminated.
FIGURE 13 is an exemplary flowchart for a software-assisted routine 88, which an agent can use to completetravel arra~.y ?nts that may require direct contact with a vendor, or the arra,.~. ~ Ls may be too ti - c~,lal ;ng to complete whi7e the customer is on the phone. Although the present routine 88 is associated with the support component 60, it can be initiated during operation of the domestic reservations component 56.
Referring to FIGURE 13, at block 378, the system retrieves a queue of outstAn~i~g actions to be completed.
At block 380, the system initiates the service trAcki ng software routine. At block 382, the designated travel agent (identified by the queue) selects a task to complete. At block 384, the agent ~ es the arrangements made with the employer's g~ l in~, if any.
At block 386, the system y~ Ls the agent to determine whether or not a vendor should be contacted. If not, at block 408, the system ~L~_, Ls the agent to perform the required action.
otherwise, at block 388, the agent selects a ~ lnications mode to contact the vendor. At block 390, if the selected mode is by tele~hone, the agent calls the vendor. If another mode is selected, at block 394, the S~J~;; 111 LITE Sl IEET (RULE 26~

WO 97/275~6 PCTrUS97100765 system ~L~ _ Ls the agent to prepare a ~ ication, such as a letter or e-mail message, which is sent to the vendor at block 396.
At block 398, a~ter receiving a response from the s vendor, the system ~l Ls the agent to determine whether or not the vendor has confirmed the re~uested arrangement. If so, the software pro~e~ to bloc~ 410.
otherwise~ at block 400, the system ~ ~ L5 the agent to detel ;ne whether or not the service to ~e pro~ided is still r~n~in~ without being confirmed. If the service is still I~n~; n~, the software proceeds to block 414.
Otherwise, at block 402, the system pL~ _ LS the agent to contact and advise the customer about the still pending arrangement(s). At block 404, the agent is ~ Led to determine whether or not any further action should be taken for the retrieved gueue. If so, the software proceeds back to block 382.
Returning to block 410, if the customer should be contacted, the software pr~c to block 412. ~he agent then contacts and advises the customer about the pending arran~r - L(s). Otherwise, at ~lock 414, the agent inputs information about the changes made to the system, ~nd at block 415, the system stores the input information in the PNR in the relational dat~ r. At block 416, the system ,~/LI , Ls the agent to dete~ in~ whether or not any follow-up action ~ho~ be taken. If so, at block 418, the agent inputs the follow-up information to the system, which stores it in the relational database.
At block 420, the agent determines whether or not the vendor action being proc~ss~~ is the last action listed in the queue. If not, the software proceeds to block 382. Otherwise, at block 422, the system transfers the gueue task information to the QA software ~Oyr the function of which has been de~cribed above. At block 424, the system terminates the service tr~kin~ routine.
At block 426, the system determines whether or not the S~JL.~ 111 ~ ITE SHEET (RULE 263 PCT/US97~00765 WO 97/275~i6 PNR being processed is the last PNR listed in the queue.
rf not, the software ~roc~eAc ~ack to block 380.
Otherwise, the present software routine is then terminated.
FIGURE 14 is an exemplary flowchart for a queue management software routine 430. Queue management ~oftware routine 430~can be used to redistribute actions associated with di~ferent PNRs from one queue to another, or ~ ve an action from a queue once the action has beQn co~pleted. At block 434, the system retrieves the queue c:ount information from the relational database and displays it to an agent. The agent deteL ines the status of each queue. At block 436, the agent dete~ ;ne~
whether or not any queue contains a task that still should be completed. If at least one queue contains an incomplete task, ~he software proceeds to block 440.
Otherwise, at block 43~, the software routine is terminated.
At block 440, the agent selects a ~ueue that contains at least one task that still should be completed. Each task is ~csoci~ted with a specific PNR.
At b}ock 442, the system sorts the PNRs associated with the tasks by : u~er reservation system. For example, a queue may list five P~Rs, three related to airline travel, and two related to bus travel. Airline travel arra..~. ?~ts are typically made using information from an airline travel ~ ~Ler reservation system, while bus travel arral-y. -~ts are made using information from a different f_ uLer reservation system. Preferably, the sy~stem retrieves the c ~ ~er re~ervation system from the relational dat~h~e~
At block 444, the system retrieves information from a selected category within the : Ler reservation system. Each cate~ory is associated a certain type of arrangement. For example, one category may specify either smoking or no" -k;n~ seating arran~. -nts, while SUBSTITUTE SHEET (RULE 26) PCT~US97/00765 anot~er category may speci~y first class seating or coach. At block 446, the agent is prompted to review the PNR associated with the selected category. At block 448, the system ~ Ls the agent to determine whether or not any action is re~uired with respect to the reviewed PNR.
If so, at block 452, the system transmits a queue to an a~ iate resource, which indicates action should be taken. otherwise, at block 450, the system ~~ ~ves the PNR information from the ~ue~e.
At block 454, the system ~L~ Ls the agent to deter ine whether or not the current PNR being processed is the last PNR that should be reviewed. If not, at bloc~ 446, the system retrieves the information from the next PNR to be reviewed. At block 456, the system ~l~ Ls the agent to determine whether or not the current ~; -Ler reservation system category being processed is the last category that Ch~ be reviewed. If so, the software eLu~,.s to block 434. Otherwise, the software returns to block 444.
FIGURE 15 is an exemplary flowchart for a software routine 458, which can be used to create and update individual and business entity profiles. Referring to FIGURg 15, at block 462, system 10 initiates the service tracking software p~ . At block 464, the system ~L ~ Ls an agent to select a ~ueue for review. At block 466, the agent is ~ ~ ~ed to identify the particular task to be performed from the queue (e.g., update a specific individual or ~usine~s entity profile). At bloc~ 468, the agent is ~r~ Led to review the business entity travel guidelines and policies (e.g., restrictions) stored in the relational dat:~h~ . At block 470, the system ~lu ~s the agent to determine whether or not the profile under consideration may be updated. If not, at block 472, the PNR information retrieved from the relational dat~h~e is restored. At block 474, the system (or the agent) designates an agent, S~Ill~TE SHEET~RULE 26) Wo ~Jn75~6 PCT~US97~W7~5 or another employee (or a ~hlne) to follow up the task (attempt to update at a later time). At block 476, the system transfers the queue(s) to the designated follow up resource. For example, another agent can be notified by the queue that an attempt should be made to update the profile at a later date. At block 484, the system then terminates the service trAc~ki ng so~tware routine.
Otherwise, if an update to the profile can be made, at bloc~ 478, the agQnt performs the update by inputting the new information via the workstation. The system stores the update information in the profile residing in the relational dat~h~. At block 480, the agent inputs a c~ A which indicates for the system that the profile update has been co~pleted. At block 482, the system stores a ~1ag indicating that the profile has been updated, in the PNR in the relational dat~h~c~. The software p u~ee~lC ~o block 484, where the service 1:racking software routine is te~ inAted. The present software routine is then terminated.
FIGURE 16 is an exemplary flowchart for a software-driven routine 488, which an ~ .~y may use to automatically ~r ~e_S a ~eL~ ~' ticket. For example, ~uch a return can include a ticket ~LuL.,ed for a refund or exchange, or a voided ticket. Essentially, the system maintains (in the relational dat~hAr~) an inventory of all tickets pro~s~ by the agency. The system thereby assists the agency in managing the ticket ~L ucessing .
I'he inventory information can include an indicator that the ticket may be returned. The system also assists the agency specifically with managing the inventory of returned tickets.
Referring to FIGURE 16, at block 492, system lO
initiates the service tracking software routine for ~illing purposes. At block 494, an agent receives a returned ticket from a customer. The system prompts the agent to determine the disposition of the ticket (e.g., Sl~ ITE SHEET (RULE 26) , PCT~US97/00765 the reason for the e~ulll snd action to be taken). For example, if the ticket has been returned for a refund, the customer~s a~c~.~L should be credited.
At bloc~ 496, the system dete~ ;neC whether or not the returned ticket is on the "expected" return log in the relational da~h~. The ~expected~ LeLuL.~ log can be the listing of tickets in the dat~hA~e that the agency has identified as likely to be r ~L~l..ed. For example, a ticket is likely to be l~Lu~ when a customer has an issued ticket c~celed and recèives another ticket in its place.
If the leLu~led ticket is not on the ~expectedr return log, at block 498, the system ~- ~-s the agent to determine whether or not the ticket was leLull~ed in error. If so, at block 502, the system ~ ~s the agent to take Cpeci fic actions with .LC_~G~;L to the customer' 5 ac~Gu.,L, such as, for example, reviewing a business entity's gui~eli n~C or restrictions that should be followed whenever an employee's ticket is ~eL~ ~ed. At block 532, the software routine is then terminated.
On the other hand, if the ticket was not returned in error, at block 500, the system ~ ,Ls the agent to determine speci~ically why the ticket was returned. At block 504, the system ~. Ls the agent to determine whether or not the ticket is void. If the ticket is void, at block 508, the system processes the void ticket by esta~?i~h j ng - ication with an a~r~iate CRS and noting the ticket as void in that CRS. Accordingly, billing and reconciliation for the void ticket is halted.
Otherwise, at block 506, the system prompts the agent to deteL i ne whether or not the ticket is being returned for a refund. If so, at block 510, the system proc-~e~C the refund by establi ching _ ication with the appropriate CRS and A~C a~ounLing system and noting in those systems that the refund is due. Furthermore, if the customer must pay a cAn~ tion fee for the refund, SUv~ 111 ~ITE SHEET (RULE 26) W ~g7~2~556 PCT~US97~076S

system lO notifies the agent that reconciliation is re!quired for the ~c~ tion ~ee. At block 512, the system stores the void and refund transactions in the customer~s PNR in the relational dat~h~e.
Returning to block 506, if the leL~l~. is not a refund, at b}ock 514, the system ~ ~ Ls the agent to determine whether or not the ticket has been returned for an i -'iAte ~Ych~n~e. If so, at blocks 518 and 520, the agent inputs a com~and to the system that allows the system to store the ~Y~nqe information in the PNR, for ~o ~nting purposes. Otherwise, at block 516, the sy~stem ~ ~ Ls the agent to determine whether or not the ticket has been L~L~n~d for a fuLu~e ~rhAnge. If 50~
at block 522, the ~gent inputs a _ ~n~ to the system, lS which initiates the oftware rou~ine described above that updates the customer's (and employer's, if any) profile.
If not, at block 524, the system prompts the agent to re~earch and determine what actions sh~ be per~ormed, anel then perform the a~ ~iate task.
Returning to block 526, the system ~ _ ~s the agent to place the L~LuL.,ed ticket in an a~ iate receptacle for physical inventory. At block 528, the system ~logs~
the action(s) or task(s) performed by the agent, by storing information about the action(s) taken, in the relational dat~hnce. At bloc~ 526, the system terminates the service tr~c~inq software routine, and then tc i~AteS the present routine.
FIGURES 17-19 are exemplary flowcharts of software-ass;isted functions or ~ _n~nts that can be performed for a travel agency, by the global distribution _ _n~t 48 shown in FIGURE 3. Specifically, FIG~RE 17 is ~n exemplary flow chart for a ticketing and delivery - software-assisted rout-r.e 534, which an agency can use to assist an agent to generate tickets and deliver them with related ~oc- -nts (e.g., an invoice) to customers. At block 538, the system ~7 ~ , ~S an agency employee to SUt~ 111 ~JTE SHEET (RULE 26) W O 97/27556 PCTrUS97/00765 l~ ~e a ticket from the printer and match it with the related ~o~ -~ts. At block 540, the system prompts the employee to coordinate the distri~ution of the documents for delivery. At ~lock 542, the system ~L' _ Ls the employee to send certain of the ~o~ -nts (e.g., the tickets) to the customers. At block 544, the other ~nl. -ntS can ~e sent, for example, to the vendors providing the travel services. At block 546, the present software routine is terminated.
FIGURE 18 is an exemplary flowchart for a software-assisted routine 540, which an agency can use to coordinate and distribute travel ~o~ -nts for delivery.
This routine can be used to organize the dG- -ntS, so that the do. -~ts being sent to one destination can be combined in one delivery. At block 552, the system prompts an agency employee to sort the travel ~oc~ments by delivery location. For exsmple, all airline tickets, train tickets, and hotel reservations requested ~y a particular customer are placed together. At block 5~4, the system ~.~ ,Ls an employee to package the do_ ?~ts that have been sorted together. The system also ~v~Ls the employee to package any additional do~ -~ts, such as, for example, car rental adverti F' Ls, along with the sorted ~o~ -~ts.
At block 556, the system .~ ~s or stores the delivery method used for the '-_ - Ls, in the relational database. For example, the system can ~o~ t~e customer's name, information about the tickets being sent, the name of t~e delivery service utilized, and the date the delivery service received the tickets for delivery. Consequently, the system can keep track of the ~o~ ts once they are turned over for delivery. At ~lock 558, the so~tware routine is terminated.
FIGURE 19 is an exemplary flowchart for a software-assisted routine 560, which an agency can use to deliver tickets and other related ~n~ ~ Ls to the re~uesting SUBSTITUTE SHEET (RULE 26) W 09~12~ss6 PCTnUS97/00765 customer. Referring to FIGURE 19, at block 564, the system ~L~ ~ ~5 an agency employee to sort the documents by delivery type, such ~s, for exa~ple, by Federal ~ Express, Express Mail, or the United ParCel Service. At block 566, the system ~L~ _ Ls the employee to prepare the documents by delivery type. ~on~ently, ~o_ ~nts which should be sent out i ~ tely can receive a high p:riority. The software routine is then terminated.
FIGURES 20-21 ~re exemplary flowcharts of software-driven functions that can be performed for a travel agency, by the special services _ ~IL 50 shown in FXGURE 3. Specifically, FIGURE 20 is an exemplary flowchart for a software-assisted routine 570, which can be used by an agency to prompt a Lr~o~re to, and keep 1~ track o~, any custo~er problems.
At block 574, the agency receives travel-related information typically during a call from a customer. At block 576, the system yL~ Ls the employee receiving the call to identify any problem so that it can be routed to an a~L~EJ iate resource for h;~n-lling. At blocks 578 and 5~0, respectively, the problem information c~n also be received from a vendor or another travel agent. At block 582, the system p.~ Ls the employee tor other personnel) to conduct h~ J o~nd research for the problem(s). For example, if a customer has not yet received his or her ticket by a specified date, an agent may call the service that was Lr-~orcible for delivering the ticXet, in order to determine what happened to the ticket. At block 584, the system ~LI _ Ls the agent to resolve the problem and notify the customer that it has been resolve. The software routine is then terminated.
F~GURE 21 is an exemplary flowchart for a bac~Lou~.d -asearch so~tware routine 582, which can be used by an agency to assist with background L~ rch for a cus~omer's problem. Referring to FIGURE 21, at block 592, the system ~ ~Ls an agent to determine whether or S~J~ 111 UTE SHEET (RULE 26~

W O 97/27556 PCTrUS97/00765 not a travel services vendor needs to be contacted about a pro~lem. If so, at block 593, the system p~Ls the agent to obtain information that can be used to resolve the problem, ~rom the vendor. At block 594, the system ~ll- Ls the agent to perform a wrap-up by ~o_ -~ting in the system the re~uired information about the pro~lem and its resolution. At block 596, the system p~u~Ls the agent to generate a service queue to perform the service properly for the customer. The 50ftware routine is then terminated.
otherwise, at block 598, the system pl~yLs the agent to determine whether or not the customer has previously ~n~ollntered similar problems. I~ so, at block 600, the system ~.~ Ls the agent to ~icc~s the problem with the customer. At block 602, the system displays (to the agent) typical pro~lems ~n~ol~ntered by customers, and a ~st~n~dized~ set of ~o~-Gl~es that could be used resolve the problems. This problem history information is main~i n~ by system 10 in the relational database.
The agent thus can dete.~ tn~ whether or not the database has a st~A~dized resolution for the type of problem being add~ . If so, at block 604, the system ~ s the agent to determine whether or not a st~n~A~dized resolution can satisfy the problem. I~ so, at block 606, the system prompts the agent to input information to the system that updates the relational database with the most ~ enL prob}em being addressed and the resolution method used. The present software routine is then terminated.
Otherwise, if the st~A~dized resolution method will not satisfy the problem being addressed, at block 608, any new method used by the agent to resolve the current problem is input and stored with the other .esolution methods in the re}ational database.
Returning to block 610, the 5ystem determines whether or not the employee hAn~l in7 the inco~;n~ call is a customer service ,e~esentative. If not, at block 614, S~l~ 111 UTE SHEE~ (RULE 26) WO 97~Z7556 PCT~US97~0076 a wrap up is performed by documenting the reguired information about the problem and its resolution. The software routine is then terminated. If, however, the ~ employee handling the call is a customer service representative, at block 612, the system p I Ls the employee to review a display of problems (retrieved from the relational dat~h~-s~) and determine whether or not the da~h~c~ contains a similar pro~lem, along with a correspon~ st~n~rdized resolution method. If 80, th~
software ~eLu ..s to block 604. Otherwise, the software proceeds to block 608. The software routine is then terminated.
F}GURE 22 is a flow diagram which illustrates a method (lOoo) an agency may use to automatically manage travel information, in accordance with a preferred embodiment of the present invention. At block 1004, system lO generates a business entity profile for a customer. At block 1006, the system generates an individual profil~ for a customer. The system stores the profile information in the relational dat~h~ce. At block 1008, a travel request is received from a customer over a suitable - n;c~tions medium. At block 1010, system lO
retrieves information (preferably via a TIA subsystem) from one or more _ ~Ler reser~ation systems. The system stores the customer reservation system information in the relational database. At block 1012, the system displays for use by an agency employee the business entity profile and individual profile information, for the requesting customer. At block 1013, the system integrates the customer reservation system information and the business entity and individual profile information, for that customer's re~uest, preferably by related data ,ields. consequently, the agent can ~CC~s5 ~he customer reservation service information and the profile information, at the same time. At block 1014, the system generates appropriate travel arrangements in Slu~ TE SHEET (RULE 26) W O 97/275S6 PCTn~S97/00765 -accordance with the travel request. The method is then terminated.
Although the present invention and its advantages have been described in detail, it should be understood that various changes, ~ubstitutions, and alterations can be made therein without departing from the spirit and scope o~ the invention as defined by the appended c~aims.

S~l~;i 111 ~JTE SHEFT (RULE 26~

-

Claims (18)

WHAT IS CLAIMED IS:

1. A method of providing decisional support for travel services, comprising the steps of:
generating a business entity profile;
generating an individual profile;
automatically accessing a computer reservation system to obtain inventory information;
storing the business entity profile, the individual profile, and the inventory information in a database;
receiving a travel request from a customer; and automatically accessing the database in response to the reception of the travel request.

2. The method of Claim 1, further comprising the step of generating complete travel arrangements for the customer in response to the received travel request.

3. The method of Claim 1, wherein the step of automatically accessing the computer reservation system comprises the step of receiving inventory information relating to travel services from the computer reservation system.

4. The method of Claim 1, further comprising the steps of:
generating travel documents in response to the travel request; and distributing the travel documents to the customer.

5. The method of Claim 1, further comprising the step of updating the business entity and individual profiles.

6. A method of providing decision support for travel services, comprising the steps of:
generating a business entity profile, the business entity profile having business entity information relating to at least one business entity;
generating an individual profile, the individual profile having individual information relating to at least one customer;
automatically accessing inventory information from a computer reservation system;
receiving a travel request from the at least one customer;
automatically retrieving business entity information from the business entity profile and individual information from the individual profile in response to the reception of the travel request; and generating travel arrangements for the customer in response to the received travel request, the retrieve business entity and individual information, and the access inventory information.

7. The method of Claim 6, wherein the step of generating travel arrangements is performed automatically.

8. The method of Claims 3 or 6, further comprising the steps of:
automatically accessing inventory information from at least one other computer reservation system; and integrating the inventory information received from the computer reservation systems so that the inventory information is accessible by a single format.

9. The method of Claim 6, further comprising the step of integrating the retrieved business entity information, the retrieved individual information, and the accessed inventory information so that the business entity information, the individual information, and the inventory information is simultaneously accessible.

10. The method of Claim 6, further comprising the step of updating the business entity information in the business entity profile and the individual information in the individual profile.

11. The method of Claim 1 or 6, further comprising the step of storing the business entity profile, the individual profile, and the inventory information in a database.

12. The method of Claim 11, wherein the step of storing comprises the step of storing the business entity profile, the individual profile, and the inventory information in a relational database.

13. A system of providing decisional support for travel services comprising:
a database operable to store a business entity profile, an individual profile, and inventory information obtained from at least one computer reservation system;
and a processor connected to the database and operable to:
automatically access a computer reservation system to obtain inventory information;
receive a travel request from a customer; and automatically access the database in response to the reception of the travel request.

14. The system of Claim 13, wherein the processor is further operable to generate travel arrangements for the customer.

15. The system of Claim 13, wherein the business entity profile contains business entity information relating to at least one business entity and the individual profile contains individual information relating to at least one customer.

16. The system of Claim 13, further comprising a travel information analysis device.

17. The system of Claim 13, wherein the processor is further operable to:
automatically access at least one other computer reservation system; and integrate inventory information from the computer reservation systems so that the inventory information is accessible by a single format.

18. The system of Claim 13, wherein the processor is further operable to verify fares for travel services provided abroad.