System for Batch Scheduling of Travel-Related Transactions and Batch Tasks Distribution by Partitioning Batch Tasks Among Processing Resources

The present invention relates generally to a data management method and architecture. In particular the present invention relates to a data management method and architecture allowing user-absent execution of scheduled batch tasks and administration of accounting information in environments that typically involve multiple users requiring access to centrally stored data such as the travel industry.

The growth of the airline business from the early 1980's to the 1990's has resulted in the proliferation of travel agencies and other travel information groups that require access to large volumes of data in a "real time" environment. This growth has spurred many technological advancements in central reservation systems (CRS) for the transportation industry and in particular the airline industry. Examples of such systems are the American Airlines Inc.'s SABRE system, System One, Covia and Worldspan.

As the number of travel agencies and other travel providers has grown, the importance of automating their business practices such as accounting and report generation has also increased. Innovations for the back-office business side of travel providers have grown from calculators, adding machines and manual file systems to very sophisticated accounting software packages which are commonly available in the market place today.

Until the present invention, however, there has not been a successful integration of the a "real time" central reservation system with the modern travel provider back-office accounting and reporting packages taking full advantage of distributed personal computer processing capabilities. For example, the central reservation systems have gone from a relatively small number of mainframe computers to vast multiplexed systems not specifically designed for a given backoffice environment. Furthermore, in the past the mainframe computers were almost always connected to "dumb" terminals, i.e. terminals having no independent processing power and incapable of handling any of the accounting and reporting processing.

Beginning in the mid-1980's, the Personal Computer (PC) began replacing the "dumb" terminals, thus making the processing power of the PC available to the travel provider. Until the present invention, however, a method and architecture that could take advantage of the newly available processing power was not available. Most previously developed methods and architectures depended on "dumb" terminals where all the processing takes place in a single computer such as mainframe or minicomputer. The few previous methods and architectures that allowed users to install PC's utilized "dumb" terminal emulation packages to force the PC's to function as "dumb" terminals, again failing to use the available processing power of the PC. Thus, prior methods and architectures did not allow the user to fully utilize the available PC processing power.

Past and present methods and architectures also did not allow the user to realize the full benefits of using PC based applications that access a database, such as a CRS, directly. Instead, prior art products provided some ability to execute a PC "hand-off" function where the user switches between using the "dumb" terminal emulation package to communicate with the CRS and the PC to perform accounting and reporting functions. Should the user require an integration of the CRS communication with the accounting and reporting functions, however, then an intermediate step is required. Personal productivity and efficiency are much less because intermediate steps must be performed.

While back-office systems for the travel provider have existed for several years, including Agency Data Systems' ADS product; Systems One's Max; World Span's World Ledger 4000 and Travel Data Systems' TDS; each of these systems was implemented on an IBM proprietary AS/400 architecture. Therefore, none of the prior art back-office accounting and reporting systems are easily ported to other architectures or used in connection with other vendor's hardware products. In addition, the travel providers have to depend on the developer of each architecture to do the necessary programming to port existing back-office accounting and reporting systems to new architectures as they are developed.

The present invention, however, provides an integrated "real-time" CRS to back-office system that works on any industry supported architecture and is independent of the particular hardware system used. Thus, the present invention allows travel providers to install various hardware devices not offered by the original architectural vendor. Examples of these hardware devices include printers, workstations, DOS based platforms, DOS based network file servers, and similar devices. The openness and flexibility of the present invention permits travel providers to largely solve their own day-to-day operational and information management needs with minimal dependence for additional programming from the original architectural vendor.

Unlike the prior art methods and architectures, the present invention provides a method and architecture that can distribute reporting functions among available processing resources in a network environment though a batch scheduling system. This provides maximum flexibility to the end user, as each user can now allocate computing power to a given reporting task. Furthermore, the user can designate the most appropriate platform to accomplish a specific reporting task. This feature allows a user who works in a mixed platform environment to maximize the efficiency of each individual platform by allocating it to a suitable task.

Moreover, the batch scheduling system of the present invention enables a high on-line throughput of transactions achieved through a client server system architecture. The client server architecture can operate when application functions are separated logically, and indeed, sometimes physically from the database management functions. Thus, a user can work with a client (the frontend) on his workstation and use resources of the server (the back-end) only when data needs to be accessed. Thus, regardless of the platform on which the database is run, e.g., UNIX, OS/2, Novell Netware, the same client applications can be accessed without any changes.

Furthermore, in the present invention either the client or server can be changed independently of the other. For example, one database can be moved from a vendor's UNIX system to another, or to an emerging environment like Microsoft Windows NT, with no additional programming required for the client applications.

