Patent Application
20060206245
The ability to gather information, which may be performed at a central hub, and distribute it to a network of users is an important business requirement. Distributing the information in an effective manner, and ensuring that the information is correct and complete provides many challenges.
The central hub gathers the information that is disseminated downward to the network of users. The information may be static information that does not change such as historical information, maps, laws and regulations, etc. Other information may be constantly changing such as financial information or weather. The central hub may also be geographically distanced from one or all of the network of users which may further complicate the process. Once gathered, the information is disseminated to the network of users. Each user receives the information and reviews it accordingly. Often times the user prints a hard copy of the information.
One example of a central hub is a strategic operation center used by the airline industry for flight release information. The information may include various necessary details about each flight, such as routing, gate, passenger list, baggage, fuel load, cargo load, hazardous material contents, special passenger requirements, and weather information. This information is created at a strategic operation center that is remotely located from one or more airports in the network.
Prior to each flight, an airline personnel accesses the network and prints a copy of the flight release information. This information is received prior to the flight leaving the airport. Potential issues that have occurred in the past is the ability to print a complete copy of the information, and to ensure that it is updated, particularly with regards to the constantly changing information. Further, the information on the network should be secure such that unauthorized persons do not have access.
Embodiments of the present invention are related to the distribution and subsequent capture of flight release information. At a flight origination location, users may be authorized based on an origination device input. The authorized user may be prompted for a flight specific data item such as a flight number or a destination location, which is validated. If the data item is not validated, the user may be prompted to receive outside assistance. If the data item is validated, the relevant flight information is located and a flight release document containing the relevant flight information is created and printed at the flight origination location. The relevant flight information may be stored in a remote location and may comprise separate data files containing weather information or flight details. The printed flight release document may include a specific page number and a total page count on each printed page of the document. The printed flight release document may also include a cover sheet having a barcode containing metadata related to the flight release document.
At the completion of a flight, and at the flight destination location, a user may be prompted at a destination device for identification. If verified, the flight release document may be received and stored using the destination device. In one embodiment, the flight release document is scanned by the destination device and transmitted to a remote location. Furthermore, if the flight release document comprises a barcode on the flight release document, metadata may be extracted by scanning the barcode. A confirmation may be produced at the flight destination location.
Embodiments of the present invention are directed to the dissemination and retrieval of flight release information in an airline industry network. One example of this type of airline network is indicated generally by the number 10 in
One task of the SOC 12 is to disseminate FAA required flight plans, also known as a Flight Release Packets, to pilots pre-flight. The flight release information contains information such as routing, gate, passenger list, baggage, fuel load, cargo load, haz-mat cargo, special passenger requirements, and weather information. This flight release information is transmitted over a combination of networking systems 36 including the airline's own network and other proprietary networks such as those operated by EDS, Sabre, SITA, and Airlink. Conventional solutions for disseminating flight release information operate on a push architecture where the SOC 12 transmitted the flight release packets to specific printers at a hub 22 or gate 24 at an appropriate airport 26. In contrast with this conventional approach, embodiments disclosed herein permit a pull-type architecture allowing pilots to access the flight release packets on-demand from a variety of locations, including at airport hubs 22, departure gates 24, pilot briefing rooms (not shown), or other suitable secure areas.
The exemplary network architecture 30 shown in
The document distribution server 32 is adapted to access flight release packet information from an SOC file server 20 located at the remote SOC 12 location. The document distribution server 32 may be advantageously located at individual airports 26 accessible by a plurality of multifunction printers 34. The document distribution server 32 may alternatively be located at the SOC 12 or at intermediate locations (not shown). The document distribution server 32 accesses information on the SOC file server over a network 36 such as those described above. In one embodiment, the network 36 is a TCP/IP network and the document distribution server 32 and the flight release packet information is accessible through a secure application via a file transfer protocol (FTP) file sharing scheme. Alternative embodiments may employ other transfer schemes such as secure HTTP or secure shell SSH.
In one embodiment, flight release information is stored on the SOC file server 20 in plain text format ending in a .txt extension. The information may be divided over a plurality of files. For instance, one file may have flight-specific information and may be saved with a file name conforming to the format “flightnumber.data.txt” while a separate file having weather-specific information may be saved to a file having a name conforming to the format “flightnumber.weather.txt.” The document distribution server 32 is adapted to handle a plurality of different file formats so the .txt extension represents one of a plurality of possible formats. For instance the flight release information may be stored on the SOC file server 20 in a compressed format to improve transfer speeds to the document distribution server 32. However, the text format advantageously permits simple parsing and combining of the information contained within the data files. Furthermore, the data files are advantageously updated on a frequent basis to ensure that when the flight release packets are printed, the most up-to-date information is retrieved.
The exemplary architecture shown in
Various other modules 40-42 associated with the document distribution server 32 permit secure and reliable transfer of the flight release packet information from the document distribution server 32 to the multifunction printer 34. Each module 4042 is described below in the context of the procedure followed by users and the processes executed by processing circuitry 35 to access and print the desired flight release packet, which is shown in
Referring to
In the event a badge is not initially recognized, the user may be prompted a predetermined number of times, such as three, to rescan the badge. Once the ID badge is validated at the multifunction printer 34, the user may be prompted for additional information such as a flight number (Step 310), a password, or other relevant information. Once all information is input (Step 312) and verified (Step 314), the document distribution server 32 locates the relevant flight release data files (Step 316) and weather files (Step 318) on the SOC file server 20, parses the information within the data files using a parse module 41 and extracts the data for compilation into a single report. More specifically, the document distribution server 32 extracts flight number, date, origin, and destination information from predefined locations or coordinates contained within the data files and merges the data and weather files to a single file (Step 320) that is delivered to the multifunction printer 34 (Step 322).
In addition, the document distribution server 32, having a knowledge of the total number of pages contained in the merged document, inserts page information and flight information as a header or footer on each page of the merged document. Furthermore, the page number information includes a total number of pages so that the page number appears in the form “Page X of Y” where X is the current page number and Y is the total number of pages in the document. With the flight number and page count information included on each page, users can be sure that they have a complete document upon retrieving the flight release from multifunction printer 34.
The document distribution server 32 also compiles a cover sheet (part of Step 320) to the beginning of the merged flight release document that contains identifying information such as the flight number, date, origin, and destination information. In addition, the cover sheet contains a two-dimensional barcode created with the aid of barcode module 40 that comprises the same flight number, date, origin and destination information. In one embodiment, the barcode confirms to a PDF417 standard, though other standards such as RSS, Aztec, or Code 128 may be used as well. The barcode on the cover sheet of the flight release is used after the flight is completed and the user returns the flight release information into the system. Conventionally, pilots or other users hand delivered a signed copy of the flight release upon their return to a central hub or the SOC. With the embodiments disclosed herein, users are able to submit a signed flight release upon landing at the destination.
The exemplary network architecture 50 shown in
Referring to
The proximity device 46 is a sensor adapted to recognize authorized user ID badges by sensing a predetermined RF signature. The proximity device 46 is advantageously coupled to a serial data port on the multifunction device 34. Alternatively, the proximity device 46 may be coupled to a client workstation in the vicinity of the multifunction device 34. Alternative security devices may be incorporated to verify user identification. For example, biometric devices, magnetic card readers, and optical laser scanners all provide alternative recognition devices capable of providing a similar security function.
A user interface panel 44 permits user interaction with the multifunction device 34 and provides access to the various functions described herein.
Those skilled in the art should appreciate that the multifunction device 34 and servers 32, 20, 52 shown in the Figures for implementing the present invention may comprise hardware, software, or any combination thereof. For example, processing circuitry 35 for prompting a user for identification may be a separate hardware circuit, or may be included as part of other processing hardware. More advantageously, however, the processing circuitry 35 in the multifunction device 34 or servers 32, 20, 52 is at least partially implemented via stored computer program instructions for execution by one or more computer devices, such as microprocessors, Digital Signal Processors (DSPs), ASICs or other digital processing circuits included in the devices 32, 34, 20, 52. The stored program instructions may be stored in electrical, magnetic, or optical memory devices, such ROM and RAM modules, flash memory, hard disk drives, magnetic disc drives, optical disc drives and other storage media known in the art.
The present invention may be carried out in other specific ways than those herein set forth without departing from the scope and essential characteristics of the invention. For instance, the embodiments described have been depicted in use with an LCD touch screen 70 on a user interface panel 44 of a multifunction device 34 to access the desired functions. Other embodiments may assign the desired functions to existing buttons of a keypad on a user interface panel. It is also possible to initiate the desired functionality via a menu tree that is viewable on a limited text display and accessed using keys and buttons on the interface panel. Still another possibility is the use of LCD touch screen that is not physically a part of the multifunction device, but that is still in communication with the multifunction device. The present embodiments are, therefore, to be considered in all respects as illustrative and not restrictive, and all changes coming within the meaning and equivalency range of the appended claims are intended to be embraced therein.
