Patent Application
20080215406
This document describes a transportation operations computing system that includes a suite of software applications.
Sophisticated computing systems are needed to manage the operations of an airline. Airline operation computing systems exist that enable aircraft and crew planning, day-to-day operations management and reporting. In addition, airline operation computing systems exist that enable airlines to manage flight crews, equipment and passengers affected by service disruptions, such as weather or mechanical delays.
Typical airline operation systems are complex and are required to manage massive amounts of data. In addition, these systems are used in scenarios where the operations being managed can change very quickly, due to weather or mechanical delays. As such, the systems need to be easy to use, and allow decision making to be made very quickly.
Generally, there is provided an airline operations computing system with graphical user interface features that enable users to plan and conduct airline operations effectively and time efficiently, and in addition, to do so in the face of disruptions due to weather, sick crew members, aircraft in need of repair, and the like.
In one aspect, a computer-implemented method is provided for scheduling a resource to a scheduled airline flight. The method includes receiving a user selection of a flight pairing for which a resource is to be scheduled or changed. The method also includes filtering data files for resources to identify resources that are possible candidates to be scheduled for the selected flight pairing. The method further includes receiving a user input that associates a visual display of the selected flight pairing with a visual display of a selected candidate resource. The method includes also updating a resource schedule to indicate that the selected candidate resource is scheduled for the flight pairing.
In various implementations, the method may include one or more of the following optional features. The resources being assigned may be flight crew resources, aircraft resources, etc. The user input that associates the selected flight pairing with the selected candidate resource may a drag-and-drop action that drags the visual display of the flight pairing and drops the dragged visual display on the visual display of the selected candidate resource. Alternatively or additionally, the user input that associates the selected flight pairing with the selected candidate resource is a drag-and-drop action that drags the visual display of the selected resource and drops the dragged visual display on the visual display of the selected flight pairing.
In addition, the filtering of data files may include filtering by availability and identifying those resources that are available to be assigned to the flight pairing. The method may also include sorting the candidate resources identified through filtering, for example, by seniority.
Computer program products are also provided to carry out the above described methods of scheduling a resource to a scheduled airline flight. Such computer program products are tangibly embodied in computer storage medium and comprise instructions that when executed by a processor cause operations to be performed that carry out the above-described methods to schedule a resource to a scheduled airline flight. In addition, computing systems are provided that are programmed to carry out the above described methods to schedule a resource to a scheduled airline flight.
In another aspect, aspect, a user interface for managing operations of an airline or other similar carrier is provided. In particular, there is provided a computer program product tangibly embodied in computer storage medium and which comprises instructions that when executed by a processor generate a user interface display for managing operations of an airline.
The user interface includes a listing area and a schedule area. In the listing area there is listed at least one flight pairing that comprises a series of one or more flights, and at least one resource assigned to at least one of the listed at least one flight pairing. In the schedule display area there is displayed on a common timeline: a) for each listed pairing, a pairing schedule provided in relation to the common timeline, the pairing schedule including flight schedule details for each flight included in the listed pairing, and also including timing information for each such flight included in the listed pairing, which timing information is displayed in relation to the common timeline, and b) for each listed resource, a resource schedule provided in relation to the common timeline, the resource schedule including flight schedule details for each flight to which the resource is assigned, the resource schedule also including timing information for each such flight to which the resource is assigned, which timing information is displayed in relation to the common timeline.
In various implementations one or more of the following optional features may be included in relation to the user interface. The user interface display may further include a candidate resource area in which resources are displayed that can be assigned to a selected pairing included in the listing area. The schedule display area may include a timeline. The resource schedule may include assigned flights from at least two different pairings, with at least one of the at least two different pairings being listed in the listing area in association with the resource. The at least one resource listed in the listing area may be crewmember resources. The at least one resource listed in the listing area may be aircraft resources.
Further features and advantages may be understood with reference to the figures and the following description.
Like numbers in different figures indicate like structures or processes.
In the
The airline operations client tier 102 includes a display device 110, an airline operations client application 112, a web browser 114, and a set of custom applications 116. The display device 110 may be the monitor of a computer, the screen of a portable device, the display of a mobile device, or other visual output device, by way of a few examples. The display device 110 provides a visual output for the airline operations client application 112, the web browser 113, and the set of custom applications 116.
The airline operations client application 112 includes number of software modules. In the
The planning and scheduling module 118 presents a user interface that may be used to display flight pairings, and to fill or make changes to such pairings. A pairing refers to a data structure for a specified flight or series of flights, in which data structure a resource such as a crewmember may be associated with the flight or series of flights. If a resource has not been assigned to the specified flight or series of flights, the pairing for that flight or series of flights may be referred to as an open pairing. The term pairing may also, depending on the context, refer to the actual association between a resource and the flight or series of flights, as in there is a pairing of a particular resource and a particular flight or series of flights. Also, a single flight or a series of multiple flights may be grouped together and referred to as a duty. Such a grouping may be created because it may have been deemed desirable to have a single resource assigned for the duty. In such a case, there may be a pairing for the grouped series of flights that constitute a duty.
The planning and scheduling module 118 presents a user interface that may be used to fill an open pairing by assigning a resource such as a flight crew member to it, and also to change a resource assignment for a pairing. This association between a resource and a specified flight or series of flight may be performed using a drag-and-drop operation. For example, the user may drag-and-drop a visual representation of a particular flight crewmember onto a visual representation of a scheduled flight or series of flights constituting a duty, or vice-versa, to associate the crewmember with the scheduled flight or series of flights. The same may be done, in some implementations, to associate other types of resources, such as a particular aircraft, with the flight or series of flights. In addition, there may be different groupings of flights for purposes of crew resources, as opposed to aircraft resources for example. In another example, the user may drag-and-drop a visual representation of a flight crewmember to a scheduled flight, or vice-versa, thereby associating the crewmember with the scheduled flight.
The planning and scheduling module 118 also may provide a visual indication that a pairing is being edited. For example, when a first user has selected and is operating an instance of the module 118 to edit a particular pairing (e.g., changing the pilot that is assigned to the pairing), the pairing may appear highlighted on the display device 110 to indicate that the pairing contains proposed changes that have not yet been committed so as to effect the proposed changes to the actual schedule. This may be useful, for example, if the user's attention is drawn away from the display device, and the user wants to be able to quickly determine the pairing for which the user was performing a scheduling action. In addition, another user using a different display device may be viewing the same pairing from another instance of the module 118, and in this case the pairing may be visually highlighted to indicate that the pairing is being edited by another user. This may be particularly useful in a scenario where there are multiple or even numerous schedulers, and a user may want to know whether or not someone else is performing a scheduling operation that would affect a pairing that the user is viewing.
The planning and scheduling module 118 may further provide a visual indication that a pairing assignment or a proposed change to a pairing assignment violates a predefined rule stored in a rules database. For example, a pilot may be assigned to a flight that will cause the pilot to exceed the number of hours a pilot may fly between rest periods. The planning and scheduling module 118 may cause an indicator to be displayed in association with the pairing, flight, or resource to indicate that the pairing violates one or more rules. Examples of rules may be guidelines based upon airline policy, union rules, airline regulatory organization (e.g., United States Federal Aviation Administration, FAA) rules, and other sources of rules and policies that may effect how flight resources are scheduled.
In some embodiments, a single indicator may be provided on a display to indicate the existence of one or more rule violations, be it one rule violation or multiple rule violations. In other embodiments, multiple indicators may be provided with each indicator indicating a different rule violation. In addition or alternatively, there may be multiple different appearance types for rule warnings, which appearance would indicate the nature or type of rule violation. For example, a pairing that may cause a non-critical rule warning (e.g., an overly large airplane being assigned to flight with few passengers) may be displayed with a “non-critical” warning icon. In another example, a pairing that may cause a pilot to break a law or flight regulation (e.g., flying too many hours without a rest period) may be displayed with a “critical” warning icon.
In some embodiments, multiple warning indicators may be used until a rule warning indicator limit is reached. For example, the planning and scheduling module 118 may display up to four individual indicators to indicate up to four rule violation warnings, but five or more rule warnings may be represented by another style of warning indicator. In the current example, five or more warnings may be indicated by a single icon that indicates the actual number of warnings, by four icons and an ellipsis, or by some other visual means to indicate multiple rule warnings.
The system 100 has an architecture, design and software functionality that enables the checking of proposed schedule changes to occur substantially in real-time. For example, the system 100 enables a user to edit a pairing and submit the proposed changes (but not commit them), and the system 100 will then check the edited pairing for rule violations before the changes are committed to the database. If the system 100 determines that the proposed pairing changes violate any of the rules, then the system 100 may indicate to the user any rule violation warnings that may have been generated, as described previously. The user may then choose to resolve any violations that may exist by making further changes (which also may be checked for rule violations in substantial real time), or leave the violations unresolved. The system 100 may, for example, provide rule violations relatively instantaneously on a display screen as a user is working on a pairing. After the user is satisfied with the schedule changes, the user may provide an input that commits the schedule changes. This may be done despite that there are rule violations, or in some cases, the user may have made further changes that resolved any intermediate changes that created one or more rule violations.
The day of operations and recovery module 120 provides general functionality for the day of operations management, as well as functionality for handling any daily disruptions. For example, the day of operations and recovery module 120 may provide functions that help the user reassign flight crews if a crewmember is unexpectedly absent from work, or if there are weather problems that disrupt flight operations. In another example, if an aircraft that is scheduled to a flight is grounded (e.g., needs unexpected repairs), then the module 120 may provide functions that help the user reassign aircraft to the scheduled flights.
The administration module 122 provides functionality for a user to edit airline resource information, security settings, rules parameters, or other administrative tasks. For example, an airline regulation that prohibits pilots from flying more than twelve hours without a rest period may be changed to a maximum of ten hours, and the administration module may allow the user to edit the rule parameter for maximum flight time to reflect the updated regulation.
The client services module 124 provides an applications programming interface (API) that handles one or more types of communications between the airline operations client tier 102 and the airline operations application tier 106. For example, the client services module 124 may encapsulate transmission control protocol/internet protocol (TCP/IP) messages, package user datagram protocol (UDP) datagrams, wrap web services messages, or manage other communications formats and protocols.
The web browser 114 is an application that provides a user with a means for interacting with hypertext markup language (HTML) pages and web applications. Examples of the web browser 114 may include Internet Explorer, available from Microsoft Corporation, Netscape Navigator, available from Netscape Communications and Weblogs, Inc., Firefox, available from Mozilla Corporation, and Opera Web Browser, available from Opera Software ASA.
The set of custom applications 116 may perform may provide a variety of different functions that are specific or unique to a particular airline. In many cases, there are standard software functions that apply generally to any airline and that will be delivered by a software vendor to an airline, and in addition, there may be additional custom applications that are either unique to a particular airline and/or provided by another vendor.
The airline operations network tier 104 in the
In some embodiments, the client services module 134 of the web server 128 may be substantially the same as the client services module 124 of the airline operations client application 112. In some implementations, the web server client services module 134 may provide an API that may be used by the web application module 130 and the web service module 132 to communicate with the airline operations application tier 106.
The web service module 132 provides functions of a protocol bridge between the custom applications 116 and the airline operations application tier 106. For example, the web service module 132 may use Service Oriented Architecture Protocol (SOAP) messages use of an Internet application layer protocol as a transport protocol to communicate with the custom applications 116 over a network (e.g., the Internet).
In some implementations, the web service module 132 may receive SOAP messages from the custom applications 116, parse the SOAP messages, and use the client services module 134 to act as a bridge between the custom applications 116 and the airline operations application tier 106. In some implementations, the web service module 132 may translate data from the airline operations application tier 106 and the client services module 134, wrap the data as a SOAP message, and send the SOAP message to the custom applications 116. For example, the client services 116 may use an Internet connection and the web service module 132 to request and retrieve various types of airline operations data from the airline operations application tier 106.
The airline operations application tier 106 includes an airline operation server application 136. The airline operation server application 136 includes various modules that perform functions for the planning and scheduling of airline flight resources. Some of these modules include a planning module 138 (for long-term staffing of flight crews), a scheduling module 140 (for the production of pairings and rosters), day-of-operations module 142 (for day of operations management and recovery functions), a rules module 144, a pairing module 146, and a rostering module 148.
The airline operations sever application 136 also includes an access services module 150 and a data access module 152 to facilitate communication with the airline operations client application 112 (either directly or via the web server 128) and with the airline operations database tier 108. The access services module 150 communicates with the client services modules 124 and 134 of, respectively, the client application 112 and the web server 128. In some implementations, the access services module 150 may coordinate communications between the client services modules 124 and 134, and the server application modules 138-148. For example, an airline operations client application 112 may request that the airline operation server application 136 make a change to a flight resource. The access services module 150 may receive this request and respond by invoking functions of the scheduling module 140 and the rules module 144 to update a schedule and check for any rules violations that the change may cause.
The application tier's data access module 152 provides an API to handle tasks associated with database communications. In some implementations, the server application modules 138-148 may use the data access module 152 to create, update, and delete data contained in the airline operations database tier 108. For example, the data access module 152 may handle the tasks of opening and closing database connections, transaction processing, caching, and other tasks generally associated with database communications.
The planning module 138 provides functions that allow users to perform various tasks related to crew resource planning, for example, long-term staffing functions. For example, the module may allow users to plan for flight and reserve requirements, absence requests, training requirements, and other tasks that deal with airline resource planning. In some implementations, the planning module 138 may provide decision support and forecasting functions. For example, the module 138 may help users create efficient resource plans by compiling information to anticipate and correct resource surpluses and shortfalls.
The scheduling module 140 provides functions for airline scheduling tasks Airline scheduling may include, for example, the production of pairings and rosters, and the scheduling module 140 may build the pairings and build the rosters.
The day of operations module 142 provides functionality to manage generally the day of operations, which may include functionality for users to handle daily disruptions. For example, the module 142 may help users reassign flight crews if a crewmember is unexpectedly absent from work, or if there are weather problems that disrupt flight operations. In another example, if an aircraft that is scheduled to a flight is grounded (e.g., needs unexpected repairs), then the module 142 may provide functions that help the user reassign aircraft to the scheduled flights.
The rules module 144 performs functions that determine whether various airline operational rules have been violated. Examples of these rules-checking functions may include determining if a schedule will cause a pilot to fly more hours than is allowed by law or by policy, determining if a flight crew member assigned to a flight is qualified to work on the type of airplane that is assigned to the flight, determining if a proposed schedule provides insufficient time between flights for a flight crew member to move between airplanes, determining whether a schedule will cause an airplane to exceed a limit on the number of flight hours between maintenance operations, or other various rules and policies that may affect flights and flight resources. For example, if a pairing causes an aircraft to fly in excess of an allowable number of hours between service checks, the module 144 may detect this rule violation.
The pairing module 146 provides functionality for users to edit pairings. For example, a pairing is a sequence of flight legs in which crewmembers are paired with flights that start at a crew base or originating airport, and end at the same crew base. The pairing module 146 provides functions for users to add, remove, change, or perform other functions that associate flight resources with pairings.
The rostering module 148 provides functions that generate and manage crew rosters. For example, the rostering module 148 may help users determine work schedules according to various fairness criteria, such as by crew preferences, by seniority, or by other factors that may be used to generate crew rosters. In some implementations, rostering functionality may be included in the scheduling module 140.
The airline operations database tier 108, in the
In some implementations, the data in the OLTP database 154 may be partly or wholly copied to the ODS database 156. For example, data in the OLTP database 154 may be replicated or mirrored to the ODS database 156. The ODS database 156 may integrate data from multiple sources (e.g., one or more tables within one or more databases) to facilitate operations, analysis, and reporting. For example, the ODS database 156 may be configured for online analytical processing (OLAP). In some implementations, the ODS database 156 may be structured and configured differently than the OLTP database 154. For example, database tunings and structures for OLTP operations may not work well for OLAP operations, and by using separate databases for OLTP and OLAP operations, the OLTP database 154 may be structured and tuned as needed for OLTP operations and the ODS database 156 may be structured and tuned to OLAP operations.
The airline operations client applications 160a and 160b each perform functions for their respective users to do airline resource planning and scheduling, for example. In some embodiments, the airline operations client applications 160a and 160b may each be implementations of the airline operations client application 112 of
The airline operations client applications 160a and 160b each includes a planning and scheduling module 166a and 166b, and a client services module 168a and 168b. In some embodiments, the planning and scheduling modules 166a and 166b may be the planning and scheduling module 118 of
The client services modules 168a and 168b each provides an applications programming interface (API) that handles one or more types of communications between the airline operations client applications 160a and 160b and the airline operations server application 136. In some embodiments, the client services modules 168a and 168b may be the client services module 124 shown in
The schedule database 162 may include tables of airline operations data. The schedule database 162, in the
The rules database 164 includes airline operations rules. For example, the rules module 144 may include a rule that checks to determine if a pilot has flown more than “N” hours in an “M” hour period. The values for “N” and “M” may be stored in the rules database and queried by the rules module 144 to define the number of hours a pilot may fly in a certain period.
In some embodiments, the rules module 144 may perform functions for a user to edit rule parameters in the rules database 164. For example, the rules database may include parameters that reflect an airline policy, such as a ratio of flight hours to training hours. The rules database may store a value of “1000” to define this ratio, but this ratio may need to be changed (e.g., airline policy change, pilot union contract change, FAA regulations change) to a value of “900.” The rules module 144 may provide functions for a user to update the ratio or other rule parameters stored in the rules database 164.
In various implementations, airline schedules may be planned to comply with various rules. These rules may implemented to reflect various laws, regulations, policies, and other such guidelines that may be put forth by governments, regulatory agencies (e.g., the Federal Aviation Administration, FAA), unions, corporations, or other entities. Rules may be implemented in computer code, such as in the code of the rules module 144. In some implementations, rules may contain parameters (e.g., variables) that may permit quantitative or other types of parameters that may be stored elsewhere (e.g., the rules database 164). The rules engine 144 may obtain the specific values of rule parameters by loading the rule parameters from storage. By storing the specific values of rule parameters separately from the computer code that defines the rules, the rules may be adjusted without requiring edits to the computer code of the rules engine 144. In some implementations, rules may be edited by using a computer implemented method and user interface.
As will be described in more detail later, a process or method is provided by which rule checking is performed in a very immediate or “real-time” manner, such that a user who is in the process of making edits to a schedule is provided nearly instantaneous feedback on a display device if a proposed change violates any of many rules that may need to be followed with the schedule. Such a rule-checking and display process may be performed even before the proposed changes are actually “committed” to the schedule, or in other words, before the scheduling user enters into the system that a set of proposed changes will be made to the schedule. Such a rule-checking and display method is particularly useful in the context of an airline operations system in which there may be many rules that apply to scheduling. Some of those rules will be mandatory, and thus must be followed, whereas others may be guidelines or preferences that may be ignored in some cases. Before turning to the rule checking process, there will first be a discussion of the rules database, and how the rules database and parameters for the rules may be updated or edited.
The method 200 begins with step 206 wherein the client application 202 generates a request that schedule information or data be retrieved from a database where that information is stored. This may be initiated, for example, by a user providing an input to a user entry device at a client device, which input is a request to display schedule information on a display device associated with the client device. The server application 204 receives the request and responds in step 208 by sending the requested schedule data to the requesting client application 202. The schedule data may include, for example, information about various flights and series or flights, and resource assignments for those flights and series of flights, if any.
Next, at step 210, the client application 202 generates a visual display of the schedule data on a display device (e.g., the display 110 of
When a user has selected a particular pairing at the client application 202, a message or notification of that selection is sent, at step 214, to the server application 204. In response, at step 216, the server application 204 retrieves and filters data files of resources to identify the resources that can be scheduled for the pairing. For example, the server application 204 may filter resources based on resource availability, authorization, qualifications, training, or other criteria that may be used to filter a collection of airline resources. In addition, the server application 204 may also prioritize the resources that can be scheduled for the flight or series of flights. This may be accomplished by step 218 that involves a sorting of the filtered resources. For example, at step 218 the collection may be sorted by alphanumeric order, by seniority, hours worked, or by other attributes that may be used to sort a collection of airline resources.
Next, at step 220, the collection of filtered and sorted resources is sent to the client application 202, where visual representations of the resources are displayed on the client display device. The retrieval and display of resources may be initiated, in some embodiments, immediately by a user selecting of a pairing. In other embodiments, the retrieval and display of resources may not be initiated until a user selects that the resources that can be scheduled for a pairing be displayed. For example, and as will be shown later by illustration, a graphical user interface (GUI) may include a series of selectable tabs that are each associated with a different resource type (flight crewmember, aircraft etc.), and the retrieval and display of the resources of a particular type may not be initiated until the corresponding resource type tab is selected.
At this point, the visual display includes both visual representations of one or more flights or series of flights (with perhaps the selected flights or series of flights highlighted in some way) and visual representations of resources that can be scheduled for the selected flight or series of flights. Using this visual display and an appropriate user input device such as a mouse or keyboard, a user associates, at step 222, a flight or series of flights (that is, a pairing) with a particular resource. For example, a user may drag-and-drop a visual representation of a particular aircraft shown in a filtered aircraft resource collection to a visual representation of a pairing, or vice-versa. This associates the aircraft with the pairing. In another example, a pairing may be dragged-and-dropped onto a crewmember's name in a filtered crewmember resource collection, or vice-versa, to associate the pairing and the crewmember.
In response to the association having been made, a message or notification of the user's association between the pairing and the resource is sent from the client application 202 to the server application 204, at step 224. In response, at step 226, the server application 204 updates the collection of available resources and schedule data to reflect the association between the pairing and the airline resource. The association may be a proposed one for which the user is not yet committed. In addition, the user may commit the proposed schedule change to effect an actual change in the schedule. This may be done, for example, by the user providing at the client application 202 an input, perhaps guided by the visual display, that is indicative of such a commit of a proposed schedule change.
Now referring to
The display 300 includes a large area in which a Gantt chart display is provided of various scheduled flights. In the
In the
At the left-hand side of the
Turning now to the next screen snapshot 300 shown in
As opposed to dragging a resource to a scheduled flight to make the association, alternatively a flight may be dragged to a resource. For example, in the display 300, the user may be able to drag a visual representation of the captain pairing 310 to a name in the collection of available flight crewmembers 325 to associate the pairing with the crewmember.
Referring now to
It may be desirable to split the first series 410 from the second series 415 so as to create two pairings from a single pairing. This may be done, for example, by a user entering a command to split a displayed pairing at a particular point in time within the pairing. For example, a user may navigate a pointing device to location 420 and enter a right click operation on the pointing device to provide a display of options, one of which may be a “split” operation. As such, the pairing L2015 may be split at that selected point. Such a “split” operation would produce the user interface display 400 shown in
Referring now to
Pairing J2018 in the
The memory 620 stores information within the system 600. In one implementation, the memory 620 is a computer-readable medium. In one implementation, the memory 620 is a volatile memory unit. In another implementation, the memory 620 is a non-volatile memory unit.
The storage device 630 is capable of providing mass storage for the system 600. In one implementation, the storage device 630 is a computer-readable medium. In various different implementations, the storage device 630 may be a floppy disk device, a hard disk device, an optical disk device, or a tape device.
The input/output device 640 provides input/output operations for the system 600. In one implementation, the input/output device 640 includes a keyboard and/or pointing device. In another implementation, the input/output device 640 includes a display unit for displaying graphical user interfaces.
The features described can be implemented in digital electronic circuitry, or in computer hardware, firmware, software, or in combinations of them. The apparatus can be implemented in a computer program product tangibly embodied in an information carrier, e.g., in a machine-readable storage device or in a propagated signal, for execution by a programmable processor; and method steps can be performed by a programmable processor executing a program of instructions to perform functions of the described implementations by operating on input data and generating output. The described features can be implemented advantageously in one or more computer programs that are executable on a programmable system including at least one programmable processor coupled to receive data and instructions from, and to transmit data and instructions to, a data storage system, at least one input device, and at least one output device. A computer program is a set of instructions that can be used, directly or indirectly, in a computer to perform a certain activity or bring about a certain result. A computer program can be written in any form of programming language, including compiled or interpreted languages, and it can be deployed in any form, including as a stand-alone program or as a module, component, subroutine, or other unit suitable for use in a computing environment.
Suitable processors for the execution of a program of instructions include, by way of example, both general and special purpose microprocessors, and the sole processor or one of multiple processors of any kind of computer. Generally, a processor will receive instructions and data from a read-only memory or a random access memory or both. The essential elements of a computer are a processor for executing instructions and one or more memories for storing instructions and data. Generally, a computer will also include, or be operatively coupled to communicate with, one or more mass storage devices for storing data files; such devices include magnetic disks, such as internal hard disks and removable disks; magneto-optical disks; and optical disks. Storage devices suitable for tangibly embodying computer program instructions and data include all forms of non-volatile memory, including by way of example semiconductor memory devices, such as EPROM, EEPROM, and flash memory devices; magnetic disks such as internal hard disks and removable disks; magneto-optical disks; and CD-ROM and DVD-ROM disks. The processor and the memory can be supplemented by, or incorporated in, ASICs (application-specific integrated circuits).
To provide for interaction with a user, the features can be implemented on a computer having a display device such as a CRT (cathode ray tube) or LCD (liquid crystal display) monitor for displaying information to the user and a keyboard and a pointing device such as a mouse or a trackball by which the user can provide input to the computer.
The features can be implemented in a computer system that includes a back-end component, such as a data server, or that includes a middleware component, such as an application server or an Internet server, or that includes a front-end component, such as a client computer having a graphical user interface or an Internet browser, or any combination of them. The components of the system can be connected by any form or medium of digital data communication such as a communication network. Examples of communication networks include, e.g., a LAN, a WAN, and the computers and networks forming the Internet.
The computer system can include clients and servers. A client and server are generally remote from each other and typically interact through a network, such as the described one. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other.
Although the embodiments described above have been described in terms of airline operations, embodiments for other purposes are possible. For example, the systems described may be modified to schedule and associate crews and equipment for land transportation (e.g., rail, busses, taxis, limousines, trucks), watercraft (e.g., ships, ferries), aircraft, spacecraft, industrial equipment (e.g., fishing trawlers, oil rigs), construction equipment, mining equipment, military equipment (e.g., tanks, patrol vehicles, reconnaissance vehicles), or other types of operations where a schedule of crews or operators may be associated with a vehicle or other machine. The described systems may also be modified for use in scenarios that do not necessarily include a vehicle. For example, the systems described may be modified for use by a travel agency to schedule and associate tour guides, tourists, tour stops, hotels, restaurants, transportation, or other items that may be associated with a tour package.
Although a few implementations have been described in detail above, other modifications are possible. For example, the logic flows depicted in the figures do not require the particular order shown, or sequential order, to achieve desirable results. In addition, other steps may be provided, or steps may be eliminated, from the described flows, and other components may be added to, or removed from, the described systems. Accordingly, other implementations are within the scope of the following claims.
This application claims priority from U.S. Provisional Application Ser. No. 60/892,405, filed Mar. 1, 2007, the contents of which are incorporated herein by reference.
| Number | Date | Country | |
|---|---|---|---|
| 60892405 | Mar 2007 | US |