The present invention also provides the ability to process multiple tasks simultaneously not only on the database server, but also on individual workstations. As an example, in one of the preferred embodiments of the present invention, applications are run on an IBM OS/2 operating system and users can execute multiple ad hoc queries, multiple formatted reports, print from third-party software programs, and do accounting data entry all at the same time. In the prior art, these tasks either tied up each workstation reducing productivity or required the submission of an individual executable command to a processor on a minicomputer.

Moreover, the batch scheduling system of the present invention has a preprogrammed reporting capability that allows each workstation to access multiple reports. The user can see the status of a report at any time, still executing, executed or already viewed reports via a video terminal. The user can send one or more copies to a printer, or save it as a file. The user may also create customized versions of each preprogrammed report by developing a template. This template defines the users choice of select criteria and sort field preferences.

In addition to the preprogrammed reporting system, the invention has a report generator system that allows a non-programmer end user to create customized and formatted reports. By merely selecting the columns the user wishes to see, a detailed query is automatically formed that can be executed. The user can specify select criteria, sort fields, request aggregate functions, sums, minimums, maximums, averages, and create customized headers and footers. The present invention then allows users to schedule a task to occur automatically at specific dates and times.

Another aspect of the present invention is to provide a batch scheduling system that allows reports to be distributed among the available network resources. Once jobs are scheduled, they are executed on a user defined platform or groups of platforms attached to the network. The user can define the available resources to be allocated to each reporting task, can group resources to work on a given reporting task, and designate the priority of each task, as well as the time and date at which the task will be performed. Unlike the prior art, this aspect of the invention allows for the processing power of each platform on the network to be used to its fullest even when no actual users are present.

The present invention also ties in perfectly with the current trend of most companies to downsize large mainframe and minicomputer systems to smaller network distributed systems. Thus, the present invention provides numerous advantages over prior data management methods and architectures and eliminates many of the deficiencies therein.

The present invention relates to a new and novel data management method and architecture. In particular, the present invention comprises a centralized host computer having means for mass storage of data and communication means for communicating to one or more central processing units. In one of the preferred embodiments, the centralized host computer is one of several central reservation systems (CRS) such as SABRE System One, Covia, World Span, or any other similar CRS.

In one of the preferred embodiments of the present invention access to all of the various CRS host computers is included. The central host computer or CRS is connected through a communication channel to a client server architecture which receives the data stream from the CRS system and subsequently manipulates the data stream into a predetermined data structure. Typically a UNIX or equivalent based process receives, manipulates, and stores the data stream on the travel provider's back-office platform.

In addition, the client server platform maintains certain accounting and reporting mechanisms. These mechanisms consist primarily of client specific accounting information, programs for organizing the information, database structures which contain the organized information, and programs for communicating with the CRS as well as the travel provider's Local Area Network (LAN) or its equivalent. In addition, the client server platform may contain maintenance utilities such as system backup and diagnostics. The LAN itself is the communication platform for the client and server processes.

In one of the preferred embodiments, the travel provider's platform consists of a LAN which may include any number of attached devices such as mini computers, PC's, dedicated workstations, printers, and similar or equivalent devices. These devices are used for imputing and transmitting data to one or more server processes. The devices are also used by the user to perform "realtime" transactions on the CRS. In addition, these devices are used in connection with the distribution option of the batch scheduling system to process reports as well as other local processing tasks which the client may require. It is at the LAN level that accounting processes such as sales entry, cash functions, accounts receivable, reporting, customer statements, accounts payable, interface, the generation of data files, and customized processes or third-party functions occur.

For a more complete understanding of the present invention and the advantages thereof, reference is now made to the following description in conjunction with the accompanying drawings in which:

FIG. 1 is a representative diagram of one embodiment of the system architecture of the present invention;

FIG. 1A is a representation of various workstation processes of the present invention;

FIG. 1B is a representation of various workstation processes of the present invention;

FIG. 2 is a detailed diagram of one embodiment of the system methodology of the present invention;

FIG. 3 is a flow chart diagram of the batch scheduling system of the presentation;

FIG. 4 is a representative screen showing executable functions of the batch scheduling system;

FIG. 5 is a representative screen showing the scheduling of batch tasks by time, date, and period;

FIG. 6 is a representative screen showing the status of scheduled batch tasks;

FIG. 7 is a representative screen showing the scheduling of a single batch task; and

FIG. 8 is a representative screen showing the editing of batch task.

