EP1305732A2 - Method, computer system and computer system network - Google Patents
Method, computer system and computer system networkInfo
- Publication number
- EP1305732A2 EP1305732A2 EP01947640A EP01947640A EP1305732A2 EP 1305732 A2 EP1305732 A2 EP 1305732A2 EP 01947640 A EP01947640 A EP 01947640A EP 01947640 A EP01947640 A EP 01947640A EP 1305732 A2 EP1305732 A2 EP 1305732A2
- Authority
- EP
- European Patent Office
- Prior art keywords
- booking
- allotment
- transport
- forwarder
- data
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Withdrawn
Links
Classifications
-
- G—PHYSICS
- G08—SIGNALLING
- G08G—TRAFFIC CONTROL SYSTEMS
- G08G5/00—Traffic control systems for aircraft, e.g. air-traffic control [ATC]
- G08G5/0095—Aspects of air-traffic control not provided for in the other subgroups of this main group
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q10/00—Administration; Management
- G06Q10/08—Logistics, e.g. warehousing, loading or distribution; Inventory or stock management
-
- G—PHYSICS
- G08—SIGNALLING
- G08G—TRAFFIC CONTROL SYSTEMS
- G08G1/00—Traffic control systems for road vehicles
- G08G1/20—Monitoring the location of vehicles belonging to a group, e.g. fleet of vehicles, countable or determined number of vehicles
- G08G1/202—Dispatching vehicles on the basis of a location, e.g. taxi dispatching
-
- G—PHYSICS
- G08—SIGNALLING
- G08G—TRAFFIC CONTROL SYSTEMS
- G08G1/00—Traffic control systems for road vehicles
- G08G1/123—Traffic control systems for road vehicles indicating the position of vehicles, e.g. scheduled vehicles; Managing passenger vehicles circulating according to a fixed timetable, e.g. buses, trains, trams
Definitions
- the present invention relates to a method, computer system and computer system network configured for providing a centralised register of booking agreements in a transport system.
- the present invention relates to providing a centralised register of booking agreements in an air cargo transport system.
- the freight transport industry is typically highly fragmented.
- air freight transport industry carriers airlines
- forwarders air freight/cargo capacity brokers
- forwarders tend to block book cargo capacity up to 6 months in advance, such booking often being an overbooking which may result in a significant number of "no-shows" for the carrier.
- ad hoc bookings may be made to make up for any shortfall in a forwarder's cargo capacity needs.
- ad hoc bookings are also inefficient since it is necessary for a forwarder, or forwarder's agent, to contact many carriers individually, by telephone, fax or e-mail, for example, in order to obtain information on capacity availability and price. Very often, further information such as the type of cargo a carrier is able to carry over a certain route will be required, together with the type of packaging required.
- EDI Electronic Data Interchange
- carriers and forwarders typically operate under established EDI conventions and protocols, different versions, data and data structures are utilised. Thus inter-working and high levels of integration are inhibited.
- EDI is a generic term for one-to-one communication between systems, which relate to just one carrier. Due to the inherent sequential and asynchronous nature of messaging via EDI, there is no single and current database of flight, capacity availability and rating information that can be addressed electronically via a single query. This inhibits the utilisation of such EDI systems within individual carriers and forwarders. Furthermore, the conventions are often rigid International standards and so are difficult to change. In one-to one EDI systems, a request for information has to be sent to each individual carrier's EDI system.
- a specific query or request for information has to be made, conforming to a format used by a respective EDI system.
- the request must be in the appropriate format for each EDI system wliich may require reformatting of a request for submission to different systems. This takes significant time and effort on behalf of a user.
- different EDI systems support different information, so that not all EDI systems can answer the same query, or provide the required information.
- tariff rate changes can only be distributed slowly, even when distributed via fax or e-mail, since they are not available via a central system.
- a yet further drawback is that results from different carrier EDIs cannot be viewed at the same time.
- the response from different EDI systems is asynchronous, since they are independent of each other. Thus a user is inhibited from assessing the information as a whole, which makes optimum selection of available services difficult.
- EDI systems were originally intended for the electronic exchange of data and to avoid manual input of data, they have degraded into mere messaging systems, and do not provide for the efficient interchange of information.
- the lack of automated integrated information management systems provides a barrier to the optimisation of routing options and route management, by for example, taking into account aircraft type with regard to capacity and cargo type for a particular route.
- forwarders or carriers may initiate a negotiation to define a reservation of capacity and an associated rate.
- the negotiation and initial agreement may be defined loosely - e.g. a number of tonnes per month from a station to a region (LHR-West Coast USA) - or more specifically - e.g. a number of tonnes between a specific origin and destination, on specified flights, on specified days of the week, over a period.
- Terms used to identify this type of agreement include "reserved capacity", “permanent bookings", “gentlemen's agreements”, “allocations” and "allotments”.
- the carrier manages the reserved capacity, either through central capacity management systems that maintain logical partitions for each agreed allotment, or locally where manual checks are required before booking into larger, less specific logical partitions in the cenfral system (e.g. where the carrier outstation itself has reserved capacity).
- the agreements are frequently maintained independently by each side, with no written contract existing and no shared information repository.
- Single organisations may maintain records locally, with little or no organisation- wide or central view of contractual and verbal agreements. Records and contractual performance, when monitored, are monitored independently by each party.
- the process for booking reserved capacity varies regionally and by organisation in terms of timing and data exchanged. Many forwarders send a bulk list of bookings 2-6 weeks in advance, which uses the full allotment capacity as the default weight/volume/number and type of units. These bookings are manually queued by the carrier until the flight is opened for booking. In these cases, amendments may be made to the initial bookings over time to release allotment capacity, or secure extra capacity, depending on whether forecasted capacity usage exceeds or falls short of the allotment.
- the process often involves faxing a bulk list of bookings to each carrier, with amendments communicated by fax or telephone.
- the manual queuing system and a lack of formalised procedure can result in errors including lost and out of sequence bookings.
- Forwarders and carrier typically interact for allotment bookings using traditional communications channels such as telephone, fax and post. Manual processes are required: to ensure buyer and seller allotment records correspond to one another; to ensure that buyers have allotment agreements in place when booking, and that the bookings do not use more capacity than has been reserved; for buyers to submit bookings to multiple sellers; to provide available information to prompt buyers to advise sellers if capacity is not going to be utilised; and to queue and register bookings when submitted by the buyer before the seller has opened flights to booking.
- carrier systems support a level of capacity partition management.
- the partitions are frequently at a less granular level than forwarder location, and typically manage capacity at the level of carrier station for each flight leg. Manual intervention is required to ensure that the carrier station partitions are used to fulfil the allotment agreements, and are reserved for the holders of such agreements.
- the present invention seeks to provide a computer system, a method for configuring a computer system and a network inco ⁇ orating such a computer system, that addresses, and preferably mitigates, at least one of the problems associated with the foregoing described allotments systems. Further problems and drawbacks associated with known systems will become apparent from the following description and drawings, together with further aspects of the present invention. Particular and preferred aspects of the invention are set out hi the accompanying independent and dependent claims. Combinations of features from the dependent claims may be combined with features of the independent claims as appropriate and not merely as explicitly set out in the claims.
- a method of configuring a computer system including a processing unit, an interface unit for communication with said processing unit and a memory unit, for providing a centralised register of transport provider permanent booking agreements between a plurality of transport providers and a plurality of forwarders, the booking agreements relating to available capacity on routes between stations in a transport system, the method comprising: receiving one or more transport provider allotment templates from a plurality of transport providers, each allotment template comprising template data representing a permanent booking agreement between a transport provider and a forwarder, the template data comprising data representative of one or more route leg instances and data representative of an agreement capacity value for at least one of said one or more route leg instances; storing a record of said allotment templates in the memory unit; and providing access to said record to a plurality of forwarders such that each forwarder can view at least part of the template data of each allotment template which represents a permanent booking agreement between the forwarder and one or more transport providers, but not the template
- a computer system for providing a centralised register of transport provider permanent booking agreements between a plurality of transport providers and a plurality of forwarders, the booking agreements relating to available capacity on routes between stations in a transport system, comprising a processing unit; an interface unit for communication with said processing unit; and a memory unit; the computer system configured to: receive one or more transport provider allotment templates from a plurality of fransport providers, each allotment template comprising template data representing a permanent booking agreement between a transport provider and a forwarder, the template data comprising data representative of one or more route leg instances and data representative of an agreement capacity value for at least one of said one or more route leg instances; store a record of said allotment templates in the memory unit; and provide access to said record to a plurality of forwarders such that each forwarder can view at least part of the template data of each allotment template which represents a permanent booking agreement between the forwarder and one or more transport providers, but not the template data of
- a method for operating a computer system including a processing unit, an interface unit for communication with said processing unit and a memory unit, for providing a centralised register of transport provider permanent booking agreements between a plurality of transport providers and a plurality of forwarders, the booking agreements relating to available capacity on routes between stations in a transport system, wherein a record of one or more transport provider allotment templates from a plurality of transport providers is stored in the memory unit, each allotment template comprising template data representing a permanent booking agreement between a transport provider and a forwarder, the template data comprising data representative of one or more route leg instances and data representative " of an agreement capacity value for at least one of said one or more route leg instances, the method comprising: providing access to said record to a plurality of forwarders such that each forwarder can view at least part of the template data of each allotment template which represents a permanent booking agreement between the forwarder and one or more transport providers, but not the template data of allotment templates
- a computer system for providing a centralised register of transport provider permanent booking agreements between a plurality of transport providers and a plurality of forwarders, the booking agreements relating to available capacity on routes between stations in a fransport system
- the computer system comprising: a processing unit; an interface unit for communication with said processing unit; and a memory unit; wherein a record of one or more transport provider allotment templates from a plurality of transport providers is stored in the memory unit, each allotment template comprising template data representing a permanent booking agreement between a transport provider and a forwarder, the template data comprising data of one or more route leg instances and data representative of an agreement capacity value for at least one of said one or more route leg instances, the computer system configured to: provide access to said record to a plurality of forwarders such that each forwarder can view at least part of the template data of each allotment template which represents a permanent booking agreement between the forwarder and one or more transport providers, but not the template data of allot
- An advantage of an embodiment in accordance with the first, second, third or fourth aspect of the invention is that transport providers can create, amend and delete templates defining permanent booking agreements with named forwarders. Since a centralised record of templates of a plurality of transport providers can be stored, forwarders can view templates details of permanent booking agreements between themselves and more than transport provider. Further, the transport provider and forwarder can each access a shared record of the permanent booking agreements and view the agreement on-line.
- an event summary is sent to a forwarder to inform the forwarder that a fransport provider has created , amended or deleted an allotment template.
- the forwarder is kept informed of any such changes.
- the system is configured to receive one or more forwarder allotment bookings from one of a plurality of forwarders, each allotment booking comprising booking data and relating to a permanent booking agreement between the forwarder and a transport provider, the booking data comprising data representative of a transport provider and one or more route leg instances.
- a plurality of transport provider modalities may be provided, so one transport provider may be sent a message by e-mail or facsimile and another may be sent a message in a data format such as XML or Cargo-IMP. Messages may be sent by MQSeries, SMTP, FTP, Type B or HTTP.
- the booking data may be simply passed on to the fransport provider together with an indication of who the forwarder is.
- the record is searched to find an allotment template corresponding to the allotment booking, and a booking request is constructed from the booking data and corresponding template data in a data format of the transport provider.
- forwarders can create and amend bookings within allotments.
- a single transaction can create or amend a plurality of bookings.
- only a minimum amount of data is required to make bookings where there is an allotment template and, in accordance with an embodiment of the present invention, a booking request is constructed from the template data and sent to the transport provider.
- the forwarder can include booking requests for transport providers who have not loaded templates onto the system, and these allotment bookings are forwarded to the transport provider.
- all forwarder bookings can be managed through a common set of functions.
- an operational window record for a fransport provider is stored in the memory unit.
- This operational window defines a time period before departure in which the fransport provider opens the flight for bookings. If the flight is not yet open for bookings then the booking is queued until the flight is opened and then automatically submitted electronically.
- a requested booking capacity exceeds the agreement capacity the booking request is stored as an in-review booking request for the transport provider to review and approve or refuse.
- the transport provider can check the in-review bookings from time to time or in response to a message informing them that one or a certain number of booking requests are awaiting their review.
- This system avoids overloading the fransport provider system with requests which exceed capacity and saves time and increases efficiency by flagging and grouping these bookings.
- a fransport provider can define an acceptable excess booking tolerance and, provided the booking capacity is within this tolerance a booking request for capacity exceeding the agreement capacity can be automatically accepted without the fransport provider's direct approval. The forwarder can not however distinguish between excess bookings which have been approved through these two different channels.
- a milestone plan is associated with an allotment template.
- the milestone plan associates at least one pre-journey milestone one or more route leg instances.
- the milestone may represent a reminder, an aspect of a contract, or a deadline for booking creations, amendments or cancellations.
- Users i.e. forwarders or transport providers
- automatic messages relating to milestones may be generated.
- transport providers to register contractual milestones and their terms, or non-contractual reminders against allotments is provided.
- transport providers and forwarders to search and view bookings in relation to milestones is also provided. This ability is also provided by the fifth, sixth, seventh and eighth aspects of the invention.
- a fifth aspect of the present invention provides a method of configuring a computer system including a processing unit, an interface unit for communication with said processing unit and a memory unit, wherein a cenfralised register of bookings is stored in the memory unit, each booking arranged between one of a plurality of fransport providers and one of a plurality of forwarders and relating to booked capacity on a route between stations in a transport system, the method comprising: associating a milestone plan with one or more of the bookings, the milestone plan associating at least one pre-journey milestone with the booking; and allowing a forwarder or transport provider to view said at least one milestone associated with one or more bookings.
- a sixth aspect of the invention provides a computer system comprising a processing unit; an interface unit for communication with said processing unit; and a memory unit; wherein a centralised register of bookings is stored in the memory unit, each booking arranged between one of a plurality of transport providers and one of a plurality of forwarders and relating to booked capacity on a route between stations in a transport system, the computer system configured to: associate a milestone plan with one or more of the bookings, the milestone plan associating at least one pre-journey milestone with the booking; and allow a forwarder or fransport provider to view said at least one milestone associated with one or more bookings.
- a seventh aspect of the invention provides a method of operating a computer system including a processing unit, an interface unit for communication with said processing unit and a memory unit, wherein a centralised register of bookings is stored in the memory unit, each booking arranged between one of a plurality of transport providers and one of a plurality of forwarders and relating to booked capacity on a route between stations in a transport system, one or more of the bookings having an associated milestone plan associating at least one pre-journey milestone with the booking, the method comprising: allowing a forwarder or transport provider to view said at least one milestone associated with one or more bookings.
- An eighth aspect of the invention provides a computer system comprising: a processing unit; an interface unit for communication with said processing unit; and a memory unit; wherein a centralised register of bookings is stored in the memory unit, each boolcing arranged between one of a plurality of transport providers and one of a plurality of forwarders and relating to booked capacity on a route between stations in a transport system, one or more of the bookings having an associated milestone plan associating at least one pre-journey milestone with the booking, the computer system configured to: allow a forwarder or transport provider to view said at least one milestone associated with one or more bookings.
- aspects of the present invention support the following: a shared record of allotment agreements accessible centrally and locally by each transacting party; the ability for the buyer to make allotment bookings electronically in bulk and view the status of bookings for all sellers and all booking types in a single screen; the ability for the seller to view the status of bookings for all buyers and all booking types in a single screen; the ability to submit bookings to be queued until flights are opened and then automatically submitted electronically; electronic audit of booking transactions (creations, amendments, deletions), related to key booking milestones; a shared record of booking transactions in relation to key booking milestones; and a shared record of allotment utilisation, relative to bookings.
- Embodiments in accordance with the present invention effect efficient management of allotments and bookings against allotments.
- the risk of error is significantly reduced, not least because the requirement for significant manual input is removed.
- embodiments in accordance with the invention effect a standardised approach between different carriers and forwarders.
- embodiments make the information required to enforce obligations readily available for routine enforcement of contractual obligations. Consequently more innovative and efficient contracts can be taken up since the flexibility to adapt to new requirements is available.
- a particularly suitable implementation in which the present invention may be utilised comprises a method of configuring a computer system including a processing unit, an interface unit for communication with said processing unit and a memory unit, for providing an integrated representation of routes in a transport system comprising a multiplicity of connectable stations, the routes being derived from data from a plurality of transport providers, the method comprising: storing a short term schedule of individual instances of route legs, each route leg corresponding to a directly connectable station pair; and deriving a route segment table comprising one or more route segments, each route segment corresponding to an individual instance of said route legs, or a combination of individual instances of said route legs, from said short term schedule.
- a particularly suitable example of a system in which the present invention may be utilised comprises a computer system for providing an integrated representation of routes in a transport system comprising a multiplicity of connectable stations, the routes being derived from data from a plurality of transport providers, comprising: a processing unit; an interface unit for communication with said processing unit; and a memory unit; the computer system configured: to store a short term schedule of individual instances of said route legs, each route leg corresponding to a directly connectable station pair; and to derive a route segment table each route segment corresponding to an individual instance of said route legs, or a combination of individual instances of said route legs, from said short term schedule.
- the route segment table provides a representation of possible routes within a transport system, derived from data from a plurality of transport providers in an integrated form. Since each route is defined as an instance of a route leg or combination of instances of route legs, routes are defined for a particular time i.e. instance. Each route comprising a combination of individual route leg instances preferably consists of route legs which are associated with the same transport service, such as the same vehicle or route number.
- Preferably data representative of attributes of the route legs is stored in the route segment table .
- the attributes may include a conveyance capacity associated with each segment.
- a user can search the table and establish the availability of routes and preferably associated attributes quickly and efficiently without the transport provider being consulted first. That is to say, the computer system provides a service quite different to a simple broker system where a user request would be sent to each of the transport providers, each returning a response with the responses then being communicated to the user.
- deriving the route segment table means user searches can be handled quickly and efficiently in real time. Without the route segment table, laborious searches would have to be made through a multiplicity of data tables.
- the route segment table includes an origin and destination pair for each route segment.
- the origin and destination pair correspond to the origin and destination stations for that individual route leg.
- the origin and destination pair for each route segment comprises the origin station of the first route leg of the route segment and the destination station of the last route leg of the route segment.
- Transport providers may provide long term schedules specifying the route legs for a whole season, such as in a train time table for instance. Alternatively transport providers may provide short term schedules specifying the actual instances (operational schedule) of route legs.
- the system is configured to handle schedule data in either form. Scheduling may be for flight routes, truck routes or routes relating to other vehicles used in the transport system.
- the system may be configured to receive and update data from the transport providers.
- the system may be further configured to initiate and send an update request message to the fransport provider as a data update poll.
- the entries in tables in the memory unit of the system are kept up-to-date.
- Another particularly suitable implementation in which the present invention may be utilised comprises a method for configuring a computer system including a processing unit, an interface unit for communication with said processing unit and a memory unit, for automatically generating route options for a transport system including a plurality of transport providers and including a multiplicity of connectable stations, wherein: said memory unit comprises a route segment table including one or more route segments corresponding to an individual instance of a route leg, or a combination of individual instances of route legs, each said route leg corresponding to a directly connectable station pair of said transport system; said method comprising generating one or more route options responsive to a route search request specifying a journey having an origin and destination station pair, each route option comprising a route segment having an origin and destination station pair specified in said route search request and selected from said route segment table; and storing said one or more route options in a segment set list in said memory unit.
- a computer system for automatically generating route options for a transport system including a multiplicity of connectable stations and a plurality of transport providers
- the computer system including: a processing unit; an interface unit for communication with said processing unit; and a memory unit comprising a route segment table including one or more route segments corresponding to an individual instance of a route leg, or a combination of individual instances of route legs, each said route leg corresponding to a directly connectable station pair of said transport system; the computer system configured to: receive a route search request specifying a journey having an origin and destination pair; generate one or more route options responsive to said route search request, each route option comprising a route segment having an origin and destination station pair specified in said route search request; and store said one or more route options in a segment set list in said memory unit.
- the journeys may be specified by way of stations corresponding to specific transport depots, for example in an air transport system stations may correspond to afrports.
- journeys may be specified by way of a region such as a city associated with one or more stations.
- Information relating to different aspects of a transport system may be automatically combined to create a list of one or more route options meeting the journey origin and destination stations and other route search request criteria originating from a potential user of the transport system, e.g. a forwarder.
- the transport system data is divided up into route segments, each route segment corresponding to an origin station and destination station pair which are preferably connected by the use of a single vehicle. That is to say, in a journey between the origin and destination stations of a route segment the same vehicle is used, and there is no transfer of cargo from one vehicle to another vehicle within the journey.
- the route segments are derived from individual, or a combination of individual, route legs. Each route leg corresponds to an origin and destination pair which are directly connectable or consecutive origin/destination station pairs. That is to say, a route leg has no intermediate stations between the origin and destination stations.
- a route segment comprising a combination of route legs has an origin station corresponding to a first route leg in the combination, and a destination station corresponding to the last route leg in the combination.
- an operator of a transport system may modify available route legs by creating new ones or deleting old ones which can then immediately be used in the creation of routing options, without having to modify all possible routing options utilising such new or old route legs station pairs in accordance with the changes.
- old or unprofitable routes can easily be deleted, and new routes added.
- an origin and destination station pair for a requested journey are compared with a route table comprising permissible origin/destination station pairs, in order to determine a permissible routing option.
- Checking the list of routing options against a list of permissible routes provides a carrier (a transport provider), e.g. an airline, with the ability to set up permissible routes which they wish to market and against which requested journey origin and destination station pairs may be automatically checked.
- a carrier e.g. an airline
- the route table is used when deriving the route segment table, so that route segments are only created for routes which are permissible.
- this reduces the size of the route segment table and required storage space, consequently increasing search speeds.
- the permissible route options may then be referred back to the originator of the route search request e.g. a forwarder, to allow them to view the list and decide which routing option most meets their requirements.
- one or more consecutive route legs define a route segment.
- a route segment comprises route legs which have some form of association with each other.
- the same vehicle may be used throughout the segment or in an air cargo system, the route legs making up the route segment may be part of the same flight.
- route legs are only combined to form route segments in the route segment table if the route legs have the same route identifier, for example the same flight number.
- two or more route segments of the route segment table may be concatenated to form a route option having an origin and destination station pair which correspond to the route search request.
- a route segment table which has an attribute associated with each route segment, only route segments which each satisfy the route search request are concatenated. For example, if a search request specifies particular cargo dimensions or a particular container for holding loose cargo (a unitised loading device), only segments which have an associated compatibility entry specifying that the dimensions or unitised loading device are compatible with the leg will be returned.
- the memory unit stores a transfer set table comprising a plurality of transfer set records, each associated with an origin and destination station pair.
- Each transfer set record includes one or more entries representative of one or more permissible transfer point stations between route segments for a route between an associated origin and destination station pair.
- the transfer set table may be linked to the route table such that the transfer set records are each associated with a permissible route.
- a carrier may limit the transfers and the transfer stations in accordance with the facilities that the carrier has at that transfer station for the transfer of cargo between vehicles.
- the cargo comprises some form of fragility, such as perishable cargo (e.g. fruit and vegetables).
- a carrier having a transfer station without suitable refrigeration units may wish to restrict the transfer of such perishable cargo at stations which do not have such refrigeration facilities.
- the transfer set table may be used together with the route table when deriving the route segment table, again reducing the size of the route segment table and increasing search speeds.
- the route search request includes a parameter representative of a maximum number of transfer points in a route between the origin/destination pair to derive routing options which comprise no more transfer points than the maximum number.
- a user of the transport system may specify in advance the maximum number of transfer points they wish to have in any of the routing options created for them. This gives the forwarder the opportunity to request a search for routing options which can take account of the nature of the forwarder's intended cargo. That is to say, if a forwarder is wishing to purchase conveyance capacity for a fragile cargo, they may wish to avoid transfer points, or keep them to a minimum number, in order to reduce the likelihood of damage to the cargo and loss through theft by reducing the number of transfers between vehicles.
- Structuring the information in this way provides a high degree of flexibility for creating route leg and segment combinations to meet search request criteria.
- a route search request can include a parameter representative of an attribute such that one or more routing options may be derived wherein the origin and destination pair are associated with the attribute.
- the forwarder may request origin and destination station pairs for which the routes will have certain attributes, for example departure time and arrival time for a journey between the origin and destination station pair and conveyance capacity, for example.
- Separate tables are set up comprising one or more attributes of the transport system and which are used when deriving the segment set list.
- An operator of a transport system for example a carrier, may then modify respective attribute tables to reflect the services they wish to offer, without having to modify a large table such as the segment set table. This reduces the complexity and processing necessary for updating the data tables.
- a client computer system configured for remote communication with a computer system as described in the foregoing paragraphs.
- the client computer system comprises: a processing unit; an interface unit for communication with said processing unit; a memory unit; and a display means for displaying information to a user of said client computer system; said processing unit comprising a user interface mechanism configured to receive user input data via said interface unit from said user, and to communicate said data to said computer system for processing thereby.
- the user input data may be transport provider template data, a forwarder search request, a transport provider search request, forwarder booking data, a transport provider or forwarder milestone search request.
- the data may represent template data or booking data for one or more templates or bookings respectively.
- a particularly suitable example of a client system in which the present invention may be utilised comprises a user interface mechanism configured to provide a graphical representation of the route segment set list, the user interface mechanism being operable to display on a display means a plurality of route options including origin and destination station, departure date, arrival date, available conveyance capacity and price for conveyance arranged in a logical grouping, the user interface mechanism being responsive to a user input to select a displayed route option and to record a user booking of at least a portion of a conveyance capacity of the selected route option.
- a tenth aspect of the present invention provides a computer system network comprising a plurality of client computer systems and a computer system as described in the foregoing paragraphs.
- Figure 1 schematically illustrates the geographic distribution of ai ⁇ orts in an air transport system
- Figure 2 schematically illustrates an example of a forwarder's cargo booking architecture
- Figure 3 schematically illustrates the logical location of a data management system suitable for implementing an embodiment of the present invention
- Figure 4 schematically illustrates functional aspects and relationships of a data management system in which an embodiment of the present invention may be inco ⁇ orated;
- Figure 5 schematically illustrates details of a database structure for a data management system in which an embodiment of the present invention may be inco ⁇ orated;
- Figure 6 is a relationship diagram for establishing a flight segment table
- Figure 7 schematically illustrates a maximum connection timetable
- Figure 8 schematically illustrates a minimum connection timetable
- Figure 9 is a relationship diagram for a carrier marketed route options table and a transfer points table
- Figure 10 is a flow diagram for the creation of a flight segment table
- Figure 11 schematically illustrates a network coupled data management system in which an embodiment of the present invention may be inco ⁇ orated
- Figure 12 schematically illustrates the logical architecture of a data management system in which an embodiment of the present invention may be inco ⁇ orated
- Figure 13 schematically illustrates the physical architecture of a data management system in which an embodiment of the present invention may be inco ⁇ orated
- Figure 14 schematically illusfrates a computer system workstation
- Figure 15 schematically illustrates an example of a search for capacity user interface screen
- Figure 16 is a flow diagram for a dmPerformSearch stored procedure implementable with an embodiment of the invention.
- Figure 17 is a flow diagram for a dmFltLegSet stored procedure implementable with an embodiment of the invention.
- Figure 18 is a flow diagram for a Carrier Search function implementable with an embodiment of the invention.
- Figure 19 is a flow diagram for a Unitised Search function implementable with an embodiment of the invention.
- Figure 20 schematically illusfrates the architecture of a data management system in which an embodiment of the present invention may be inco ⁇ orated;
- Figure 21 illustrates the relationship between allotment templates and allotment bookings in an embodiment in accordance with the present invention
- Figure 22 schematically illustrates an example of a maintain allotments templates user interface screen of an embodiment in accordance with the present invention
- Figure 23 is a flow diagram for an allotment template record validation function in accordance with an embodiment of the present invention.
- Figure 24 schematically illusfrates an example of an allotment templates outcome user interface screen of an embodiment in accordance with the present invention
- Figure 25 schematically illusfrates an example of a correct allotment template errors user interface screen of an embodiment in accordance with the present invention
- Figure 26 schematically illustrates an example of a search for allotment templates user interface screen of an embodiment in accordance with the present invention
- Figure 27 schematically illustrates an example of an allotment templates search results user interface screen of an embodiment in accordance with the present invention
- Figure 28 is a flow diagram for an allotment template check function in accordance with an embodiment of the present invention.
- Figure 29 schematically illustrates an example of a maintain allotment booldngs user interface screen of an embodiment in accordance with the present invention
- Figure 30 schematically illustrates an example of an allotment bookings maintenance outcome user interface screen of an embodiment in accordance with the present invention
- Figure 31 schematically illustrates an example of a correct allotment bookings error user interface screen of an embodiment in accordance with the present invention
- Figure 32 is a flow diagram for an allotment booking check function in accordance with an embodiment of the present invention.
- Figure 33 schematically illustrates an example of a booking management search results user interface screen of an embodiment in accordance with the present invention
- Figure 34 schematically illustrates an example of an allotment booking e- mail/facsimile attachment of an embodiment in accordance with the present invention
- Figure 35 is a flow diagram for an allotment e-mail decision function in accordance with an embodiment of the present invention.
- Figure 36 schematically illustrates an example of a search for bookings user interface screen of an embodiment in accordance with the present invention
- Figure 37 schematically illustrates an example of a bookings search results user interface screen of an embodiment in accordance with the present invention
- Figure 38 schematically illustrates an example of an allotment usage summary user interface screen of an embodiment in accordance with the present invention
- Figure 39 schematically illustrates an example of an allotment usage by date user interface screen of an embodiment in accordance with the present invention.
- Figure 40 schematically illustrates an example of allotment usage by milestone user interface screen of an embodiment in accordance with the present invention
- Figure 41 schematically illustrates an example of a milestone plan user interface screen of an embodiment in accordance with the present invention
- Figure 42 schematically illustrates an example of an allotment booking template user interface screen of an embodiment in accordance with the present invention
- Figure 43 illustrates an allotment template data model
- Figure 44 illustrates an allotment booking template model.
- the transport system is an air transport system in which the connectable stations are ai ⁇ orts.
- the ai ⁇ orts are geographically distributed substantially as shown in Figure 1 and are referred to using the International Air Transport Association (IATA) codes.
- IATA International Air Transport Association
- airlines provide flights between ai ⁇ orts thereby connecting stations within the transport system.
- a direct connection between two consecutive ai ⁇ orts is termed a flight leg, referenced 10 in Figure 1.
- Flight legs represent the lowest level of connection within an air transport system and may be considered to comprise a "wheels up-wheels down" sequence.
- a single flight leg or combination of flight legs forming part of the same flight, e.g. having the same flight number, are termed flight segments, referenced 12 in Figure 1.
- flight segments referenced 12 in Figure 1.
- reference 12 is placed in brackets indicating that the single flight leg forms a part of a flight segment.
- a flight segment is bounded by transfer points but may include any number of stopovers and even different aircraft.
- a route between London Gatwick (LGW) and John F Kennedy (JFK) ai ⁇ orts shown in Figure 1 includes a stopover, for re-fuelling and/or on-load or off-load of cargo, at Manchester (MAN) ai ⁇ ort. Additionally, there are connections between LGW and MAN, and MAN and JFK. Each connection, LGW/MAN and MAN/JFK is a flight segment.
- the route between LGW and JFK is also a flight segment and comprises flight legs LGW/MAN and MAN/JFK.
- Freight on flight segment LGW/MAN may connect with the flight segment LGW/JFK at MAN, thereby using flight leg MAN/JFK of flight segment LGW/JFK to complete a route between LGW and JFK.
- ai ⁇ orts may be connected by road or rail.
- a truck may be booked to transport cargo from Zurich (ZUR) to Geneva (GVE) for transferring onto a flight to another ai ⁇ ort, if no suitable flight is available into Geneva ai ⁇ ort.
- ZUR Zurich
- GVE Geneva
- airlines often operate primarily within geographic areas and do not offer service between all ai ⁇ orts. Restrictions are generally due to the service locations of the aircraft for a particular airline, as well as market and business plans of the airline. In particular, many airlines are state-owned, controlled or strongly linked with the state, which often restricts the operation of the airline.
- Carriers provide air cargo capacity within aircraft. In general, they do not interface directly with shippers wishing to have cargo transported (or the receivers of air cargo), but distribute cargo capacity via freight forwarders who function as their agents or brokers.
- Carriers may be divided up into three main types.
- the first type includes carriers who provide both passenger and cargo service.
- the air cargo service comprises the excess belly-hold space on passenger aircraft, although there are a number of passenger airlines that operate dedicated freighter aircraft. Some of these passenger airlines also operate so-called "combis" that have some of the main-deck seats of the passenger cabin removed in order to give additional cargo capacity.
- a second type of carrier is the cargo only carrier.
- These are carriers dedicated to the transportation of cargo through the operation of an all-freighter fleet and comprise freight operator companies such as CargoLux and Polar. In most cases, the carriers operate regular or semi-regular services and distribute their cargo capacity through freight forwarders. In some cases, the freighter operators will offer specially arranged or charter flights on an as-needed basis.
- a third type of carrier is the so-called "private label" carrier.
- Such carriers for example Atlas, promote the outsourcing of freighters by operating aircraft on behalf of other carriers who contract for the full freighter including the pilot.
- the private label carriers will sub-divide an aircraft on behalf of two or more conventional carriers.
- Freight forwarders are brokers of air cargo capacity in the sense that they principally buy capacity on behalf of shippers, and manage the logistics and customer documentation on behalf of the shippers.
- forwarders do not own their own aircraft, and where they do they may be considered to be integrators, as described later.
- forwarder industry is highly fragmented with in excess of 10,000 such undertakings throughout the world. Indeed, there are estimated to be around 1000 forwarders in the UK alone. Although forwarders are generally multi-modal in that they ship via sea, road and rail in addition to air cargo, a very significant proportion of their activities and resources are directed to the air cargo market.
- Integrators own their own aircraft and interface with customers through an extensive retail/ground network to provide the forwarder function.
- the four main players are currently Fedex, UPS, DHL and TNT, who represent a vertical integration of the airline and forwarder functions.
- Hubs are the main entrances or portals to the air transport system and are distributed throughout the main territories of the air transport system.
- cargo is transhipped between aircraft at hubs.
- a hub is usually a carrier base, where the carrier's operational equipment is stored, maintained and serviced.
- Forwarders generally have their infrastructure based around one or more hubs.
- the gateway 42 is controlled and managed by a combination of a carrier route manager 44 and a forwarder gateway manager.
- the carrier route manager receives cargo capacity requests from a forwarder gateway manager who in turn receives cargo capacity requests from respective forwarder branches 46, who have been contacted by a sales person 48 to provide cargo capacity on behalf of a shipper 50, or direct from a shipper.
- requests for cargo capacity made to the carrier route manager from the forwarder gateway manager are made via telephone, fax or e-mail.
- an individual sales person 48 or a branch 46, is provided with cargo capacity targets for sale to shippers.
- the forwarder gateway manager seeks to balance the cargo capacity requirements with the capacity he has pre-booked or can negotiate with the carriers. Separate cargo packages from shippers are consolidated at gateway 42 for onward carriage.
- the branch or salesperson consolidates shipments before passing them onto the forwarder gateway manager.
- the forwarder gateway manager is responsible for negotiating and managing consolidated bookings and regular bookings on a given route or set of routes. They negotiate with the carrier route manager to ensure that adequate cargo capacity has been booked to meet the forwarder organisations consolidation, general cargo or ad hoc requirements.
- the forwarder gateway manager negotiates by fax, telephone or e-mail with a carrier sales person 52 or the carrier route manager in order to manage the cargo capacity requirements on a daily, weekly, basis, etc, as appropriate.
- the carrier may operate a telephone call centre.
- This can be a substantial challenge, since there can be differences in the daily (including hourly), weekly and seasonal demand for air cargo capacity. Such differences are driven by consumer and industrial buying patterns, shipper manufacturing configurations, scheduling and shipping approaches, such as back consolidation or just in time shipping. For example, even a relatively minor breakdown at a manufacturing facility of a shipper with substantial volume on a given route can create a backlog of goods and throw the market into imbalance for weeks.
- the demand variances are also complicated by global macro- economic trends such as GDP growth, foreign exchange rates and labour rates which can have a significant impact on the directional focus of any given route and by micro- economic conditions such as labour strikes.
- the forwarder gateway manager makes two types of bookings, permanent and ad hoc bookings.
- Permanent bookings are long-standing bookings of six months or more allocation of cargo capacity on a given flight.
- Ad hoc bookings as their name suggests, are made at the time they are required. They exist outside of the permanent bookings arrangement.
- the permanent bookings may have different rates in accordance with various factors such as day, month, nature of cargo, route, capacity etc.
- the forwarder gateway manager utilises the forwarder computer legacy system to analyse the record of all permanent bookings made with the various carriers. The gateway manager then seeks to balance all the difference cargo capacity requirements originating from the branches to best utilise the available permanent booking. Any excess requirement on any particular route would then be achieved by ad hoc bookings.
- the permanent bookings are made by negotiation with the carrier sales 52, although are generally based upon long-standing expectations and commitments. What is more complex, are the ad hoc bookings in which a forwarder gateway manager has to contact a number of carrier sales 52 in order to determine what cargo capacity over what routes and at what price are available to fulfil the ad hoc requirement. Currently, this is achieved by virtue of telephone calls, fax transmissions and, sometimes, electronic mail.
- the forwarder gateway manager has to contact an individual carrier sales person 52 to determine available cargo capacity to meet the ad hoc requirement for that carrier.
- the forwarder gateway manager has to contact each carrier sales person 52, for each carrier operating at the hub in order to determine what cargo capacity is available.
- the forwarder gateway manager then has to analyse all the information to determine with which carrier to book the ad hoc capacity.
- it is often the case that the forwarder gateway manager is unable to get an immediate answer from the carrier sales as to available cargo capacity since the carrier sales would have to conduct their own investigations within the carrier to determine what is currently available. This may occur with many of the carriers with sales persons with whom the route manager has requested ad hoc capacity. This introduces a significant latency in the information available to the forwarder gateway manager, and makes the booking of appropriate cargo capacity extremely difficult.
- the forwarder gateway manager consolidates the shipments in terms of permanent bookings and ad hoc bookings from the branches at the gateway 42 and transfers the individual house airway bills (HAWB) for each shipment onto a master airway bill (MAWB) pre-allocated by the carrier.
- the forwarder gateway route manager also organises and manages shipments into Unit Load Devices (ULD) for transfer to the carrier or may merely provide loose or bulk shipments which will be packaged and unitised by the carrier themselves.
- ULDs are containers for holding loose cargo. They are of three main types: containers which are enclosures with or without lids; pallets; or igloos which sit on top of a pallet and restrict or constrain the volume of cargo supported by the pallet.
- Forwarders may not have contractual penalties applicable for the permanent bookings that they maintain with carriers. As such, there may be no incentive or penalty if the forwarder is a "no-show", or ships less than was booked.
- the forwarder gateway manager may also alert the carriers sales 52 when a permanent booking or allocation made on behalf of the forwarder is unlikely to be used. When negotiating with the carrier sales 52, the forwarder gateway manager will often haggle over the rates for a particular shipment.
- the existing forwarder/carrier interface is very difficult to manage since a plurality of negotiations are necessary and there is a significant latency within those negotiations. Furthermore, there is a low visibility of the availability of cargo capacity and currently there is no electronic or automated integration between the forwarder systems and the carrier legacy systems.
- the forwarder gateway manager has to await confirmation of the booking by typically a fax back communication which provides proof to the shipper that a booking for their shipment has been made.
- the airway bill is then utilised on the basis of this booking and fixed to the shipment.
- individual airway bills are appended to a master airway bill 54 for the combined booking made by the forwarder with the carrier.
- the carrier sales 52 or route manager 44 labour under significant limitations as to data availability on air cargo capacity within their carrier.
- the carrier sales 52 and route manager 44 wish to optimise the revenue obtained from their cargo business which would typically require a high level of flexibility in rates and type of cargo in order to fully utilise the capacity.
- the carrier sales 52 and route manager 44 just know the weight available on a particular route at any particular moment. This substantially limits the service that they can provide to the carrier.
- Data management system (DMS) 70 is provided between the carriers sales 52 or route manager 44 and the forwarder (typically the forwarder gateway manager), as illustrated in Figure 3.
- the DMS 70 provides an interface between the carrier sales 52 and the forwarder 40 in order to enhance the nature of the transactions conducted between them.
- the DMS 70 provides up-to-date, on-line scheduling, including cargo capacity.
- a quote market is available in which buyers of capacity can view data about the price at which a carrier will make capacity available to them to meet their requirements, for example by route, shipment type, weight and cargo type.
- such a DMS system is capable of performing complex searches in order to enable forwarders to input a desired origin/destination ai ⁇ ort pair and a range of search criteria, such as preferred vehicle types, cargo type and shipment type, and then search and display a list of carrier options to meet these criteria.
- search criteria such as preferred vehicle types, cargo type and shipment type
- search and display a list of carrier options to meet these criteria search and display a list of carrier options to meet these criteria.
- the display order may be determined by the customer's prioritisation of search criteria (e.g. by placing a priority on preferred carrier relationships, lowest rate, earliest departure or latest arrival).
- Such prioritisation may be by way of a parameter pre-set by a forwarder, or input at the time of searching.
- a reverse market or auction may be conducted by virtue of the DMS 70, in which prospective buyers of capacity can place a request for a quote to a selected set of carriers.
- an auction market may be provided where prospective sellers of capacity, typically carriers, initiate an auction for excess capacity over a particular route with unsold capacity.
- DMS 70 contains a relational database including tables comprising raw data received from carrier legacy systems 72.
- the DMS system derives a refined database structure 76 from the raw data contained in database 74.
- the refined database structure 76 is configured for efficient searching in response to search queries from forwarders 78.
- a forwarder submits a search query to the DMS 70 and has returned to it a results table which includes carrier routes conforming to the search query criteria.
- the tables contained in database 74 are set up such that the data may be easily maintained and updated over a link from the carrier legacy system 72, preferably an automatic update link. Any changes in database 76 caused by updating of database 74 are then effected such that the revised database structure 76 is kept up-to-date, in order to service search queries and provide suitable results to the forwarder's systems 78.
- Relational database 74 containing the raw data received from the carriers, will now be described in further detail with reference to Figure 5.
- Relational database 74 contains a plurality of data tables. The data is input to the database from the carriers over a carrier interface 88. Optionally, where there is no electronic interface with the carriers, the data may be input by way of keyboard entry by the operator of the DMS system.
- Database 74 contains a carrier table 90 comprising a list of carriers taking part in the DMS 70. For each carrier entered into the carrier table 90, a series of related tables are stored in the database. At the top level, there is stored an operational schedule table 92 for each carrier.
- Schedule table 92 comprises the operational schedule (a short term schedule) provided to the DMS, or as derived from the seasonal schedule (a long term schedule), as appropriate to the particular carrier.
- the operational schedule table 92 provides a schedule of each flight leg instance for the carrier 90. That is to say, each flight between stations, the origin & destination stations, the time and date of arrival and departure, equipment type and ability to on-load or off-load cargo at each station for the flight are recorded in the operational schedule.
- a maximum connect time may be defined as a global parameter across the DMS system for all carriers, or on a carrier by carrier basis.
- a minimum connect time table 96 is provided which is related to the operational schedule table 92.
- the minimum connect time table 96 is a table of the stations included in schedule table 92 together with the minimum transfer times between carrier aircraft at that station.
- a maximum connect time table 94 is also provided and comprises a table of the stations referred to in the schedule table 92 together with the maximum connection time for transfers between carrier aircraft at that station.
- a further table related to the schedule table 92 is the Marketed Carrier Routes Options (MCRO) table 98 (a route table). This table contains the routes marketed by the carrier, together with other relevant information for that route.
- MCRO Marketed Carrier Routes Options
- This table contains the routes marketed by the carrier, together with other relevant information for that route.
- a transfer points table 100 is also provided and comprises a list of the marketed routes, together with the number of transfer point stations allowable for a journey over that route.
- At least a part of the data contained in database 74 may be transferred, 102, to a pre-calculation routine 104 which derives the flight segment table 76 from the data in database 74. .
- Pre-calculation routine 104 creates an instance of every valid combination of flight legs derived from respective operational schedule tables 92.
- Valid combinations of flight legs are formed in accordance with the examples disclosed in the description of Figure 1. Namely, that a flight segment is bounded by transfer stations. Any number of flight legs may be combined to form a flight segment.
- pre-calculation routine 104 instantiates flight segments LGW-MAN, MAN- JFK and LGW-JFK, showing all possible flight leg combinations.
- flight segments LHR-BKK and BKK-SYD are instantiated in flight segment table 76, without an instance of LHR-SYD, since BKK is a transfer station. That is to say, cargo is transferred from one aircraft to another at BKK for onward carriage to SYD.
- the DMS system also includes a search engine 106 which is coupled to the flight segment table 76 and responds to a search query 108 to search for suitable flights in the flight segment table.
- the search engine also interrogates other data tables in the DMS system which relate to parameters in the search request and the flight segments.
- the search engine also returns search results 108 to the forwarder submitting the query.
- FIG. 6 An example of the data provided by a carrier in a seasonal schedule table entry 91 is illustrated in Figure 6.
- the entry is represented as a column. Many entries make up the seasonal schedule.
- the seasonal schedule entry 91 is divided into two parts, 91a representing a flight and 91b representing a flight leg of the flight represented by 91a. For each flight 91a, there may be one or more flight leg entries 91b respectively corresponding to each flight leg of flight 91a.
- the flight leg entry/ies 91b are child/ren of flight entry 91a.
- Flight entry 91a comprises information characterising a flight, for example: carrier code (CARR_CODE); aircraft type and configuration codes (AIRCFT_TYPE_CODE) and (AIRCFT_CONFIG) respectively; origin and destination stations for the flight (ORIG_STN_CODE) and (DEST_STN_CODE); the seasonal schedule start and end dates (SCHED_STRT_DTE) and (SCHED_END_DTE) in both local end universal time (i.e.
- GMT Greenwich Mean Time
- Flight leg entry 91b includes the identity of the flight of which it is a leg, (FLIGHT D), and the order of the leg within the flight, (FLIGHT_LEG_ORDER).
- the leg departure and arrival times (LEG_DEP_TIME) and (LEG_ARR_TIME) are included for both local (LCL) and universal (UTC) time.
- Also included in flight leg entry 91b is information on the usual cargo capacity for the aircraft type and configuration in terms of weight (DFLT_AVAIL_VOL) and volume (DFLT_AVAIL_WGHT).
- the flight leg 91b is also identified as allowing cargo to be on-loaded at origin and/or off-loaded at destination by setting flags (ORIG_ONLD_FLAG) and (DEST_OFLD_FLAG) respectively.
- the operational schedule 92 is either derived from the seasonal schedule 91 or is supplied directly by the carrier, and an entry for flight instances and flight leg instances are shown labelled 92a and 92b respectively in Figure 6.
- Flight instance entry 92a is a child of flight entry 91a. Flight instance entry 92a contains more detailed information regarding individual flights, i.e. a flight instance. The departure and arrival times are provided by date and time (DEP_DTIME) and (ARR_DTIME) in both local and universal time.
- DEP_DTIME date and time
- ARR_DTIME ARR_DTIME
- the types of allowable cargo and limits of cargo are included in the fields (UNITSD_BKNG_FLAG) and (LSE_BKNG_FLAG) for indicating whether unitised or loose cargo bookings are allowed, and (MAX_SNGL_BKNG_WGHT) and (TOT_BKNG_WGHT) for the maximum single booking by cargo weight, and the total weight of cargo bookings by a forwarder organisation that may be taken.
- the contents of these fields may be set to default values dependent on the aircraft type and configuration, or by the carrier.
- the maximum single booking weight limit and total booking weight limit may be set by the operator of the DMS as a system parameter, automatically or manually derived from the default values, for example.
- Flight leg instance entry 92b is a child of both flight instance entry 92a and flight leg entry 91b.
- the flight leg instance entry 92b includes specific details of that flight leg. For example, the leg order (FLGHTJLEG ORDER), flight instance and flight leg identities (FLGHT NSTJD) and (FLGHT_ LEG_ID), and the actual cargo capacity available by volume (ACTL_VOL) and weight (ACTL_WEHT).
- Other fields corresponding to fields of flight leg entry 91b and flight instance entry 92 are also included as shown in Figure 6.
- the actual cargo capacity available by volume and weight is preferably provided separately to the schedules. For example available capacity data for each route leg instance may be provided by each carrier. Alternatively, carriers may set default values for sets of legs. In a preferred embodiment carriers provide capacity data in a table for each route leg instance and may provide capacity updates.
- a flight segment entry 93 corresponding to an entry in a flight segment table, is derived from the flight instance entry 92a and flight leg instance entry 92b.
- the fields for flight segment entry 93 include the flight number, flight instance identity, origin and destination stations, the carrier code, arrival and departure times and the aircraft configuration. Also included is a field for setting a period prior to flight departure during which no further cargo bookings for the flight segment may be taken (BKNG_ACPT_PERD); this defines a latest booking acceptance time. This field may be set by the DMS operator or be a default period, for example.
- the available volume and weight of cargo capacity is included in the flight segment entry 93, together with the connection times for different types of cargo for different types of aircraft.
- connection time categories are loose (LSE) or unitised (UNIT) freighter (FRGH_CON_TIME), mixed passenger and freighter, (MXD_ CON_TIME), passenger (PAS_CON_TIME) or truck (RFS_CON__TIME).
- FRGH_CON_TIME unitised freighter
- MXD_ CON_TIME mixed passenger and freighter
- PAS_CON_TIME passenger
- RFS_CON__TIME truck
- the type of equipment from which the cargo is off-loaded and on to which cargo is to be loaded determines the connection time.
- flight segment entry 93 also includes a maximum connection time (MAX_CONCTN_TIME) which is a system wide parameter and field for (LAST_LEG_ORDER) and (FIRT LEG_ORDER), respectively identifying the last and first flight leg in the segment.
- MAX_CONCTN_TIME is a system wide parameter and field for (LAST_LEG_ORDER) and (FIRT LEG_ORDER), respectively
- Aircraft load capacity table 84 is provided for each aircraft type, identified by AIRCFT_TYPE_CODE(FK), and is maintained by respective carriers having carrier codes CARR_CODE(FK). Each table 84 includes a field ULD_CODE(FK) indicating the ULD type which the identified aircraft can carry.
- ULD_TYPE comprises a full list of the ULD types, drawn from what are used in the cargo freight industry.
- ULD_EQUIV_GRP maps ULD type codes onto equivalent ULD codes (EQUIV_ULD_CODE), in order to harmonise different ULD types used in the industry to standard types used in the DMS system.
- EQUIV_ULD_CODE equivalent ULD codes
- different ULD codes may be used in the industry to refer to the same ULD type or different ULD codes may be compatible.
- FIG. 7 is an example of a maximum connection time table 94 from which the maximum connection time fields for the flight segment table 93 can be populated.
- the table is in the form of a grid, each type of carrier equipment (117, 118) is represented as being an originating equipment from (119) which cargo is unloaded, and to (121) which cargo is transferred.
- the grid is split into two repeating parts for loose and unitised cargo 112 respectively.
- the grid cells 123 each hold a value which represents the maximum connection time for transfers of cargo between the equipment and for the shipment type to which the cell relates.
- a maximum connection time table 94 is set up for each carrier, and in a further optional embodiment for each station in the carrier's network at which on-load and offload of cargo can take place.
- the maximum connection time table 94 illustrated in Figure 7 is merely an example, in grid format, of such a table. It is readily recognisable that other logical stmctures and criteria may be utilised. For example, it may be the case that the maximum connection time is dependent upon the type of cargo that is being transferred, and therefore the time may vary according to cargo type.
- An example of a cargo type where maximum connection time may be critical is that of perishable goods, such as food and vegetables. The maximum transfer time for such cargo may be significantly shorter than the maximum transfer time for non-perishable goods such as electronic equipment.
- Figure 8 is an example of a minimum connection time table 96.
- the minimum connection time table 96 is shown having a similar logical stmcture to the maximum connection described with reference to Figure 7, and so no further description will be provided.
- the MCRO table 98 defines the carrier route options which the carrier wishes to market. To this end the origin station and destination station are defined together with a carrier code, respectively designated ORIG_STN_CODE, DEST_STN_CODE and CARR_CODE. Typically an origin city and destination city are included in MCRO table 98 and are designated ORIG_CITY ⁇ CODE and DEST_CITY_CODE. However, designating the origin and destination city is not necessary.
- Various other fields are available within the MCRO table which relate to DMS parameters which control all management aspects of the DMS and will not be described in detail.
- the carriers are able to define a suggested rate for the carriage of cargo as well as a minimum rate, (MIN_SUGTD_RATE) and (MIN_STND_RATE) for the route. Additionally, there is a unitised and a loose booking flag for indicating the type of cargo the carrier wishes to carry on this route. These flags are represented by the fields UNITSD_BKNG_FLAG and LSE_BKNGJFLAG respectively. A maximum journey time for the route (MAX_TRNSIT_TIME) is also specified.
- the MCRO table 98 illustrated in Figure 9 is just for one carrier and one route. Every carrier will define each of their marketed routes by such a table, and it will be evident that the tables need not be structured in the manner illustrated in Figure 9, but may be formatted in any suitable logical stracture.
- a transfer set table 100 which is related to the MCRO table 98.
- the transfer set table 100 is a child of the MCRO table 98.
- the origin station code and destination station code of the related carrier routes together with the carrier code.
- the appropriate station code is entered into the field.
- transfer points may be specified for a single carrier marketed route.
- the transfer set table provides a high level of flexibility for the carrier in terms of the routes they wish to market. It is a relatively simple matter to modify which stations are to be transfer points and whether or not transfers are to be available at all. In this way, the marketed options can be easily updated and modified. Another advantage is that the carrier does not have to define every single available route, but merely the combinations of transfer point stations available. Thus, the carrier or DMS operator has minimal maintenance or set up to perform on the data.
- the flight segment table 93 is derived from the seasonal 91 and/or operational tables 92 provided to the DMS 70 by the carriers.
- the flight segment table 93 is created for each possible flight segment provided by the carriers using the DMS 70 system.
- the MCRO and some miscellaneous tables need be opened and interrogated in order to search for suitable routes in response to a search query.
- Relevant data from the different carriers has been de-normalised into at least an operational seasonal schedule 92, and then used to populate the relevant fields of the flight segment table 93.
- the many different systems and data utilised by different carriers are transparent to the user of the DMS 70 system, who merely sees the flight segment table 93.
- MCRO table 98 In addition to the flight segment table 93 containing relevant information for any searches, there is MCRO table 98, and the transfer points table 100. A search query will still interrogate the MCRO 98 table to determine whether a requested route option is marketed by a carrier or carriers, that route in turn being limited by the transfer points defined in the transfer set table 100. However, once the marketed route has been established as an existing route for a carrier, and the transfer stations have been identified then the flights segment table 93 is utilised to find the flight segment or combination of flight segments which will fulfil a route query.
- the other principal tables that are set up and accessed are the: member org table which details each carrier organisation parameters; carrier service rating table which is specified by the forwarder for each carrier on the route; buyer seller involvement table which sets out whether the carrier does business with the forwarder in a quote and/or reverse markets manner; preferred carrier table which is a list of preferred carriers specified by the forwarder; aircraft/ULD compatibility table 84 for ULD searches and which set out which ULDs can fit on a given aircraft; ULD table 88 which is a list of DMS system implemented and operator ULD types; and various system parameters.
- the transfer set table 100 may define transfers between carriers, for example carriers which are part of an interline arrangement.
- carriers may arrange unilateral agreements with each other and provide for transfer between respective flights.
- the foregoing described data architecture is particularly advantageous in terms of flexibility and updating of data. If a carrier makes a change to a flight, all they need to do is to update the appropriate entry in their operational table 92.
- the DMS 70 determines by means of a poll, trigger or other such message that a change in a field has occurred, opens and interrogates the relevant carrier operational schedule table 92, and makes a corresponding update to the field in the flight leg table 92b and flight segment table 93.
- Other changes may be made to an operational flight either directly through a user interface unit, via an unrolled change to a seasonal flight or via a batch update to the operational flight tables.
- the flight leg and flight segment tables are then automatically updated.
- the data entity relationships illustrated in Figure 6 show how a seasonal schedule 91 may be utilised to produce an operational schedule 92.
- the operational schedule is in great part the seasonal schedule entries having exact date and time applied to them, together with actual cargo capacity availability indicated. It is from the operational schedule 92 that the flight segment table 93 is generated. An example of the generation of the flight segment table 93 from the operational schedule 92 can now be described with reference to the flow diagram illustrated in Figure 10.
- a flight instance identity is set, to determine which of the flight segments are to be generated.
- the flight segments are constructed from the flight leg instance table 92b associated with the flight instance table 92a.
- Each possible combination of flight legs are evaluated, each one becoming a flight segment and populating flight segment table 93, associated with the appropriate flight instance identity, at step 144.
- the process of creating flight segments for each flight instance continues, until all possible flight leg segments have been created, providing a full flight segment table 93.
- the DMS is configured to be operable with both open and non-public computer networks.
- a particularly suitable configuration is illustrated in Figure 11.
- the DMS system 70 is coupled to customer's legacy systems 72 by a non-public network 150. Suitable non-public network links may be direct leased lines from telecommunications companies or links to non-public networks to which the carriers are connected, for example.
- the DMS system 70 is also coupled to a public network, such as the Internet 152.
- the legacy systems 72 may also be coupled to the Internet 152.
- clients may transmit data to the DMS system 70 via the non-public network 150 or the Internet 152.
- Such a configuration facilitates the scalability of the system, in particular the addition of new customers, since they need not provide non-public network links to the DMS system, but may choose to communicate via the Internet 152.
- Users of the DMS system, forwarders 40 access the DMS system 70 over the Internet 152 by means of workstations 154.
- the DMS system 70 can couple to forwarder systems and carrier systems via public or non-public links.
- the DMS system 70 is implemented as a Web Information System (WIS) at a website.
- WIS Web Information System
- the DMS system 70 is accessible throughout the world by means of the global Internet. That is to say, any location that has access to the Internet may also have access to the DMS system, provided suitable access rights are granted to them by the operators of the DMS system.
- WIS Web Information System
- the system becomes accessible by standard web applications. For example, all that a forwarder need have in order to interface with the DMS system is standard browser software and a connection to the Internet.
- the DMS system is platform independent and forwarders do not need any special hardware in order to access the DMS system.
- a particular advantage of configuring the DMS system 70 as a website is that it is relatively easy to scale up the service without forwarders 40 or carriers needing to upgrade or scale up their existing hardware or software (by for example having to install new versions of software).
- Other features provided by the DMS system are high resilience and high availability.
- the system is configured to preserve the confidentiality of sensitive information, control access to sensitive transactions, and to provide the service when and where it is needed
- Figure 12 describes the logical architecture of the overall system.
- the carriers and forwarders are shown as users of the system and are commonly labelled 160.
- the forwarders 40 use workstations 154 which are suitably “web-enabled", for example ranning suitable browser software, and are coupled to the Internet 152.
- the communications link between the forwarder workstation 154 and the Internet 152 is either a dial-up or a permanently connected leased line.
- the protocol used for communication with the DMS is HTTP and HTTPS 162.
- the carriers have back office systems 164, comprising their legacy computer systems 72 and their open communication systems such as workstations 154 which are web-enabled and capable of coupling to Internet based applications.
- the back office systems 164 are coupled to systems integration and communication modules 166, which provide interfaces to outside networks and systems.
- the DMS system 70 also comprises a systems integration and communications module 166 comprise interface servers which provide messaging and translation services for links with the customer 160 systems as well as other automated feeds, for example currency exchange rate information which may be obtainable from suitable information sites.
- the communications module 166 includes an interface module 168 comprising protocol converters, format translators and transmission systems.
- Interface module 168 provides suitable messaging and transmission services for the information within the DMS system 70 to be output over the proprietary networks 150 and over networks 152.
- the DMS interface module 168 also provides interfacing to web-based services such as currency exchange rate information, as well as other suitable information that may be utilisable by the system.
- Communications module 168 is internally coupled to incoming message queues 170 and outgoing message queues 172 to and from the back end 174 of the DMS system 70.
- the message queue modules manage the fransfer of messages to and from the DMS back end 174.
- Back end 174 comprises two main databases, a Management Information database 176 and an operational database 178.
- the Management Information database stores historical and statistical information regarding transactions conducted on the DMS system.
- the operational database 178 comprises the relational database 74 containing the raw data from the carriers and the refined database 76 comprising the flight instance table. Respective databases 176 and 178 are accessed by data access control module 180.
- Data access control module 180 handles incoming messages on the carriers which require access to the databases, as well as handling outgoing messages to the carriers or forwarders comprising data from the databases.
- the DMS system application logic 182 controls the data access control module 180, as well as the front end module 184 of the DMS system.
- the DMS application logic 182 comprises the functional modules for performing pre-calculation routines, 104, on the data received from the carriers in order to set up the flight instance table 76.
- the DMS application 182 also comprises the modules for receiving the raw data from the carriers and setting it up in the relational database 74 in accordance with tables as illustrated in Figure 5.
- the search engine 106 also resides in the DMS application 182.
- the front end 184 of the DMS system 70 comprises the customer or user interface aspects of the system.
- the front end comprises customisation modules 186 and client side scripts and applets modules 188.
- the customisation modules 186 are driven by the DMS application 182 and are set up to configure user interfaces, access rights and privileges as well as the format of any results in accordance with a particular user. For example, certain users may only be able to see flights offered by particular carriers or only certain types of cargo capacity.
- the customisation modules 186 and client side scripts and applets modules 188 are coupled to a web server 190.
- the DMS application 182 is also coupled to web server 190.
- Web server 190 performs the usual tasks and functions of a web server and provides web access to the DMS system 70 to a user, e.g. forwarder 40.
- Forwarders 40 make use of the system by virtue of workstations 154 running suitable browser software, typically inte ⁇ reting HTML, DHTML and javascript code, for example.
- the workstations 154 are coupled over a telecommunications network supporting TCP/IP communications.
- Forwarders and the DMS may also exchange digital certificate information over the telecommunications system through the Internet 152 to mutually authenticate each other
- the DMS system 70 front end 184 comprises a web tier.
- the web tier includes a load balancer 192 for balancing the incoming and outgoing messages to and from the Internet.
- Load balancer 192 is coupled to a web/application server or servers 194 comprising suitable software modules for interfacing with Internet users such as application servers executing JSP and JAVA modules.
- the web/application servers 194 in the front end- 184 are coupled to the back end 174 comprising the database tier.
- the database tier 174 includes a number of database servers.
- the database servers operate a program language such as SQL and C++ stored procedures for controlling and operating the database.
- the back end or database tier 174 is coupled to a customer communications module or customer interface tier 196.
- the customer interface tier 196 comprises the communications modules 168 and messaging queues 170 and 172 described with reference to Figure 13.
- An interface server couples the backend 174 to other networks such as non-public and proprietary networks and/or the Internet.
- the server handling the incoming and outgoing message queues 170/172 utilises mechanisms such as MQ series, FTP and SMTP for handling the incoming and outgoing message queues.
- the workstation 154 comprises various data processing resources such as a processor (CPU) 230 coupled to a BUS structure 238. Also connected to the BUS structure 238 are further data processing resources such as Read-Only Memory 232 and Random Access Memory 234.
- a display adaptor 236 connects the display device 218 to the BUS structure 238.
- One or more user-input device adaptors 240 connect the user-input devices, including the keyboard 222 and mouse 224 to the BUS structure 238.
- An adaptor 241 for connection of the printer 221 may also be provided.
- One or more media drive adaptors 242 can be provided for connecting the media drive, for example the optical disk drive 214, the floppy disk drive 216 and hard disk drive 219 to the BUS stracture 238.
- One or more telecommunications adaptors 244 can be provided, thereby providing processing resource interface means for connecting the workstation computer system to one or more networks or to other computer systems.
- the communications adaptors 244 could include a Local Area Network adaptor, a modem and/or ISDN terminal adaptor or serial or parallel port adaptor etc as required.
- the work station 154 may take many forms.
- the work station may be a non-PC type of computer which is Internet or network-compatible, for example a Network Computer or set top box for a TV capable of providing access to a computer network such as the Internet.
- the work station 154 may be in the form of a wireless PDA or a multimedia terminal.
- Work station 154 is configured to operate under the control of CPU 230 operating in accordance with a computer program stored in the workstation memory 232/234/219.
- the program implementable by the workstation 154 may be supplied on a telecommunications medium, for example over a telecommunications network and/or the Internet.
- the telecommunications medium may be a radio frequency carrier wave carrying suitably encoded signals representing the computer program and data information.
- the carrier wave may be an optical carrier wave for an optical fibre link or any other suitable carrier medium or a land line link telecommunications system.
- message and data structures and formats from the workstation 154 to a remote computer, such as the DMS system 70 or received from such a remote computer may also be supplied on any of the telecommunications media referred to above.
- the program may be supplied on a floppy disk 217 or CD-ROM 215.
- a Graphical User Interface for a remote system such as the DMS system 70, may be supplied over a telecommunications medium in order to configure the work station display device 218 to display a suitable Graphical User Interface on a display screen 220.
- a forwarder 40 wishing to utilise the DMS system 70 in order to search for suitable flights for carrying cargo from an origin to a destination station must first log on to the DMS website. When logging on to the DMS website, a welcome page is displayed and if the forwarder has previously registered with DMS then all they need to do is provide suitable passwords and user names comprising their member id of the DMS system and member organisation in order to authenticate themselves as a registered user to the system. In order to search for flights having a required cargo capacity, the forwarder 40 will request a capacity search.
- a server-side Java servlet in the Application Logic module 182 calls a decision making perform search stored procedure, dmPerformSearch, from the data access 180 in response to receiving the completed search parameters page.
- the dmPerformSearch module returns a list of results to the servlet which packages them in HTML and passes them on to the web server for transmission to the forwarder 40.
- the search parameter page transmitted from the web server 190 to the forwarder's 40 workstation 154 is displayed by a browser on the display screen 220.
- An example of a search user interface screen 250 is illustrated in Figure 15.
- the forwarder 40 inputs the journey origin 252 and destination 254 ai ⁇ orts into the appropriate screen fields 252 and 254.
- the origin ai ⁇ ort is London Heathrow and the destination ai ⁇ ort is John F Kennedy ai ⁇ ort in New York, having respective IATA designations LHR and JFK.
- Alternativelyfields for origin and destination city, respectively 256 and 258, are also provided on the user interface 250.
- Departure and arrival fields are also provided which are split into departure date 260 and time 262 and arrival date 264 and time 266, defining the window during which the forwarder 40 wishes to have the cargo transported from the origin to the destination. In a preferred embodiment, dates must be completed but times need not be.
- Fields 268 and 270 and 282 relate to the weight, volume and density of the goods for which cargo capacity is being searched. The calculator symbols 274 may be pressed to calculate the required volume if the weight and density are known or the density if the weight and volume are known. All three fields, weight, volume and density, need to be completed either by the user or automatically upon pressing the calculator icon in order for the nature of the cargo to be properly determined and the correct rate and value ascribed to it.
- Field 276 typically comprises a drop-down menu of different cargo types for which a search may be initiated.
- general cargo type is illustrated.
- Other types of cargo might comprise perishables, or auto parts, for example.
- Cargo type may be defined in any suitable manner by the DMS system operator.
- the cargo type may be further defined in terms of whether it is loose cargo, i.e. boxes or packages, or unitised cargo, that is to say pre-packed into predefined cargo units.
- a simple toggle button unitised 278 or loose 280 may be activated to indicate the cargo type.
- the cargo may be so-called outsized as defined by the IATA Rules, in which case field 282 is checked to indicate an outsized cargo.
- the unitised packaging type may be entered for a unitised search, i.e. toggle button 278 is activated.
- a forwarder may enter dimension data relating to individual pieces of cargo within the shipment.
- Data fields for the dimension data are provided in a search interface screen (not shown) corresponding to search interface screen 250.
- the dimension data include the number, length, width, height and weight of each piece of cargo.
- a calculator icon such as calculator symbol 274 is provided to generate the volume and density from the dimensions data, if provided.
- the forwarder is able to enter weight, volume, density and ULD category.
- the search screen (not shown) includes the ability to enter up to 3 ULD categories for a unitised shipment.
- the system will only return ULDs which have been mapped by the carriers to the categories specified in the search.
- Carriers map supported ULDs to the ULD categories.
- the forwarder need not define ULD categories if they would like to return all available ULD types.
- Carriers typically use one of the three international standard ULD typologies (TACT class rating, IATA type code or ATA US domestic terminology) and/or their own organisation-specific ULD types.
- the DMS allows carriers to map their ULD types to more generic ULD categories which differentiate ULDs across broad dimensions, such as container/pallet, lower/main deck.
- the forwarder is able to define generic ULD categories in the search screen, to ensure that only thoses specific carrier ULD types are returned which correspond to the defined category. For example, a search for Pallet (lower) will return in the search results only those segment sets and ULD types which the carrier has mapped to Pallet (lower).
- the carrier will provide rates and aircraft ULD compatibility for their specific supported ULD types. Their supported ULD types will be returned in the search results and be the basis for quote market and reverse market bookings.
- the lower half of the user interface screen 250 comprises a series of search filters which determine the results to be returned to the forwarder 40.
- Two toggle buttons 286 and 288 may be activated to either initiate a search which will return a list of carriers fulfilling the criteria, or a list of flights fulfilling the search criteria, respectively.
- Further options are to include non-participants in the system by checking field 290, to exclude passenger aircraft and mixed flights by checking field 292 and further to exclude trucks i.e. road transport, by checking field 294.
- Further search filters are the maximum number of transfers to be permitted which may be selected by means of a drop down menu 296, determining an allowed carrier service rating for the results to be returned which is selectable via drop down menu 298 and the ability to determine how many results one wishes to have returned by virtue of drop down menu 300.
- Further limitations may be to display only a single carrier code by checking field 302 and to show just the available capacity only, i.e. those results which can cater for the cargo capacity required by checking box 304. Additionally, results that cannot accommodate the searched capacity may be requested, for pu ⁇ oses of future reference or negotiation.
- the forwarder 40 may determine the order in which the results are to be returned to them by prioritising four different features.
- Four display fields are provided, each one having a drop down menu comprising the following five keys: preferred carrier, lowest cost, fastest arrival, latest departure, service rating.
- One or more fields 306-312 may be completed by using the drop down menus provided with each field, such that the results are ordered in accordance with the priority of the displayed keys.
- a user submits their request to the DMS system by activating the "search for capacity" button 316.
- User interface screen 250 may be configured to respond to a screen pointer controlled by the mouse 224 of the workstation 154 such that respective fields may be selected by user and data input into them by means of keyboard 222 or selection of options in a dropdown menu.
- the user interface program may move a prompt throughout the user interface 250 to each field in turn whereby a user may input such data as they may desire.
- Such a prompt may be controllable by means of the up/down arrow and tab keys typically found on a keyboard such as keyboard 222.
- a forwarder may explicitly select the type of search they wish to perform via the DMS system.
- the terms "loose” and “unitised” refer to the nature of the cargo packing.
- a flight segments search will return a set of results including full details of the flights segments for the requested route, whereas a carrier search will provide just carrier identification.
- Certain fields have to be completed for each type of search. These fields are the route between origin and destination, which could be a city or ahport, the search times, the cargo type and cargo capacity. There is a system defined maximum time period between departure and arrival times in order to ensure that excessively long periods are not entered. If this system parameter is exceeded, the system will issue an error.
- Ai ⁇ orts are generally associated with a city by an IATA table.
- Each flight segment entry 93 there is a departure date and time (DEP_DTIME) and arrival date and time (ARR_DTIME).
- DEP_DTIME departure date and time
- ARR_DTIME arrival date and time
- Each flight segment entry also has an origin and destination station for the flight segment.
- an export handling time and import handling time are also included.
- the export handling time is the time required at the origin station for handling before the flight departs.
- Export handling time is subtracted from the departure time to define a drop-off time (in fact a latest drop-off time).
- the import handling time is the time required at the destination station for handling after the flight arrives.
- Import handling is added to the arrival time to define a pick-up time (in fact an earliest pick-up time) for the shipment.
- a drop-off time and pick-up time is thus established for each flight segment in the flight segment table.
- a search may be envisaged to be time specified or itinerary specified (flight specific).
- the DMS searches the flight segment table and related tables for route segments with departure and arrival dates and times satisfying the request (where departure date and time is later than or equal to start (requested departure) date and time and arrival date and time is earlier or equal to end (requested arrival) date and time).
- the results may be displayed with the departure and arrival dates and times and/or with the associated drop-off and pickup dates and times.
- the DMS searches the flight segment table and related tables for route segments with drop-off and pick-up dates and times satisfying the request (where drop-off date and time is later than or equal to start (requested drop-off) date and time and pick-up date and time is earlier than or equal to the end (requested pick-up) date and time). Again, the results may be displayed with the departure and arrival dates and times and/or with the drop-off and pickup dates and times.
- Figure 16 illustrates a flow diagram for an illustrative embodiment of the dmPerformSearch stored procedure.
- the dmPerformSearch stored procedure resides in the DMS data access logic 180 and initially validates the input parameters for a search request from a forwarder, step 322.
- the dmPerformSearch stored procedure validates the following input parameters which may be input by the search for capacity user interface screen 250 or as part of the log-on procedure and the search for capacity screen 250.
- a member ID parameter is passed in; a result type search parameter is passed in; a loose or unitised (278,280) search parameter is passed in; results type (carrier or flights) 286,288; ensure origin ai ⁇ ort or origin city parameters (252,256) are passed in; ensure the destination ai ⁇ ort or destination city parameters (254,258) are passed in; ensure that the origin city (256) if passed in is a valid city; ensure that the origin ai ⁇ ort 252 (if passed in) is a valid ai ⁇ ort; ensure that the destination city 258 (if passed in) is a valid city; ensure that the destination ai ⁇ ort 254 (if passed in) is a valid ai ⁇ ort; ensure that origin ai ⁇ ort and origin city have not both been entered; ensure that destination airport and destination city have not both been entered; ensure that the origin is not the same as the destination for both ai ⁇ ort and city; ensure that origin station is
- the dmPerformSearch function then proceeds to step 324 where it generates a unique search identity for the search requested.
- This search identity is used to identify a search result set formed when retrieving results sub-sets.
- a common function called Result Set ID utilises the unique search ID and enters the unique ID into a record VU_SRCH_RSLT_SETU to record the time at which the search was performed. This record is then used in the DMS management system to determine when a search should be removed from the database.
- the unique search ID is returned to the client software once search processing is complete, for use in identifying the search result set.
- the next step 326 calls a FlightSegmentSet function which is used to generate a list of flight segments that fulfil the search criteria entered in the search screen, e.g. 250, in terms of the journey origin and destination stations, the route, start and end dates and capacity availability. This list of flight segments is used for all search routines that are performed subsequently.
- the dmPerformSearch procedure then proceeds to step 328 in which it is determined whether the search is of the carrier type or the flight type as determined by toggle switches 286 and 288 respectively in the search for capacity screen 250, for example.
- the dmPerformSearch stored procedure proceeds to step 330 where the carrier search function is called to perform the carrier search and the return "type" parameter "C" is set at step 332.
- the function control flows to step 334 where it is determined whether a unitised type search has been requested. If a unitised search has not been requested then at step 336 a flight search function is called which will search for flights carrying loose cargo. Then the control flows to step 338 in which a return type parameter "F" is set.
- control flows to step 340 where a unitised search function is called and thence to step 342 where a return type parameter "U" is set.
- a search results set is established reflecting the results of the appropriate search. From the search results set, the pricing of individual records within that set is performed.
- the procedure function "FlightSegmentSet" 326 is called in the dmPerformSearch procedure 320.
- the dmflightsegmentset 326 is executed for all search types and inserts into the result set table the list of flight segment sets that match the route specified in the search for capacity screen 250.
- Each flight segment set forms a row of data stored on the result set table, and the list is configured such that a requested number of rows can be returned to a JAVA servlet by a gefresults function for communication to a user workstation 154.
- the dmflightsegmentset search is a complex search and the search is performed in several distinct queries from which the complete result set is constructed. Each query is performed in turn and the output from the search is inserted onto the result set table, along with relevant search ID. Each individual query corresponds to the number of transfers allowed in the route.
- the dmflightsegmentset stored procedure starts at step 350 by searching the MCRO table 98 for carriers which market the journey entered onto the search window 250.
- the MCRO table 98 will be searched for an origin ai ⁇ ort LHR and a destination ai ⁇ ort JFK.
- the requested shipment type i.e. unitised or loose, is also checked against the route marketed by the relevant carriers.
- a list of the carriers marketing the requested route, with the requested shipment types is then stored by the dmflightsegmentset procedure.
- step 350 and 352 Other checks that may be carried out in steps 350 and 352 are that the carriers have an adequate service rating, parameter 298 in screen 250.
- step 354 the transfer point table 100 is checked to identify the transfer sets valid for the marketed route for each carrier.
- Flight segment table 93 is then searched at step 356 for direct flight segments having origin and destination stations corresponding to the origin and destination stations for the requested journey. Each of the direct flight segments is checked against the conditions entered into the search for the date period defined by search parameters 260,262,264 and 266 of screen 250 and includes the latest booking acceptance time conveyed by route and flight.
- a search for the necessary capacity is also undertaken as well as a search for the appropriate equipment type as defined by search parameters 292 and whether or not to include trucks as defined by search parameter 294.
- the DMS application logic also checks that each of the flight segments has its departure and arrival times within a maximum time period as set by a system parameter.
- the direct flight segments identified in step 356 satisfying the query are stored in a flight segment set list.
- the dmflightsegmentset stored procedure then proceeds to step 358 where it is determined whether a maximum number of flights have been identified.
- the maximum number of flights is typically a system parameter but optionally may be user defined. If a maximum number of flights has been identified then the dmflightlegset stored procedure process control flows to step 370 where the results in the flight legset list are ordered and the dmflightlegset procedure ends at step 372. However, if the result of step 358 is no then the process control flows to step 360 at which the flight segment table is searched for a combination of two flight segments fulfilling the journey request.
- the two flight segments may be for flights with the same managing carrier, but optionally they may be for flights having different carriers.
- connection of the two flight segments is handled by comparing the connection time i.e. difference between the arrival and departure of the two flight segments at the transfer station against the carrier minimum comiection time as defined in the minimum connection time table 96.
- connection time i.e. difference between the arrival and departure of the two flight segments at the transfer station against the carrier minimum comiection time as defined in the minimum connection time table 96.
- Two flight segments can only be connected if the time difference between their connection time and carrier minimum connection time is acceptable. That is to say, there has to be sufficient time in which to make the connection and transfer.
- the carrier minimum connection time varies depending upon aircraft, shipment type (loose or unitised) transit station etc as discussed with reference to Figure 8 when discussing table 96. Additionally, the connection time is compared with the maximum connect time system parameter, to determine whether or not the time difference is acceptable.
- connection time is also compared with the appropriate field in the maximum connect time table 94.
- the maximum connection time may vary depending upon aircraft type, shipment type (loose or unitised), and the transit station as well as other variables such as the nature of the cargo, as discussed with reference to Figure 7.
- each of the combined flight segments collectively known as a trans-shipment, is checked against a maximum journey time for the marketed route stored in the MCRO table 98 and any which exceed the maximum journey time are discarded.
- a further condition for trans-shipment tested at step 360 are that the next flight's origin matches the previous flight destination.
- the flight segment set list is then updated with the trans-shipments identified in step 360.
- Process control then flows to step 362 where a transfer point counter TPC is set to 1. This counter is used in order to check that the number of fransfer points in a route do not exceed a user's specifications or a system parameter.
- TPC transfer point counter
- each flight segment is capable of transporting cargo as set out in the request in terms of cargo compatibility for cargo type, dimensions and/or ULD type, for example. For instance, each segment must be capable of transporting cargo having the dimensions set out in the request or of the ULD type requested
- the result of the dmflightsegmentsetprocedure is to produce an ordered flight segment set list.
- the ordering is in accordance with the order results parameters 306,308,310,312 and 314 input on the search screen 250.
- process control flows to the dmPerformSearch stored procedure 320 where the search type is determined at step 328.
- search type to be performed by the perform search algorithm 320 is determined.
- a carrier search function 330 is initiated.
- the process control flow for the carrier search function 330 will now be described with reference to the flowchart illustrated in Figure 19.
- the first entry in the flight segment set list is read.
- step 386 the next entry in the flight segment set list is read and process control flow returns to step 302 to determine whether the number of transfers in the next entry exceeds the maximum allowed. If the number of transfers does not exceed the maximum, then the process control continues and flows to step 384 where the entry is stored and the search results and the next entry is read from the flight leg set list. However, if the number of transfers in the most recently read entry of the flight leg set list exceeds the maximum value, then process flow control moves to step 388 where the carrier search function is terminated and the final search result set is returned to the perform search procedure.
- the final search result set comprises a list of carriers with flights and cargo capacity sufficient to fulfil the request.
- the first step 390 of the unitised search function 340 is to read the first entry in the flight segment set list. At step 392 it is determined whether or not the number of fransfers for the entry exceeds a maximum.
- step 394 it is determined whether or not the enfry contains a flight segment capable of supporting ULD unitised cargo generally, or if a ULD category has been entered that the flight segment supports that specific ULD type. If the result of step 394 is yes then process confrol flows to step 396 where the entry is stored in the search results set. Then, at step 398, the next enfry in the flight segment set list is read and process control flows to step 392 where it is determined whether or not the number of transfers for that next entry exceeds the maximum value. At step 394, if the current read entry does not support the ULD cargo, or a specified ULD type, then process control flows to step 398 where the next entry in the flight segment set list is read.
- step 392 If the result at step 392 is yes, that is to say the number of transfers in the currently read entry from the flight segment set list exceeds a maximum value, then process control flows to step 400 where the search results set is returned to the dmPerformSe_trch stored procedure 320. Search result sets are only relumed where each flight segment supports a common ULD type or types.
- a search results set has now been created corresponding to the respective search type requested by the forwarder.
- a price is associated with each flight segment set record.
- the price may be a function of the volume, weight or density of the cargo capacity request.
- Such a price per unit of capacity may be included at an entry in the MCRO 98 table.
- the price may be an entry for each flight leg in the flight instance table 76 with the price for each flight leg in a combination of flights forming a segment and/or route being summed to give a total price for that route.
- rate cards are provided on the DMS system which are configured by many different parameters, including route and flight segments or flight legs, to calculate a rate for a journey.
- the rate cards are created and maintained by carrier by route, journey, forwarder, cargo type, day of week for example.
- the DMS system finds the correct rate card for each flight segment set and calculates a rate taking into consideration shipment type, weight amongst other things.
- the rating or revenue management information held against the MCRO referred to above includes a minimum for that route, below which the calculated rate is not allowed to fall. It is a minimum rating control.
- the system compares the rate on the rate card with the rate on the MCRO and takes the minimum of the two.
- the search results are then displayed in the order selected by the user in the relevant search screens.
- the user selects for which of the selected route options they wish to book cargo capacity.
- cargo capacity booking is done by selecting one of the flight segment sets in the results list, which initiates the generation of a booking screen which may be filled out by the user in order to book cargo capacity.
- booking of cargo capacity may be by more conventional means such as a fax, telephone, or e-mail to the relevant carrier.
- Figure 20 shows the overall system.
- Customer (carrier) systems 72 communicate with customer interface (CI) system 710 across the Internet and/or other networks, as already described with reference to Figure 12.
- CI system 710 interacts with CI Flights Database 712 which in turn interacts with Flight Batch System 714, Web Transaction System 716 and Main Database 718.
- Web Transaction System 716 and Main Database 718 also interact with one another.
- Allotment Batch System 720 interacts with Web Transaction System 716 and Main Database 718.
- Main Database 718 interacts with Management Information System (MIS) 722.
- MIS Management Information System
- Off-line tools 724 can be used to load carrier and forwarder data gathered off-line into the CI Flights Database 712 and Main Database 718.
- Web Transaction System 716 and MIS 722 communicate with client (forwarder and/or carrier) work stations 154 across the Internet and/or other networks.
- the Web Transaction System 716 comprises a web application server and database access software and enables forwarders using workstations 154 to submit search requests to the data management system.
- the MIS 722 uses data from the main database 718 to generate on-line reports, and the Allotment Batch System 720 is used to load allotment bookings and templates received via the Web Transaction System 716 into the main database 718.
- Carrier systems 72 supply flight schedules to the CI system 710 either as seasonal schedules 91 with standing flight timetables or operational schedules with individual flight instances.
- the CI system 710 stores the flight schedules in operational schedule tables 92 and seasonal schedule tables 91 in the CI Flights Database 712. Capacity data for populating the flight segment table is also provided.
- MCRO Marketed Carrier Routes Options
- Transfer Set data are also supplied by the carrier system 72 to the CI system 710, and these are stored in the Main Database 718 in MCRO table 98 and transfer set table 100 respectively. Copies of the MCRO table and transfer sets table are held in the CI Flights Database.
- ULD data is similarly received and stored in ULD tables 82. Operational schedule table 92, seasonal schedule table 91, MCRO table 98, transfer set table 100 and ULD table 82 and their relationships have been described with reference to Figures 6 and 9.
- Flight Batch System 714 runs a batch process to unroll a carrier's seasonal schedule 91 to produce an operational schedule 92.
- the operational schedule sets out the origin and destination stations, the time and date of departure, equipment type and the ability to on-load and off-load cargo at each station for each flight.
- pre-calculation routine 104 creates flight segments for the flight segment table, valid combinations are made for segments which have an on-load capability at the origin station and an off-load capability at the destination station.
- flight legs are only combined by pre-calculation routine 104 to form segments in the flight segment table if the flight legs belong to the same flight i.e. have the same flight number.
- different rules may be followed for combining flight legs to produce flight segments in the flight segment table. For instance a carrier may specify via an identifier which legs may be combined with which to form segments
- MCRO table 98 and transfer set table 100 are used to define a marketed carrier route segments set by for example creating a marketed carrier route segments table containing all of the permissible route segments defined by the data in these tables. For example, if a carrier is marketing LHR-SIN directly and LHR-SIN via DXB, assuming load-on and load-off capability at DXB, then the marketed flight segments LHR-DXB, DXB-SIN and LHR-SIN will be created. However, if only LHR-SIN directly is being marketed then only the marketed flight segment LHR-SIN will be created.
- Precalculation routine 104 when populating the flight segment table reads data representing a flight leg or valid flight leg combination from the operational schedule and checks the origin and destination stations against those of each marketed flight segment. If the flight leg or flight leg combination corresponds to a marketed flight segment then the leg or flight leg combination will be entered into the flight segment table as a flight segment. If the flight leg or flight leg combination does not correspond to a marketed route segment then it is not entered into the flight segment table. Therefore in the example above a leg DXB- SIN would be entered into the flight segment table as a segment only if a corresponding marketed flight segment exists i.e. in the first part of the example but not the second part of the example.
- the MCRO table 98 and transfer set table 100 are preferably still used in the dmPerformSearch procedure to first act as a check that the data in these table has not changed (been updated) and secondly check that if the search concatenates two or more segments that the concatenated search result corresponds to a marketed route and/or valid transfer.
- the Flight Segment table formed in the CI Flights Database 712 is replicated to the Main Database 718 to support main transactions (customer searches) performed through the Web Transaction System 716.
- Main Database 718 holds the MCRO table, transfer sets table, ULD table and other tables used for customer transactions including the member org table, rating table, buyer seller involvement table, preferred carrier table and aircraft/ULD compatibility.
- the CI System 710 and CI Flights Database 712 are implemented as a CI server on a separate server to the main database 718, Web Transaction System 716 and Allotment Batch System 720.
- the CI System as well as receiving and handling Flight Schedules and populating the flight segment table, handles the exchange of other data between the carrier legacy systems (Customer/carrier systems) and the main database 718. This includes handling capacity updates, MCRO updates, transfer set updates, updates of other carrier data and the handling of booking requests generated through the DMS system and booking responses from the carrier system. Updates are cascaded to related tables using database triggers.
- the CI server ensures that this data is kept accurate and current.
- carriers can load allotment templates (via the Web Transaction System 716 into Allotment Batch System 720) as a record of a permanent booking or forwarder allocation contract.
- the template defines attributes of the agreement, such as the forwarder, the reserved or pre-booking capacity, flights and routing.
- Allotment templates are loaded using a bulk data interface.
- the interface allows data to be entered into a browser window in a published format.
- the data can be maintained and entered directly into the DMS, or imported from an external application such as a carrier system or spreadsheet.
- the data content conforms to a common, published standard.
- the allotment template includes a number of fields, which together uniquely identify the template. In a preferred embodiment they are: ⁇ Carrier ⁇ Forwarder ⁇ Origin ⁇ Destination ⁇ Start date
- Carriers can optionally specify an account number on a template. If defined, only users with a corresponding account number - an identifier of the gateway within which they operate - can make a booking against the template.
- Allotment reference o The allotment reference is an optional field that can be used to differentiate allotments which are otherwise unique. ⁇ Flight(s) ⁇ Product name ._ _ _
- the allotment template may also include an end date. Allotment templates should overlap if all other keys are the same.
- Flight details may include:
- ⁇ departure variance number of days after first flight on which subsequent flights depart; not required for first flight
- capacity identifiers capacity identifier which is sent in booking message. The identifier can be used to identify the logical capacity partition that the booked capacity should decrement and allows carrier legacy systems to manage capacity according to forwarder without maintaining low level capacity partitions within their own systems.
- the identifier can be left blank
- the template may additionally define one or more of the following: ⁇ Allotment weight ⁇ Allotment volume ⁇ Allotment closure time (hours before departure) ⁇ Unit type (unitised templates only) ⁇ Unit number (unitised templates only) ⁇ Remarks (shown as link to pop-up box showing seller remarks) ⁇ Milestone plan (name of plan shown as link to pop-up box showing milestone plan details ' )
- the template load function Maintain Allotment Templates, is accessed from the main menu.
- the user is able to load new templates, amend or delete existing templates.
- the user is presented with a screen with a blank text area, in which data can be pasted or typed, in the correct format.
- An example of the Maintain Allotment Templates screen is shown in Figure 22, populated with sample data.
- Figure 23 illustrates the checks performed by the DMS. The user can view the outcome of their load either by 'Quick Search' from the event message, or by selecting Allotment Templates Maintenance Outcome from the main menu.
- the results for each load are shown in a summary line.
- the results include: Q Time the data was first submitted to the DMS ⁇ Time the data was processed by the DMS
- FIG. 24 An example of the outcome screen is shown in Figure 24.
- the forwarder receives an event message for each new or amended or deleted allotment template. If there were errors in loading any records, users can navigate to an Error Correction screen by clicking on the amend (pencil) icon. All records with errors are then displayed in the Correct Allotment Templates screen. Users can amend the records in the top edit box and view details of why the record was rejected in the lower edit box. A line number at the front of the record in each window helps users easily link the errors with the record. Users can amend record ' s directly in this screen, or make changes in an external application and re- paste the data into the top box before resubmitting. The lower box will also show the Allotment Template Reference, if supplied.
- Figure 25 shows an example of the Correct Allotment Template Errors screen.
- the Allotment Templates Maintenance Outcome screen shows the results of each load for a set of data. For example, if a load of 100 records leaves 10 records in error, the user can correct the errors and resubmit.
- the outcome screen will show both loads together, with the same 'Time first submitted' to allow users to track successive load attempts. The latest attempt will be shown first, and previous attempts will show an indented Time Processed, to help users to focus on the most recent load. See Figure 24 for an example.
- Carriers and forwarders are able to search for, and view, allotment templates online.
- Templates will be returned if they include any of the selected days, flight number (if entered), or if any active date lies between the start and end date (if entered).
- Figure 26 shows the Search for Allotment Templates screen.
- Milestone plan (name of plan shown as link to pop-up box showing milestone plan details)
- Flight departure variance (number of days after first flight departure day on which subsequent flights depart) ⁇ Flight origin ⁇ Flight destination ⁇ Flight Capacity ID
- Carriers can amend and delete allotment templates once they have been created. Allotment templates are amended and deleted using the same Maintain Allotment Templates function that is used to create templates.
- Figure 28 illustrates the checks that take place on submitted records, and the expected outcomes.
- Carrier users can either access the Maintain Allotment Template screen from the main menu or from the Allotment Templates Search Results. Once a search has been carried out for allotment templates, a user can select the Maintain Allotment Templates button from the search results. The user is taken directly to the Maintain Allotment Template screen where the window is already populated with the search results, presented in the published data format.
- the carrier can therefore choose whether to maintain and edit data directly in the DMS, or through an external application before importing the data into the DMS.
- amendments to allotment templates are not automatically applied to bookings that have already been made against the template on a specific date. For example, if a carrier reduces the capacity on an allotment template, bookings capacity is only validated against the new allotment capacity next time the booking is amended or a new booking is created. Optionally, such a restriction is not included in the system.
- Forwarders can load allotment bookings into the DMS. Allotment bookings are loaded using a bulk data load interface.
- the interface allows data to be entered into a browser window in a published format.
- the data can be maintained and entered directly in the DMS, or imported from an external application such as a forwarder system or spreadsheet.
- the data content conforms to a common, published standard.
- the allotment booking has a number of mandatory fields that are the minimum required to make an allotment booking. In a preferred embodiment they are:
- the forwarder can optionally provide further information where:
- the forwarder wants to define the capacity they will be using, for example where the units are different from those defined on the template or more or less capacity is booked, or they are providing data such as remarks or dimensions Q
- the booking is going to be sent by e-mail and more information is desired
- the template load function Maintain Allotment Bookings
- the user is able to load new bookings or amend existing bookings (see description below)
- the user is presented with a screen with a blank text area, in which data can be pasted or typed, in the correct format.
- An example of the Maintain Allotment Bookings screen is shown in Figure 29, populated with booking data.
- the DMS processes the data and sends an event message once the data has been processed.
- the user can view the outcome of their load either by 'Quick Search' from the event message, or by selecting Allotment Booking Maintenance Outcome from the main menu.
- the results for each load are shown in a summary line.
- the results may include:
- the Allotment Booking Maintenance Outcome screen shows the results of each load for a set of data. For example, if a load of 100 records leaves 10 records in error, the user can correct the errors and resubmit.
- the outcome screen will show both loads together, with the same 'Time First Submitted' to allow users to track successive load attempts. The latest attempt will be shown first, and previous attempts will show an indented Time Processed, to help users to focus on the most recent load. See Figure 30 for an example. In one embodiment outcomes are visible for seven days after processing.
- the DMS conducts a series of checks on booking records that are loaded through the bulk interface.
- Figure 32 provides an illustration of the checks that take place to determine whether the booking is new or an amendment, whether the booking can be made (if new), what state the booking should be created in/amended to. Defined capacity checks take place once the booking is identified as an amendment or new record. Details of the Booking E-mail Decision are with reference to Figure 35.
- Allotment bookings may be amended in bulk using the same Maintain Allotment Bookings function that is used to create bookings, or individually through the 'Amend allotment booking details' function (see below).
- Figure 32 provides a high- level view of the checks that take place on submitted records, and the expected outcomes.
- Forwarder users can either access the Maintain Allotment Booking screen from the main menu or from the Bookings Management Search Results. Once a search has been carried out for bookings, a user can select the Maintain Allotment Bookings button from the search results. The user is taken directly to the Maintain Allotment Booking screen where the window is already populated with all the allotment bookings from the search results, presented in the ICD data format.
- Figure 33 shows the Maintain Allotment Bookings button, available from the Bookings Management Search Results. Users can amend records directly, or paste data into the screen to add to or overwrite the existing records. The forwarder can therefore choose whether to maintain and edit data directly in the DMS, or through an external application before importing the data into the DMS .
- the DMS automates the capacity checks that are typically carried out by carrier sales (52, Figure 2) before making a booking.
- the DMS compares the booking request to the unused capacity on the allotment template. Amended bookings are also compared with the available capacity on the allotment and either sent for Manual Review or Confirmation, according to the allotment booking rules. If a Pending booking is amended, the status stays as Pending and no action is required of the carrier.
- Allotment booking amendments do not go into negotiation. If an amendment is sent for Manual Review, the carrier can accept or reject the amendment, and can add remarks. If the amendment is rejected, the original booking remains confirmed and the seller remarks can be viewed on the booking.
- Carriers can define an excess booking tolerance to apply to all allotment bookings.
- the tolerance is set as a percentage through the Maintain Seller Parameters screen. The tolerance is not displayed to the forwarder. When bookings are made, and the booked capacity compared to the allotment capacity to determine whether the booking should be sent to manual review, the allotment capacity is adjusted by the tolerance.
- the tolerance applies to both allotment weight and volume independently, as follows:
- Carrier stations can be configured to receive allotment bookings by e-mail.
- the e- mail may consist of: ⁇ A subject line describing which organisation the mail is from, and which origin and carrier it is intended for ⁇ E-mail text defining the user the bookings were sent by, the units and formats used in the bookings (weight, volume, date, numbers), instructions for how to view and print the bookings, and standard confidentiality and disclaimer information ⁇ An html attachment containing booking information. An example of the booking file is shown in Figure 34.
- the allotment bookings load could include those for which DMS member carriers have configured allotment templates, those for which DMS member carriers have chosen not to configure templates, and non-DMS carriers.
- a carrier receives an e-mail or facsimile if there is an appropriate address configured for the carrier by forwarder by origin station. For example, bookings loaded by FastForward for carrier Global Airlines originating out of HKG.
- the e-mail is copied to the forwarder user, who must also have an e-mail address configured.
- the 'reply to' address is the forwarder user's.
- Carriers can register or associate a milestone plan with an allotment template.
- the milestone plan defines key events before departure, and any terms and conditions that apply at those events.
- the milestone plan can reflect a formal contract, with penalties or incentives applicable at each milestone, or an informal series of reminders to encourage booking updates.
- the carrier can register multiple milestones in the DMS, and associate each with one or more allotment templates.
- Each milestone plan may be identified by a name, and can include one or many milestones.
- the following data is maintained: ⁇ Milestone number (cannot be zero, cannot be a duplicate on same plan) ⁇ Time to departure (cannot be a duplicate on same plan) ⁇ Percentage payable (optional field to reflect contractual obligation) Q Remarks (optional field to include carrier text)
- the milestone plan can be viewed by the carrier and forwarder as a pop-up from each template (through Allotment Templates Search Results), and from each booking to which it applies (through Allotment Bookings Search Results).
- Carriers can define milestone plans associated with allotment templates.
- the milestone plan defines events before departure.
- the milestones apply to all bookings made against those allotment templates.
- Forwarder and carrier users can search for bookings where a milestone is due to be reached within a certain number of hours, using the predicate Time Remaining to Milestone.
- the user can select a number of hours as the 'window' for the milestones.
- the user can search for milestones up to 72 hours (three days) in the future.
- Figure 36 shows the search predicate.
- a bookings management search predicate is introduced which allows forwarder and carrier users to search for bookings that have not been updated within a certain period.
- the user defines a 'window' of a number of hours using the search predicate Time Since Last Update.
- the user selects the value from a drop-down list.
- the maximum value is 72 hours. Any bookings that have not been updated within that window will be returned.
- the search applies to allotment, quote and reverse market bookings.
- Figure 36 shows the search predicate.
- Milestone plans are defined by a number and a time (in hours) to departure.
- the carrier may also define an Allotment Closure Time on the template which is the latest time (in hours before departure) that bookings can be created, amended or deleted on the allotment.
- a checkbox - Include Closure Time as Milestone? - is provided to allow users to search for bookings with milestone approaching, where the Allotment Closure Time is treated as a milestone. Bookings will be returned if there is either a milestone or a closure time within the window.
- Figure 36 shows the search predicate.
- Allotment bookings can have milestone plans associated with them. Carrier and forwarder users will be shown milestone information in the Bookings Management Search Results. The milestone information is available from the 'twisty' against the booking which expands to show a second line of booking information. The milestone information shown is:
- the DMS provides forwarders and carriers with access to a data warehouse and operational data system, or Management Information System (MIS).
- MIS Management Information System
- the MIS consolidates reference and transaction data and provides analysis to customers based upon user defined criteria.
- the allotment activity in the DMS is audited and available to users to provide a neutral, central repository for allotment utilisation statistics.
- the report provides data to carriers and forwarders about the confirmed bookings made against allotments over a user defined period.
- the user is able to search by the following criteria:
- the report indicates: ⁇ The number of allotment 'instances' (on how many separate dates within the period was the allotment 'active') ⁇ ⁇ The number of bookings made by the forwarder against that allotment ⁇ The total weight of the allotments (a sum of all 'instances') ⁇ The total volume of the allotments (a sum of all 'instances') ⁇ The total weight booked against the allotment (a sum of all bookings) ⁇ The total volume booked against the allotment (a sum of all bookings) ⁇ Percentage of allotment weight that was booked (total booked weight divided by total allotment weight) ⁇ Percentage of allotment volume that was booked (total booked volume divided by total allotment volume)
- the report provides data to carriers and forwarders about the confirmed bookings made against allotments on specific dates.
- the user is able to search by the following criteria: ⁇ Buyer (if user is a seller) ⁇ Seller (if user is a buyer) ⁇ Origin ⁇ Destination ⁇ Start date for period
- the data is grouped by the following key fields: ⁇ Organisation ⁇ Origin ⁇ Destination
- the report indicates: ⁇ The date of the allotment ⁇ The weight of the allotment ⁇ The volume of the allotment ⁇ The total weight booked against the allotment (a sum of all bookings) ⁇ The total volume booked against the allotment (a sum of all bookings) ⁇ Percentage of allotment weight that was booked (total booked weight divided by allotment weight) ⁇ Percentage of allotment volume that was booked (total booked volume divided by allotment volume)
- FIG. 40 an example of an allotment usage by milestone report screen is illustrated.
- the report allows carriers and forwarders to show the usage of an allotment relative to any milestones that apply.
- Usage is measured as the sum of bookings in states Confirmed, Unconfirmed or In Review.
- the report allows users to search for allotments by the following criteria: ⁇ Buyer (if user is a seller) ⁇ Seller (if user is a buyer) ⁇ Origin ⁇ Destination ⁇ Departure date range ⁇ Shipment type ⁇ Cargo type
- the report will show the weight and volume booked at each milestone, for each allotment on each date.
- the following fields are returned: ⁇ Buyer (if user is a seller) ⁇ Seller (if user is a buyer) Q Origin
- the report groups data by Milestone Plan and shows the following data: ⁇ Milestone name ⁇ Milestone number
- FIG. 42 an example of an allotment booking template screen is illustrated.
- Forwarder users can run a report to show allotment templates in the same format as the Allotment Booking Load ICD (Interface Control Document).
- the allotment templates are automatically converted to show a record for every date on which they are active.
- the data can be downloaded and saved as a standard csv (comma-separated values) file.
- the report includes a space for the forwarder user to insert an AWB before loading through the Maintain Allotment Bookings function.
- the report is intended to be used in conjunction with data management spreadsheets for managing allotment bookings.
- each Member Organisation 802 has an address 803 and one or more Carrier ULD types 804, including an Allotment ULD 806.
- Each Member Organisationi 802 also has none, one or more Allotment Templates 808, with a relationship via a Carrier Product 810 possible.
- Each Member Organisation also has one or more Milestone Plans 812, preferably related to one or more Allotment Templates 808.
- each Allotment Template 808, if unitised, has one or more associated Allotment ULDs 806 and comprises one or more Allotment Segments 814 having one or more Segment Set Members 816.
- Each Milestone Plan 818 has one or more Milestones 818 associated therewith. Also illustrated is Flight Segment 820.
- each Carrier 852 is a Member Organisation 802 having one or more Users 854.
- Each Carrier has one or more related Capacity Bookings 856 optionally with one or more related Capacity Booking Histories 858.
- Each Capacity Booking 856 has an associated Segment Set 860 comprising one or more associated Segment Set Members 862.
- Also associated with the Capacity Booking optionally are one or more Pricings 864.
- the Carrier Product 810 having associated Product Booking Information 864.
- Each Capacity Booking has one set of Shipment Details 868 and an associated Cargo Type 870..
- AWB usage 872 and whether or not manual consideration is required (874) for a Cargo Type 870 and their associations are also illustrated.
- the computer program is stored on a carrier medium in machine or device readable form, for example in solid-state memory or magnetic memory such as disc or tape and the processing device utilises the program or a part thereof to configure it for operation.
- the computer program may be supplied from a remote source embodied in a communications medium such as an electronic signal, radio frequency carrier wave or optical carrier wave.
- a communications medium such as an electronic signal, radio frequency carrier wave or optical carrier wave.
- carrier media are also envisaged as aspects of the present invention.
Landscapes
- Engineering & Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Business, Economics & Management (AREA)
- Economics (AREA)
- Human Resources & Organizations (AREA)
- Development Economics (AREA)
- Entrepreneurship & Innovation (AREA)
- Aviation & Aerospace Engineering (AREA)
- Marketing (AREA)
- Operations Research (AREA)
- Quality & Reliability (AREA)
- Strategic Management (AREA)
- Tourism & Hospitality (AREA)
- General Business, Economics & Management (AREA)
- Theoretical Computer Science (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
Description
Claims
Applications Claiming Priority (9)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
GBGB0016822.9A GB0016822D0 (en) | 2000-07-07 | 2000-07-07 | Method computer system and computer system network for data management |
GB0016822 | 2000-07-07 | ||
US62406900A | 2000-07-24 | 2000-07-24 | |
US624069 | 2000-07-24 | ||
GBGB0027301.1A GB0027301D0 (en) | 2000-07-07 | 2000-11-08 | Data management system |
GB0027301 | 2000-11-08 | ||
GB0111737A GB0111737D0 (en) | 2001-05-14 | 2001-05-14 | Data management system |
GB0111737 | 2001-05-14 | ||
PCT/GB2001/003041 WO2002008935A2 (en) | 2000-07-07 | 2001-07-06 | Method, computer system and computer system network |
Publications (1)
Publication Number | Publication Date |
---|---|
EP1305732A2 true EP1305732A2 (en) | 2003-05-02 |
Family
ID=27447861
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
EP01947640A Withdrawn EP1305732A2 (en) | 2000-07-07 | 2001-07-06 | Method, computer system and computer system network |
Country Status (4)
Country | Link |
---|---|
EP (1) | EP1305732A2 (en) |
CN (1) | CN1447945A (en) |
AU (1) | AU2001269286A1 (en) |
WO (1) | WO2002008935A2 (en) |
Families Citing this family (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN102523261B (en) * | 2011-12-06 | 2014-04-02 | 北京经纬信息技术公司 | Distributed data processing system |
CN102855281A (en) * | 2012-07-31 | 2013-01-02 | 李建波 | Automatic patent document updating method and patent publishing and pre-warning system adopting method |
CN104182856A (en) * | 2014-07-24 | 2014-12-03 | 余少勇 | An international freight forwarding air platform system |
DE102019003233A1 (en) * | 2019-05-08 | 2020-11-12 | Daimler Ag | Method for evaluating a freight order by means of a freight order evaluation system and also a freight order evaluation system |
CN113361998B (en) * | 2021-06-04 | 2023-09-08 | 北京京东振世信息技术有限公司 | Determination method, device, equipment and medium for apportioned transportation cost |
Family Cites Families (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5265006A (en) * | 1990-12-14 | 1993-11-23 | Andersen Consulting | Demand scheduled partial carrier load planning system for the transportation industry |
US5623413A (en) * | 1994-09-01 | 1997-04-22 | Harris Corporation | Scheduling system and method |
JP3247274B2 (en) * | 1995-02-28 | 2002-01-15 | 松下電器産業株式会社 | Transport route search device |
JP3161529B2 (en) * | 1998-05-15 | 2001-04-25 | サントリー株式会社 | Vehicle dispatching equipment |
-
2001
- 2001-07-06 WO PCT/GB2001/003041 patent/WO2002008935A2/en active Application Filing
- 2001-07-06 AU AU2001269286A patent/AU2001269286A1/en not_active Abandoned
- 2001-07-06 CN CN 01812447 patent/CN1447945A/en active Pending
- 2001-07-06 EP EP01947640A patent/EP1305732A2/en not_active Withdrawn
Non-Patent Citations (1)
Title |
---|
See references of WO0208935A3 * |
Also Published As
Publication number | Publication date |
---|---|
CN1447945A (en) | 2003-10-08 |
WO2002008935A2 (en) | 2002-01-31 |
AU2001269286A1 (en) | 2002-02-05 |
WO2002008935A3 (en) | 2003-02-06 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US20040054549A1 (en) | Method, computer system and computer system network | |
US20040015409A1 (en) | Method, computer system and computer system network | |
KR100975610B1 (en) | Common carrier system | |
US20040010578A1 (en) | Method, computer system and computer system network | |
US20180300669A1 (en) | Inland freight management | |
US7711602B2 (en) | Systems and methods for supply chain management | |
US6785718B2 (en) | Method and system for interfacing with a shipping service | |
CN106815702A (en) | A kind of Smartway dispatch management method | |
AU2008282178B2 (en) | Transportation management system | |
EP2648143A1 (en) | System and method for providing immediate confirmation for shipping services | |
US6970825B1 (en) | Planning engine for a parcel shipping system | |
US20040015605A1 (en) | Method, computer system and computer system network | |
US6957197B1 (en) | Load planning tables for a parcel shipping system | |
CN109978420A (en) | A kind of logistics and distribution management scheduling system | |
US20090037245A1 (en) | Gateway balancing | |
EP1299816A2 (en) | Method, computer system and computer system network | |
WO2002008935A2 (en) | Method, computer system and computer system network | |
WO2002005110A2 (en) | Method, computer system and computer system network | |
WO1998048366A1 (en) | System and method for event management within a transportation network | |
US20240095658A1 (en) | Integrated logistics ecosystem | |
WO2001071534A2 (en) | System and method of reserving cargo space on aircraft flights | |
WO2019130152A2 (en) | Platform for connecting cargo aero-transportation providers with cargo transportation consumers | |
Bloomen | Air express market entry in Latin America, 1988-1992 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PUAI | Public reference made under article 153(3) epc to a published international application that has entered the european phase |
Free format text: ORIGINAL CODE: 0009012 |
|
17P | Request for examination filed |
Effective date: 20030124 |
|
AK | Designated contracting states |
Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LI LU MC NL PT SE TR |
|
AX | Request for extension of the european patent |
Extension state: AL LT LV MK RO SI |
|
RAP1 | Party data changed (applicant data changed or rights of an application transferred) |
Owner name: GF-X OPERATIONS LIMITED |
|
17Q | First examination report despatched |
Effective date: 20080104 |
|
REG | Reference to a national code |
Ref country code: HK Ref legal event code: WD Ref document number: 1053883 Country of ref document: HK |
|
STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN |
|
18D | Application deemed to be withdrawn |
Effective date: 20100202 |