The present invention relates to a data management method and architecture. FIG. 1 shows an overall system architecture 10 comprising of either a single central host computer or central reservation system (CRS) 20 or a plurality of CRS's 30. In one of the preferred embodiments, the CRS 20 or CRS's 30 are the various travel reservation systems or their equivalent. CRS 20 or CRS's 30 connects to a gateway or communications server 40, or its equivalent. In one of the preferred embodiments, the communications server 40 is a 386-based platform or its equivalent with storage and disk capabilities. The communications server 40 is an attached device on a Local Area Network (LAN) 50 such as the IBM Token Ring Netware operating under an IBM OS/2 Presentation Manager operating system. Equivalent network and operating systems may be used. Communication server 40 may contain an RTIC board from IBM or any other similar communications board. The gateway or communications server 40 connects to the LAN 50. Typically the LAN 50 is an IBM Token Ring operating under standard Novell Netware network software utilizing TCP/IP. Connected to the LAN 50 is a network file server 60. In one of the preferred embodiments, the file Server 60 is typically a 386 or equivalent based platform, with disk and storage capabilities operating on a token ring network and LAN workplace IBM OS/2 Presentation Manager software with SQL Server PC Net-Library. The file server 60 may also contain various application software including third-party software and/or customized software.

Additionally, the system architecture 10 contains at least one client workstation 70 for the input and display of data. It should be readily understood that a plurality of client workstations 70 may also be used without departing from the true spirit of the present invention. The client workstation 70 is a 386 or equivalent based platform with or without disk and storage capabilities running on a Token Ring Network under the IBM OS/2 Presentation Manager operating system. This client workstation 70 is used by the travel provider end user to perform many of the routine accounting functions and client report generating functions, including data entry and reservation services. In one of the preferred embodiments of the present invention, it is within a client workstation 70 that the batch scheduling system and message communications processing takes place.

The client workstation 70 accounting and client report generating functions can be more readily understood with reference to FIG. 1a. Interface 61, which in one of the preferred embodiments is the IBM OS/2 Presentation Manager or a similar or equivalent interface, provides sales entry functions 71 allowing the client a selection of invoicing programs and creation of invoices 73 using data input 72. The client workstation 70 provides cash functions 74 selected from interface 61 and consisting of functions 76 such as receipts, disbursements, adjustments, open item posting, and unpost paid items using data input 75. Client workstation 70 also provides, through interface 61, account receivables functions 77 consisting of functions 79 such as void, transfer, dispute and resolve, queries, as well as creation, modification, deletion and posting a beginning receivable using data input 78.

Referring to FIG. 1b which shows other functions of client workstation 70 reached through interface 61 are customer statement functions 81, which using data input 82, provides functions 83 such as creation of a statement format, statement setup, statement remarks and specification, and processing, printing, and reprocessing of statements. Client workstation 70, through interface 61, also provides accounts payable functions 84, which using data input 85, provides for specific functions 86 such as creation, modification and voids, mailing address entries, distribution across accounts, and a payable status screen. Other functions of the client workstation 70 are hotel and car functions 87 which use data input 88 to provide functions 89 such as building, hotel and car properties, identifying key identifiers, and merging of properties.

Although client workstation 70 functions as herein described and detailed in FIGS. 1a and 1b which are illustrative of the preferred embodiments of the present invention, it must be clearly understood that various other configurations of functions could be utilized that embody the true spirit and scope of the present invention, as described herein.

Attached to the LAN 50 of FIG. 1 is database server 80. In one of the preferred embodiments, the database server 80 is typically a RISC based platform in an UNIX or equivalent operating system in a Token Ring Network with TCP/IP or a 386-based or equivalent platform that has an IBM OS/2 Presentation Manager operating system on the Token Ring with TCP/IP. It is at the database server 80 that the data stream from the CRS 20 or CRS's 30 is parsed, validated, verified, and otherwise manipulated before being accessible on LAN 50.

Typically, a print server 90 is attached to LAN 50, which in one of the preferred embodiments is a 386 based or equivalent platform, with disk capabilities running on the Token Ring Network under the IBM OS/2 Presentation Manager operating system. In addition, print server 90 may have port expansion cards allowing communication to multiple printers 100. Printers 100 are typically Hewlett Packard LaserJet or equivalent type devices capable of printing text and graphics from wordprocessing and reporting applications.

Although system architecture 10 described herein and depicted in FIG. 1 is one of the preferred embodiments, it must clearly be understood that various other configurations, methods and system architectures could be utilized as long as they have the appropriate memory and communication links as those described herein.

Importantly, system architect 10 of the present invention is designed to be highly scalable. It is designed to be utilized in travel companies ranging from relatively small, i.e. less that 2000 ticket transactions per month, up to large global agencies having over 100,000 ticket transactions per month per database server. TABLE 1 contains a general description of examples of the system architecture configurations based on tickets and volumes.

FIG. 2 is a flow diagram of one embodiment of the architecture of the present invention. FIG. 2 illustrates a plurality of the centralized reservation systems (CRS) 32, 34, 36 and 38 that maintain "real time" databases including present availability, fares, city pairs, bookings, destinations, city guides and other travel related information necessary in the travel industry for booking, purchasing, and ticketing passengers for air travel. Other items of travel included in the CRS 32, 34, 36 and 38 include, among other information, hotel fares, car rental fares, cruise directories, and room availability.

Data from the CRS's 30 is sent via communication links 130, 132, 134 and 136 to database server 80 either directly or through a communications server 40 and LAN 50. At database server 80 the data stream is parsed, validated, and otherwise manipulated according to the message types 140, 142, 144 and 146. The data communication lines 130, 132, 134, 136 connect to the accounting and reporting system database 150 where the message is either validated and stored 152 or modified and rejected 154 as an invalid message.

Again, in one of the preferred embodiments, the accounting and reporting system database 150 typically resides in either a UNIX-based or equivalent platform, or a 386 or equivalent based platform, using an IBM OS/2 Presentation Manager operating system platform capable of interaction with LAN 50.

Also shown in FIG. 2 is batch scheduling system 160 which can be more readily understood with reference to FIG. 3 and the description below. The information in the accounting and reporting database system 150 is communicated through batch scheduling process 160 via communication links 162, 164, 166 and 168 to client workstation 70 where end user functions 170, 180, 190, 200, and 210 are performed. End user functions 170 include typical accounting processes 170 such as accounts receivable, accounts payable, general ledger, cash balances and other typical accounting processes. Utilizing batch scheduling system 160, other end user functions 170 include generating preprogrammed reports 180, generating customized reports 190, generating data hand-off files 200, and processing and customization of third-party functions 210, such as E-Mail, employee personnel records, etc..

Batch scheduling system 160 can be more readily understood with reference to FIG. 3. FIG. 3 is a flow diagram of batch scheduling system 160 of the present invention. The batch scheduling system 160 is controlled by the software that resides on database server 80 and network file server 60 of LAN 50 and communicates and transmits data back and forth between the accounting and reporting system database 150 and client workstation 70 utilized by the end user. A source code listing of the representative operational program of the preferred embodiment of the present invention which is utilized in the memory of the processing unit and that operates batch scheduling 160 system is set forth hereafter in TABLE 2. The source code of batch scheduling system 160 is in computer language "C", but it should be clearly understood that other computer languages and varying structure, sequence aid organization of the source code is contemplated within the scope of the present invention. ##SPC1##

Batch scheduling system 160 provides means for generating a variety of customized reports automatically at end-user predetermined times and intervals. Batch scheduling system 160 allows each batch executable filename or program filename to be assigned a program name as further illustrated by the screen shown in FIG. 4. Another feature of batch scheduling system 160 is the ability to edit batches 232 to add, modify, delete or copy jobs within a batch.

Additionally, batch scheduling system 160 gives the user the ability to define executable programs 234 that may be batch processed, i.e. to give the end user the ability to customize reports and decide what parameters should be used and when and where the batches should be processed. An example of this is illustrated in the screen of FIG. 5.

Batch scheduling system 160 provides the end user with the ability to view current batch detail, batch status, and batch history 240 as needed. Feature 240 illustrated in the screen shown in FIG. 6.

Batch scheduling system 160 gives the user the ability to assign available resources to resource groups 238 (used during the batch processing). This allows the end user to decide, if, when and how many of the resources within the enduser facility shall be used for customized report generation and when those resources are going to be occupied. Batch scheduling system 160 also has the ability to add resources 236 to those that are available for batch processing. This gives flexibility to the end-user to either increase or decrease the number of resources utilized in report generation and customization. Features 236 and 238 are also illustrated in the screen of FIGS. 7 and FIG. 8, respectively.

Operation of the batch scheduling system 160 is illustrated at 250, 260, 270, 280 of FIG. 3 with the start of the batch scheduler on either LAN 50 or a single platform attached to LAN 50. Batch scheduling system 160 may execute tasks 260 on the preassigned resources 238 which have been added to the list of resources 236 using the available processing power of LAN 50 to start the scheduled batch process 250. After a job is completed, batch scheduling system 160 then transmits the data along communication line 262 to database server 80. Batch job information is communicated along the line 264 from the accounting and reporting database 150 to the start batch scheduler 250. Two other functions 270 and 280 allow the batch scheduling system 160 to refuse or accept new jobs while the scheduler is running or to stop and start the batch scheduler as necessary. One embodiment of features 270 and 280 is illustrated in the screen of FIG. 7.

Although the invention has been described and illustrated in detail it is clearly understood that the same is by way of illustration and example only. It is not to be taken by way of limitation. The scope of the present invention is to be limited only by the terms of the appending claims.