METHODS AND SYSTEMS FOR FACILITATING TRAVEL PLANNING

FIELD OF THE INVENTION

The present invention is in the field of travel planning, particularly in the area of corporate travel planning.

BACKGROUND TO THE INVENTION

The planning and implementation of a corporate travel itinerary is typically a shared task involving the traveller, personnel within the traveller's organization, and often also an external travel management company (TMC). The organization typically is charged with the planning of travel, while the TMC is responsible more so with the implementation of the travel plan by arranging transport, accommodation, insurances and the like.

Generally, the traveller initiates a request to travel often by the submission of a form to relevant personnel within the organization. This may be a manager having authority to approve, modify or decline the request. In some circumstances security personnel participate in the approval process. Where the manager/security personnel approves the request, the matter is often passed to travel-related personnel within the organization to prepare an itinerary, with further action possibly being undertaken by other personnel more directly charged with travel-related tasks. In some organizations, further travel-related tasks may be passed to a TMC for execution.

Significant complication arises where, for example, an executive plans to travel to several countries on a business trip. Regard must be had to many variables and tasks including the scheduling flights, transfers, accommodation, ticketing, issuance of vouchers and other matters.

While recreational travellers have some leeway in their travels, this is rarely available for corporate travellers who must be on time for meetings, seminars, trade shows and the like. Accordingly, arrangements made for corporate travellers are required to have a high level of precision, this presenting particular problems in the art Matters may be complicated by the inclusion of a TMC in the process. The external nature of these companies mean that specific requirements of an organization can be overlooked, this leading to protraction of travel planning and provision of required documentation.

A further problem arises by an organization's continued reliance on the services of a given TMC. While such ongoing relationships can improve efficiencies in travel arrangements, an organization may be less inclined to use more than one TMC, or to switch TMCs to obtain improved pricing or services. ,

It is an aspect of the present invention to overcome or ameliorate a problem of the prior art by providing systems for facilitating travel planning by an organization. BRIEF DESCRIPTION OF THE FIGURES

Fig 1 is a flow chart illustrating an exemplary workflow for a travel request, approval and booking. Elements in the light-grey regions relate to the travel authoriser within the organization , those in the mid-grey regions of the flow chart are those related to the traveller (or travel arranger) within the organization, and those in the dark-grey regions relate to the Travel Management Organization.

Fig 2. is a screenshot of an initial login page.

Fig 3 is a screenshot of a user dashboard.

Fig 4 is a screenshot of a user dashboard with notifications.

Fig 5 is a screenshot of an authoriser dashboard. Fig 6 is a screenshot of user discussion thread.

Fig 7 is a screenshot of a page for approving a trip.

Fig 8 is a screenshot of a page confirming submission of travel request. Fig 9 is a screenshot of a Travel Management Company dashboard. Fig 10 is a screenshot of HART Airline Risk Calculator ratings. Fig 11 is a screenshot of a contact page.

Fig 12 is a screenshot of a country risk rating request

Figs. 13 to 17 are exemplary workflows, and wherein actions shaded light-grey are traveller / travel arranger actions; actions shaded black are authoriser / super authoriser actions. System notifications are shaded mid-grey, and booking tools shown as light grey with a diagonal line. Travel management company actions are shown in white with a diagonal line.

The following legend is used to denote common actions:

Start

Yes

Trip edited

No

Cancelled

End

Approval

Approve

Decline (with message to declined party/parties)

Select new approver

13 is a flow chart of a pre-trip and cost approval process where the consultant is offline.

Fig. 14 is a flow chart of a cost approval only process where the consultant is offline. Fig. 15 is a flow chart of a pre-trip and cost approval process incorporating use of an online booking tool.

Fig. 16 is a flow chart of cost approval only process incorporating use of an online booking 100 tool.

Fig. 17 is a flow chart of a pre-trip approval only process, with online and offline configuration.

105 Figs. 18 to 20 are charts showing handling of traveller profile information by systems administered by (i) the traveller or travel arranger (ii) coordinating entity (iii) travel management company (iv) corporate employing the traveller and (v) online booking tool.

Fig. 18 is a chart showing the creation of a new traveller profile, the profile created within 110 the coordinating entity system. The newly created profile is transferred to the online booking system by real time synchronization of the coordinating entity server and the online booking system server.

Fig. 19 is a chart showing the amendment of an existing traveller profile, the profile created 115 within the coordinating entity system. The profile amendments are transferred to the online booking system by real time synchronization of the coordinating entity server and the online booking system server.

Fig. 19 is a chart showing the deletion of an existing traveller profile, the profile created 120 within the coordinating entity system. The profile is deleted from the online booking system by real time synchronization of the coordinating entity server and the online booking system server.

SUMMARY OF THE INVENTION

125 After considering this description it will be apparent to one skilled in the art how the invention is implemented in various alternative embodiments and alternative applications. However, although various embodiments of the present invention will be described herein, it is understood that these embodiments are presented by way of example only, and not limitation. As such, this detailed description of various alternative embodiments should not 130 be construed to limit the scope or breadth of the present invention. Furthermore, statements of advantages or other aspects apply to specific exemplary embodiments, and not necessarily to all embodiments covered by the claims.

Unless the contrary intention is expressed, the features presented as preferred or 135 alternative forms of the invention can be present in any of the inventions disclosed as alone or in any combination with each other.

Throughout the description and the claims of this specification the word "comprise" and variations of the word, such as "comprising" and "comprises" is not intended to exclude 140 other additives, components, integers or steps.

In consideration of one or more problems detailed in the Background section herein, Applicant proposes that the arranging of travel in an organization can be improved by •referencing various kinds of information during the arranging process. In a first aspect, the 145 present invention provides a computer-based system for facilitating personnel travel arrangements within an organization, the system comprising:

means for obtaining information required for travel approval by a guided method,

means for creating a proposed travel plan based on the information required for- 150 travel approval, optionally means for allowing review of the proposed travel plan by organization personnel, and

means for creating a proposed itinerary,

wherein the proposed travel plan and/or proposed itinerary is/are created by reference to a travel-related policy of the organization, and/or by reference to information provided by 155 one or more entities external to the organization.

In a further aspect the present invention provides a method for facilitating personnel travel arrangements within an organization, the method comprising the steps of:

obtaining information required for travel approval by a guided method, creating a proposed travel plan based on the information required for-travel

approval, optionally reviewing the proposed travel plan by organization personnel, and

creating a proposed itinerary,

wherein the proposed travel plan and/or proposed itinerary is/are created by reference to a travel-related policy of the organization, and/or by reference to information provided by one or more entities external to the organization.

Applicant proposes that travel arranging is made more efficient, or more simple, or more economical, or more accurate, or less prone to error, or is made otherwise advantageous 170 where structured, computer-based methods are used to generate a proposed travel plan, and reference the plan against internal organizational travel policies and externally- originating information such as health and safety information on a destination, visa information, and the like.

175 The confluence and use of information provided internally (i.e. by the organization) and information sourced externally (for example from a TMC, government department, or an airline) provides significant advantages in the art. Applicant proposes that significant time and resources are wasted in the arrangement of corporate travel by the common requirement to amend travel arrangements in light of information discovered during

180 planning of the travel, or in the creation of a proposed itinerary or final itinerary, or in the generation travel documentation such as airline tickets and- accommodation vouchers. Further improvements in the art are contemplated where a TMC is involved in the process of arranging personnel travel, since some embodiments of the computer-based system allow for savings in time and resources of the TMC. By the incorporation of third party data

185 the present systems and methods are capable in some embodiments of improving the operational efficiency of the organization and/or TMC; and/or improving employee compliance with corporate governance of the organization; and/or reducing the overall cost of travel for the organization.

190 It is routine practice for personnel (both organizational and TMC) involved in the arranging of travel to make multiple amendments to the arrangements, in light of organizational policy and other travel-related information. This iterative process of fine tuning a travel plan or itinerary is accepted practice in the art, with there being no useful alternatives proposed at the filing date of this application to the best of Applicant's knowledge.

195

In the context of the present invention, the term "computer-based" is intended to mean that the system is operable at least in part or even entirely on any processor-equipped device such as a server, personal computer, laptop, netbook, tablet, PDA, smart phone and other similar contrivances. The system may be implemented on a single computer or across 200 multiple computers connected to a LAN, WAN or the Internet. In the context of the present invention the term "computer-based system" is intended to include any necessary hardware and software components, as well as data transmission components (such as wired and wireless network infrastructure, as more fully described infra).

205 As used herein the term "Travel Management Company" is intended to mean any organization separate to that of the organization for which the travel plan is created. While TMCs commonly deal with the travel requirements of corporate entities, some also deal in recreational travel. Conversely, some companies which deal mainly in recreational travel also deal in corporate travel. All the aforementioned types company are considered a TMC.

210 However, in one embodiment the TMC deals predominantly or solely in corporate travel.

The term "organization" is intended to mean the organization within which the traveller is employed, operates or is otherwise associated with. The organization may be a corporate entity (for profit, or not-for-profit), community group, government organization and the 215 like.

The present systems and methods require means for obtaining information by a guided method. The skilled person is familiar with browser-based methods (for example) which are useful for presenting questions or options to an individual, and allowing the individual 220 means by which to enter the required input. In the present context, such guided methods can be advantageous since information which is necessary and sufficient to create a proposed travel plan may be readily obtained. Furthermore, irrelevant information is not sought and therefore not included in any review of the proposed travel plan. 225 In one embodiment, the guided method for obtaining information presents questions or options to the user (who is typically the individual seeking approval to travel) that are related to organizational travel policy. For example, an initial question may relate to the countries to which the individual seeking approval wishes to travel. Organizational policy may dictate that travel is only allowed to countries having a minimal safety rating, or a

230 minimum level of sales, or having an organization branch office, or where organizational personnel have not visited in the last year. Thus, countries may be presented as radio buttons on a browser page, with only those countries being acceptable under current organizational policy being selectable. Alternatively, the user may input a list of countries into a text box on the browser page, and then submit those options. An error message will

235 result indicating that one or more countries are not allowable for travel. It will be understood form this example that policies may change over the course of time, with options being manually or automatically updated in some embodiments of the present systems.

240 Other forms of user input are contemplated for use with the present systems including the use of drop down boxes, check boxes, voice recognition, and the like.

The guided method may have consideration to one, several or a plurality of aspects of organizational policy including the following non-limiting examples: dates of travel, mode of 245 travel, class of travel, class of accommodation, overall cost of travel, length of time travelling, size of rental car, collision damage waiver for car rental, minimum level of travel insurance, maximum allowances for meals, maximal allowances for client entertainment, and the like.

250 In some embodiments of the guided method, a past answer or selection provided by the user influences a later question or option. For example, where the user indicates that travel to North America is planned, a further question or option may be raised relating to which city or cities within North America are required. It may be the case that a large country such as North America is divided into a number of territories for the purposes of organizational 255 policy, with elicitation of such information only being required where travel to North America is planned.

The guided method may be more simple than those described supra, and in some embodiments be an electronic form having questions and spaces reserved for the insertion 260 of answers. While generally effective, it is proposed that a more structured guided questioning improves the overall system or method by focussing the intentions of the user, and also guiding toward the elicitation of information that is useful to the reviewer when deciding to approve, deny or modify the proposed travel plan.

265 In a preferred embodiment, the system or method is implemented across two or more sites, or is implemented across two or more servers, or is adapted to allow access to both organizational and external personnel (such as TMC personnel), or by an external server. Such embodiments allow for the integration of data input, organizational travel policy considerations, and external information such as safety information, travel and

270 accommodation availability and the like to be provided in an efficient manner.

In one embodiment, the system comprises an organizational interface and a TMC interface. The organizational interface allows the user to input a proposed travel plan and also for other personnel in the organization to enter various criteria related to travel policy. 275 Reference is made to the browser-based example described supra.

The result of the various inputs provided by the user at the organizational interface (as dictated or modified by organizational policy) is a proposed travel plan. This plan may then transmitted via the TMC interface, to a TMC server. The data may be passed in a variety of

280 ways, such as via wired or wireless broadband connection such as long-range optical data communications, local area network based protocols, wide area networks, long-range wireless radio, local area wireless network such as 802.11 based protocols, wireless wide area network such as WiMax, and/or other similar applications; transmission of electric, electromagnetic, optical, and/or wireless signals and/or packets that carry digital data

285 streams using a standard telecommunications protocol and/or a standard networking protocol, Session Initiation Protocol (SIP), Voice Over IP (VOIP) protocols, Wireless Application Protocol (WAP), Multimedia Messaging Service (MMS), Enhanced Messaging Service (EMS), Short Message Service (SMS), Global System for Mobile Communications (GSM) based systems, Code Division Multiple Access (CDMA) based systems, Transmission

290 Control Protocol/Internet (TCP/IP) Protocols. Other protocols and/or systems that are suitable for transmitting data include cabled network or telecom connections such as an Ethernet RJ45/Category 5 Ethernet connection, a fiber connection, a traditional telephone wireline connection, a cable connection or other wired network connection may also be used. Data transmission between the organization and TMC or within the organization may

295 be by use of standard wireless protocols including IEEE 802.11a, 802.11b, 802.11g, etc., or via protocols for a wired connection, such as an IEEE Ethernet 802.3.

In one embodiment, the system is embodied without the need to install dedicated software or database information on a user's computer. For example, the core software components 300 of the system may be embodied in a server remote form a user's computer, with data transmission between the computer and server being via the Internet, by way of a browser platform such as Microsoft Internet Explorer™, Google Chrome™, Mozilla Firefox™ or Apple Safari™.

305 The skilled person is familiar with methods for implementing the present systems and methods on such web browser platforms. Dynamic pages can be programmed on the server or client side, but typically server-side web programming languages are used whereby code is run on the server and then transmits static information back to the web browser. Suitable web programming languages may include PHP, ASP.NET, Ruby on Rails, Perl, ASP classic,

310 Python, and JSP.

The skilled person is also familiar with various relational databases useful in the programming of dynamic web page content. Such databases allow for the storage, manipulation and retrieval of any required information such as user details, travel plan 315 details, organizational policy details, country safety information, passport and visa requirements for a country, preferred suppliers of transport and accommodation, et cetera. A suitable relational database well understood by the skilled person is Microsoft SQL. However, other database solutions such as Oracle and DB/2 may be useful, especially for larger implementations of the system.

320

Those of skill in the art will appreciate that the various embodiments disclosed herein can be implemented as electronic hardware, computer software, or combinations of both.

In one embodiment, the system is capable of interfacing with two, several, or a plurality of 325 TMCs. This capability may be achieved by the incorporation of one more data interchange formats in the system. Thus, the travel plan may be exported from the organization in a format that is readable by personnel and/or management software the TMC. This capability may provide advantages in one or more aspects. For example, the ability to transmit a travel plan to several TMC's allows an organization to seek several itineraries 330 instantaneously. The selection of TMC for that particular travel plan may be taken on the basis of cost, the number and length of stop overs en route, the convenience of connections and the like. A further potential advantage is that the system can be embodied in a vendible product which may be installed and be immediately substantially capable of interfacing with any TMC.

335

As an example only, the organization and TMC may exchange travel plan data by electronic data exchange (EDI), which is the structured transmission of data between organizations by electronic means. It is used to transfer electronic documents or data from one computer system to another computer system without human intervention.

340

As a further example, a speciation such as that defined by the Open Travel Alliance (OTA) may be used to interchange data. OTA develops open data transmission specifications for the electronic exchange of business information for the travel industry, including but not limited to the use of XML. Many application programming interfaces (APIs) have been 345 developed for software developers to process XML data, and several schema systems exist to aid in the definition of XML-based languages such as RSS, Atom, SOAP, and XHTML. XML- based formats have become the default for many office-productivity tools, including Microsoft Office (Office Open XML), OpenOffice.org and LibreOffice (OpenDocument), and Apple's iWork. XML has also been employed as the base language for communication 350 protocols, such as XMPP. Thus, the skilled person is amply enabled to design and execute many different schemes (including bespoke solutions) for information interchange between the organization and the TMC based wholly on common knowledge in the art.

OpenTravel provides the de facto standard for the travel and leisure industry, and is used by 355 suppliers, resellers, global distributors and integrators globally. Due to the wide adoption of the specification, tens of thousands of OpenTravel message structures are in use, carrying tens of millions of messages every day.

At present, the OpenTravel Specification supports the following travel industry segments: 360 air, car rental, customer profiles, dynamic packages (air, car, hotel, extras), ground transportation, hotel, loyalty programs, and rail. However it is contemplated that customization of the basic protocol could be implemented in order to accommodate other parameters.

365 A further example of a potentially useful data exchange protocol is the Global Distribution System (GDS) which currently provides connectivity modules allowing hotels to connect with travel agents. GDS is powered by four networks: Sabre, Amadeus, Worldspan and Galileo; the same reservations systems used to connect with the airlines. Another useful protocol may be Pegasus ODD (Online Distribution Database). Partner hotels easily keep

370 up-to-date GDS / ODD room inventory and rates, and third parties can retrieve real time rates and room inventory and book instantly via GDS and ODD networks. Utilising GDS data combined with the various external information, the organization will have access to the data required to build a travel plan, or a proposed itinerary.

375 It will be understood that any of the above protocols may be used in the present systems to transmit data between the organization and the TMC, or the organization and any other entity external to the organization. The data may be transmitted mono-directionally or bi- directionally.

380 Data interchange between the TMC and the corporate may be handled using a secure API (application programming interface) connection exposing the necessary data required by the TMC to enhance and streamline the booking and approval process. XML feeds and API connectivity from the TMC to the corporate allow a synchronise link of travel and profile data. The skilled person is well versed in the implementation of data interchange protocols 385 and methods. Accordingly, further disclosure is not required, and for the sake of clarity and brevity is not provided herein.

The system provides that the proposed travel plan is created by reference to information provided by one or more entities external to the organization.

390

In one embodiment, the external organization is a TMC. The TMC may provide information either directly to the system (such as by an interface), or manually (such as by text document or verbal means which are manually entered into the system by the organization). The information provided by the TMC may be any information that may be

395 relevant to the approval of a proposed travel plan, or the implementation of a proposed itinerary. For example, the user may submit a travel plan at short notice requiring a flight on 25 June 2012 from Sydney to New York, with organizational policy dictating an economy fare. The TMC automatically or manually enters flight availability into the system on a daily basis, with reference to that availability information by the system returning an error ,

400 message to the user during the guided travel planning method informing that the planned travel is not possible. An option may be provided by the system to allow for the user to select a business class seat (which is available on the required days), with a reviewer of the proposed travel plan capable of granting or denying the more expensive business class airfare.

405

In another embodiment the external organization is an organization that provides travel- related information that may be relevant to the approval of a proposed travel plan, or the implementation of a proposed itinerary. For example, the external organization may be a government department (such as the Australian Department of Foreign Affairs, the United 410 States of America Department of State, or the United Kingdom Foreign and Commonwealth Office). Such organizations may provide information relating to safety issues that may affect a decision to approve travel within an organization. While the travel-related information may be imported automatically into the system, more typically the information will be entered manually into defined fields. Usefully, the safety information is structured as a 415 numerical rating, or some other quantifiable means such that a clear minimum safety level may be set for each country.

In another embodiment, the external organization is an accommodation organization or a transport organization. Information provided by these organizations may be useful in 420 determining the availability of flights, hire cars, hotel rooms etc during the planning phase of the travel arrangements.

• In other embodiments the external organization is a hotel rating organization that provides assessments of the quality of accommodation. There are a wide variety of rating schemes 425 used by different organisations around the world, any of which may be useful in the present context. Many have a system involving stars, with a greater number of stars indicating greater luxury. The American Automobile Association (AAA) and their affiliated bodies use diamonds instead of stars to express hotel ratings levels.

430 Many such hotel rating organizations exist including online tripadvisor.com; motoring clubs such as the Royal Auto Club (United Kingdom), National Roads and Motorists' Association (Australia); tourist boards such as the Scottish Tourist Board; dedicated ratings organizations such as the European Hotelstars Union.

435 The external information may relate to a safety rating or other features of a hire car, airplane, bus or train proposed to be utilized in the travel arrangements. As an example, HART Aviation (Australia) provides an aviation airline risk calculator which calculates a risk factor associated with a scheduled airline service. The risk is calculated by having regard to indicators such as management, fleet age, accident record, alliances, operational training,

440 maintenance, flying environment, national regulatory control, the International Air Transport Association [IATA] IOSA audit, and other factors. Many organizations are bound by health and safety protocols and must therefore have regard to such criteria.

The present systems and methods optionally comprise means or a step allowing for review

445 of the proposed travel plan by organization personnel. Conveniently, the means are provided by a browser page being viewable on the reviewer's personal computer. The reviewer is enabled by the system to review the proposed travel plan (typically presented in textual form) and also optionally other information relevant to the approval process such as cost. In some embodiments, the system highlights to the reviewer any aspects of the plan 450 that may not be consistent with organizational travel policy, and optionally means for amending the plan and/or return the plan to the user for amendment.

The present systems and methods optionally comprise means or a step allowing for comparison of a proposed cost or a settled cost of travel against a budget of the

455 organization. Where the cost exceeds the budget, the traveller or travel arranger (and optionally the TMC) will be notified. The early identification of a budget overrun is advantageous for the organization, and avoids the payment of penalties where bookings are cancelled due to inadequate funds being available. In one embodiment, the traveller or travel arranger is permitted to amend one or parameters (such as flight class, standard of

460 accommodation etc) to reduce cost, and resubmit the travel plan.

Once the travel plan is settled (and to the satisfaction of the reviewer), the reviewer approves the plan (typically by clicking a button on the browser page). The system may at that point dispatch an email message to the user, advising that travel has been approved.

465

Upon approval by the reviewer, the system typically electronically transmits the plan to personnel responsible for actioning the plan. Where the entire system is executed internally (i.e. without the assistance of a TMC) the plan is dispatched to organizational personnel responsible for making the travel arrangements. More typically however, the 470 travel plan is dispatched electronically to a server of the TMC, optionally by an agreed data interchange protocol as described supra.

A significant advantage of the present systems is that after review the TMC is provided with a pre-qualified trip plan from which a proposed itinerary (or even a final itinerary) may be 475 created. This negates, or at least lowers the probability, that amendments are required to the itinerary. In addition or alternatively the provision of an approved travel plan may result in the need for only minor amendments to the itinerary. In one embodiment, the system includes means for monitoring compliance with the 480 organization travel policy. This may be achieved by the user entering compliance-related information during the trip (for example, by way of a mobile-capable web browser (such as those executable on android or iOS). In addition or alternatively, the compliance-related information may be entered into the system by way of personal computer upon return of the user.

485

The compliance-related information may relate to expenses, time spent in a given location, time devoted to business, time devoted to recreation, entertainment venues visited, restaurants frequented, gratuities provided and the like. The information may in some 'embodiments be validated against organization policy and any deviations reported by the 490 system to management personnel.

One embodiment of the system or method includes the step of validating the travel plan, or an itinerary created from the plan, against organizational policy. This may be achieved by comparing components of the trip (such as flight class, accommodation style, and costs) 495 against the policy as entered into the system by organizational personnel. This validation step is advantageous in that it represents a final checking mechanism before the plan is transmitted to the TMC or is otherwise actioned within the organization.

In another aspect, the present invention provides processor-executable program 500 instructions for implementing a method as described herein.

In another aspect the present invention provides a computer-readable memory containing processor-executable program instructions for implementing a method as described herein.

505 DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

Overview

Via the company intranet the proposed traveller (user) clicks a travel link, which (using a single sign on) logs the user into a portal to begin the approval process. The user then clicks on the desired workflow to initiate the travel planning process. 510

From the initial click the user is presented with a series of browser windows presenting a series of questions to be answered in order to obtain travel approval. Once all travel-related criteria are validated, the user submits the application for approval.

515 The TMC receives notification of a trip and creates the itinerary which is uploaded into the system. The TMC submitted itinerary is then checked to ensure organization policy is met.

Once the booking is loaded the reviewer can then select and approve the itinerary. Where the travel is domestic only, the review process may not be required, with the plan 520 automatically approved pursuant to various criteria being met during the guided questioning process.

Upon authorisation the traveller is notified that their travel request is successful and they have the ability to view their itinerary.

525

An exemplary workflow is shown in Fig. 1. Screenshots of pages relevant to the input and output of the present systems are shown in Figs. 9tol2.

With respect to the workflow of Fig. 1, the following descriptors are relevant:

530 2 Log in

4 Click the appropriate pre-trip workflow approval

6 Traveller completes form (including specific workflow criteria)

8 Criteria Valid?

10 No

535 12 Yes

14 Submit for approval - this is point of charge (one charge per approval)

16 No

18 Online booking?

20 Pre-TMC authorization required?

540 22 No

24 Yes 26 Pre-TMC authorization required?

30 Yes

32 No

34 Authorizer notified that a Pre-TMC approval has been placed

36 Authorizer has been notified that a Pre-Online approval has been placed

38 Yes

40 Authorizer logs in to view approval request

42 Authorizer logs in to view approval request

44 Authorizer presented with completed traveller pre-trip enhanced data

46 Authorizer presented with completed traveller pre-trip enhanced data

48 Advise traveller, travel arranger of declined trip

50 No

52 Approval accepted?

54 More information required

56 Discussion thread requesting change

58 Advise traveller, travel arranger of declined trip

60 No

62 Approval accepted?

64 More information required

66 Discussion thread requesting change

68 Traveller, travel arranger notified of approval now pending TMC itinerary upload

70 Yes

72 Yes ,

74 TMC notified that a trip request has been placed

76 Traveller, travel arranger notified of approval now pending TMC itinerary upload

78 Trip details sent to online booking tool pre-populating search fields

80 TMC logs in to view approval request

82 Traveller, travel arranger selects travel options based on loaded travel policy 84 TMC consultant generates itineraries/quotes

86 No

88 Policy valid?

90 Itineraries/quotes submitted into approval workflow 92 Yes

575 94 TMC informed of violations

96 Portal runs cross check with policy criteria specified ensuring policy of itinerary met

98 Trip itinerary/quotes loaded into portal

100 No

102 Policy Valid?

580 104 Authorizer notified that online booking has been placed and requires approval

106 Yes

108 Authorizer logs in to view approval request

110 Trip itinerary/quotes loaded into portal

112 Authorizer notified that an itinerary has been uploaded ready for approval

585 114 Authorizer selects itinerary/quote to approve

116 Authorizer logs in to view approval request

118 Advise traveller, travel arranger of declined trip

120 No

122 Discussion thread requesting change

590 124 Authorizer selects itinerary/quote to approve

126 Yes

128 Approval accepted?

130 More information required

132 Advise traveller, travel arranger and TMC of declined trip

595 134 No

136 Approval accepted

138 More information required

140 Discussion thread requesting change

142 Traveller, travel arranger notified of booking placed

600 144 Yes

146 TMC notified to place booking

148 Booking placed

150 Traveller, travel arranger notified booking placed.

605 Detailed process

As a first step, users are presented with the Travel Organiser Portal, which is an initial pre- trip landing page. The Travel Organiser Portal is used by corporate travel managers and travellers to access the pre-trip travel management system and products therein that are 610 relevant to them.

Travel Organiser Portal Summary

Single sign-on (see Fig. 2)

Corporate Logo & Branding

615 Links Module - Including links to client specific info & 3rd party suppliers

Company Travel Policy

Preferred Hotels

Preferred Car Hire

Profile Forms

620 Medical Information

Information on VISA

Help Guides

Alerts Module - Travel, Profile & System

625 The Travel Organiser Portal is developed for the traveller / authoriser / management and can be also be utilized to interface with the TMC. The system enables these users to utilise the pre-trip workflow for travel authorization. A TMC has access to technology relevant to them that will enable execution of their respective tasks and interact with other parts of the system necessary to them.

630

Traveller Pre-Trip Approval

Domestic & International Travel Traveller pre-trip approval includes a workflow as follows:

Personal Details pre populated from profile

635 Travel details outlining proposed trip

Check to ensure correct training has been completed and advise if incomplete Determining the risk factors and warnings of the travellers destination/s Checks to ensure correct vaccinations have been issued

Checks to ensure airline is approved

640 Checks to ensure travel insurance is in order

A compliance declaration making sure the traveller agrees to the travel to protect the corporate.

And any other customised information, material, logos etc

645 Modular Development

Each section required for authorisation is created as a standalone module. By doing so, each pre-trip authorisation consists of both standard and custom modules to satisfy all required needs of the corporate.

650 Each module contains the necessary links to third party data sources in order to leverage off this data as part of the pre-trip approval process.

Due to the flexible nature of custom modules integration with HART Aviation is allowed to give the TMC data to make sure preferred airlines are booked.

655

Reviewer Dashboard

The authoriser has the ability to access personal and staff travel requests through a single user-friendly console (see Fig 5).

660 This allows the authoriser to manage and streamline the pre-trip process and can communicate directly with the traveller via a purpose built discussion thread.

The major benefit of this for the authoriser is that it allows records to be held, thus removing the need to manage, transmit, read and file constant email communications.

665

In Built Discussion Thread

The approval process consolidates all communication between the authoriser, traveller and TMC through a single portal, thereby reducing the amount of emails going back and forth (see Fig. 6). 670

All communication is stored and can be accessed via the portal at any time. This process is applied for all pre-trip approval.

Travel Booking

675 The booking process in the pre-trip portal is TMC agnostic. The preferred TMC consultant has the ability to log in to the system to view trips and notify that a booking has been placed.

This eliminates dealing with complex international bookings with an online portal. The pre- 680 trip system builds an itinerary which is automatically sent by the corporate to the TMC for the TMC to then complete the booking with all the data of approved airlines, destination information along with all compliance checks and recommendations included to act as a purchase order with all required information to the travel consultant.

685 This helps to create a more efficient and effective booking process with less reliance on phone call and email correspondence; thus saving both time and money.

In the case of a traveller contacting the TMC to change a booking, the technology runs a check that would recognise this (using the GDS) and automatically notifies the authoriser of 690 the change in trip; thus allowing intervention by the authoriser to cancel or modify the trip.

Post-Trip Reporting

The post-trip reporting has the ability to consolidate all data captured allowing for a full analysis on all travel data.

695

Reports include (but are not limited to);

Dynamic Dashboards

Authorised Travel

Travel Locations

700 Lead In Days

Top Travellers Domestic Travel Detail

International Travel Details

Booking Trends

705 And many other custom reports

System Architecture

The systems are designed to create maximum interoperability between services.

The system architect is designed for maximum interoperability to allow the use of third- party data providers and to allow for future providers to be adapted into the system.

All areas of the travel process is connected to the central data store allowing for cross checks on data alerting of travel issues and making sure the traveller and authoriser are aware of all the issues associated with travel.

Module Functionality

The Pre-Trip Solution supports the following processes/tasks for both domestic (local) and international pre-trip approval:

720

Viewing contact information

Cross checking any proposed itinerary against: authorised procedures, travel profile, security safety net services (Control Risks Group, ISOS, BARS, Hart Aviation etc.);

Verification of any Visa, medical or other requirements;

725 Submission of proposed and approved travel itinerary to an Approver;

Approval/rejection of request by Approver;

Confirmation of the trip to be sent to the TMC for the TMC to fulfil;

Feeding off PNR to approved linked travel tracking and employee duty of care support resources;

730 Printing of approved trip to traveller; and

Assisting traveller with post trip reporting.

The portal also serves the functionalities of: Assist in the control and monitoring of travel authorisation;

735 Integrate vendor pre-trip approval workflow to assist in compliance with policy and practice;

Support system administration

Provide end-to-end tracking of travel plans and traveller location status reporting.

Save and maintain all details related to a particular pre-trip and facilitate the re- 740 authorisation of a trip when a change permits

Be a simple, easy to use tool;

Giving instruction to the TMC for the TMC to ticket

The pre-trip portal comprises of the following characteristics:

745

An easy to navigate and intuitive tool, with logical and well presented screen information that can be quickly viewed and assessed;

A user friendly tool that can be used effectively without formal training and which has functionality that is apparent when first encountered;

750 Screens with appropriate use of icons and similar meaningful graphics to improve screen presentation and speed of user understanding of functions;

Company specific logos and screen presentation style to give the impression to the user of accessing a tool that has been customised;

Screen presentation that reflects the logic and flow of the pre-trip authorisation 755 process;

Maximized use of default information to populate fields

A minimal number of keypad inputs and the optimal number of mouse-click selections; The minimal number of screens to be accessed to undertake any task consistent with logical and readable presentation of information and a minimal need to scroll in 760 order to view information;

Fast, accurate, timely free upgrades of new features and functionality

Traveller Profiles The system integrates with third party HR systems for profile management. In the event a 765 profile is missing, the in-built profile system can be used to house all data attaining to the pre-trip details.

All Traveller Profile data is managed to meet security and compliance requirements for personal/confidential information and privacy issues.

770

In order/to meet the needs of Security Compliance Programmes, the pre-trip portal provides the ability, if required, to store traveller and company data outside of the corporation's supplier host systems.

775 User Help

The solution includes easy to use online user functionality to allow any user to quickly identify how to complete a task.

The User help/advice and information enables the User to effectively use all the 780 functionality and understand the context of the use of the portal without recourse to external assistance.

Intuitive user interface design and tool tip guides are available to ensure the user can navigate through the site with little to no assistance.

785

Controls and Warnings

The system includes:

Controls to minimise trips made in contravention of the corporates pre-trip rules; User messages/warnings to facilitate compliance with best practice for the use of the ^' 790 corporate's policy or business rules;

User messages to ensure that a user is fully aware of the task that has been completed and notification of instances where a task has not been completed;

Validation mechanisms, to optimise the quality of data input and ensure that mandatory data is entered. Approval Recording

The system stores and provides access to the full history of all trip authorisation requests, including:

Facilitation of the recording of every instance of travel approval

800 Capturing data that would uniquely identify each approval by;

Time,

Approver,

Booker,

Traveller

805 And basic travel information.

Queries/Reporting

The system is able to provide a technical solution for a full range of viewing and reporting functions and as a minimum provide:

810 Quick queries to view and print historical, current and future approvals;

General information for Travellers and Bookers;

View and print from selected information for Travellers and Bookers;

Management information reports to enable monitoring of compliance;

Management information reports to provide travel activity or raw data/customised 815 extracts of travel activity by traveller

Exemplary workflows.

Fig. 13 describes the process of a pre-trip cost and approval process with a travel consultant 820 . A traveller (or travel arranger) may submit a proposed trip for approval. The traveller / arranger selects a workflow to begin the trip request 300, and completes 302 an initial travel itinerary including trip details, purpose, cost centre responsible for travel expenses and (optionally) any group booking information where the traveller is part of a group.

825 The traveller / arranger may provide further travel requirements 304 which may be customized for the particular workflow. The travel request is submitted 306 to an approver, the approver receiving details of the request by email 308. The trip may require to be edited (for example to increase or 830 decrease duration for business reasons), in which case it is returned to the traveller / arranger for input of amended details 302.

Where no editing is required, the request is considered for approval. If approved, the traveller is notified 310 and the request considered for satisfying further criteria 312. If the 835 pre-trip request is declined the traveller is notified 314. Alternatively, the approver may need further information to make a decision in which case the approver enters a message 316 into a chat feed with the traveller, a notification 318 of the need for discussion being forwarded to the traveller.

840 Upon approval by the approver, the request may be checked to determine whether the proposed trip includes travel to a country having a high risk status 312. Where that check is negative, a further approval is gained and the traveller notified 320, and provided with an itinerary and travel authorization code.

845 Where a high risk status country is identified the approver receives a pre-trip approval email

322, and the trip may be edited to avoid that country or the request cancelled. Where the trip is not edited, the approver may nevertheless further consider the request and provide approval by, notification 320. Where the trip is not edited, the request may be declined with the traveller receiving notification 324 and the traveller being permitted to amend the

850 original request. The approver may enter a message into a chat feed 326, and the traveller notified 328 that discussion is required.

After approval, further editing of the trip may be allowed (typically minor changes, for example departure times), and the approved trip details are passed to a travel management 855 company. The travel management company makes contact with the traveller to ensure that the itinerary is ideal (or at least acceptable) using TMP messages 330. The travel management company then uploads 332 the itinerary to multiple travel providers to obtain quotes. 860 One or more quotes are then subject to cost approval 334, with an authorizer 336 receiving the quotes 342. Simultaneously, a cost centre authoriser 338 receives the quotes 346, as does a business unit authoriser 340, 348. Any of the authorizers 336, 348, 340 may require editing of the trip for reasons of cost.

865 Where no editing is required, details of the itinerary and cost are passed for approval action

350, or other action where the itinerary is not approved. Where approved, the traveller is notified 352 of the approved itinerary and the travel management company is notified 354 of which quote to accept and place booking. Where all quotes are declined, the travel management company is notified 356. Where further discussion is required, the travel

870 management company is notified 358. At any point post authorisation the travel consultant may add a new itinerary or remove an existing itinerary for authorisation. This process can also be configured with integration into travel systems automating the pushing itinerary data through to replace the need for any manual intervention.

875 A further alternative approval action is to select a new approver who may consider different parameters to any previous approver.

*

Where the travel management company is notified of the successful quote 354 the trip may be further edited. Where no further edits are required, the travel management company 880 makes the required bookings 360. In doing so, alteration to the itinerary may require a trip edit. A required trip edit may force cancellation of the entire trip, in which case the travel management company is notified 362. Otherwise, the traveller is notified 364 of the final itinerary and the trip booked 366.

885 Fig. 14 shows a workflow for a cost approval only process. Potential barriers to travel such as country status and the like are not considered.

The traveller / arranger selects a workflow to begin the trip request 400, and completes 402 an initial travel itinerary including trip details, purpose, cost centre responsible for travel 890 expenses and (optionally) any group booking information where the traveller is part of a group. The traveller / arranger may provide further travel requirements 404 which may be customized for the particular workflow. The travel request is then submitted 406, and may 895 be subsequently edited.

Where no editing is required, the request is considered for approval. If approved, the traveller is notified 410 by the travel management company and the travel management company 412 the itinerary to multiple travel providers to obtain quotes.

900

Trip request is then sent to travel consultant and one or more quotes are then subject to cost approval 414, with an authorizer 416 receiving the quotes 442. At any point post authorisation the travel consultant may add a new itinerary or remove an existing itinerary for authorisation. This process can also be configured with integration into travel systems 905 automating the pushing itinerary data through to replace the need for any manual intervention. Once quotes are submitted, a cost centre authoriser 418 receives the quotes 416, as does a business unit authoriser 420. Any of the authorizers 416, 418, 420 may require editing of the trip for reasons of cost.

910 Where no editing is required, details of the itinerary and cost are passed for approval action, or other action where the itinerary is not approved. Where approved, the traveller is notified 428 of the approved itinerary and the travel management company is notified 432 of which quote to accept and place booking. Where all quotes are declined, the travel management company is notified 434. Where further discussion is required, the travel

915 management company is notified 430.

A further alternative approval action is to select a new approver who may consider different parameters to any previous approver.

920 Where the travel management company is notified of the successful quote 432 the trip may be further edited. Where no further edits are required, the travel management company makes the required bookings 436. In doing so, so alteration the itinerary may require a trip edit. A required trip edit may force cancellation of the entire trip, in which case the travel management company is notified 438. Otherwise, the traveller is notified 440 of the final 925 itinerary and the trip booked 442.

The embodiment shown in Fig. 15 is similar to those of Figs: 13 and 14 except that an online booking tool is included in the workflow.

930 The traveller / arranger selects a workflow to begin the trip request 500, and completes 502 an initial travel itinerary including trip details, purpose, cost centre responsible for travel expenses and (optionally) any group booking information where the traveller is part of a group.

935 The traveller / arranger may provide further travel requirements 504 which may be customized for the particular workflow.

The travel request is submitted 506 to an approver, the approver receiving details of the request by email 508. The trip may require to be edited (for example to increase or 940 decrease duration for business reasons), in which case it is returned to the traveller / arranger for input of amended details 502.

Where no editing is required, the request is considered for approval. If approved, the traveller is notified 510 and the request considering for satisfying further criteria 511. If the 945 pre-trip request is declined the traveller is notified 512. Alternatively, the approver may need further information to make a decision in which case the approver enters a message 514 into a chat feed with the traveller, a notification 516 of the need for discussion being forwarded to the traveller.

950 Upon approval by the approver, the request may be checked to determine whether the proposed trip includes travel to a country having a high risk status 511. Where that check is negative, a further approval is gained and the traveller notified 526, and the traveller clicks a link on the notification email to receive itinerary and travel authorization code. The traveller then clicks a link 528 on the email taking them to an online booking platform.

955 Where approval is declined a notification 512 is sent to the traveller. Where discussion is required, the approver enters a message into a chat feed 514 and the user notified 516.

Where approved, a high risk status country is identified the approver receives a pre-trip 960 approval email 518, and the trip may be edited to avoid that country or the request cancelled. Where the trip is not edited, the approver may nevertheless further consider the request and provide approval by notification 526 also informing itinerary and travel authorization code. Where the trip is not edited, the request may be declined with the traveller receiving notification 520 and the traveller being permitted to amend the original 965 request. The approver may enter a message into a chat feed 522, and the traveller notified

524 that discussion is required.

After approval, and upon being taken to the booking tool 530, it will be noted that multiple booking tools 532, 534, 536 are offered. Depending on the traveller's company office, 970 profile or configuration they will be routed to the appropriate booking tool.

Data from TMP is carried across 538 to the booking tool to automatically sign a user into the tool and begin searching based on the data entered by a traveller / travel arranger when building an itinerary.

975

The traveller / arranger may select 540 segment options. The booking is then checked for conformance with corporate policy 542. If it does not conform 544 the booking with itinerary is loaded into TMP automatically awaiting approval. A cost approval process 550 is then followed with review by an authorizer 552, cost centre authorizer 554 and business 980 unit authorizer 556 who each receive the quotes 558, 560, 562. Any of the authorizers 552, 554, 556 may require editing of the trip for reasons of cost.

Where no editing is required, details of the itinerary and cost are passed for approval action, or other action where the itinerary is not approved. Where approved, the traveller is 985 notified 564 of the approved itinerary and the booking tool books the tickets and the trip is marked as booked 570. Where declined, the booking tool cancels the booking 566 and the trip is cancelled. Discussion may be required in which case a notification 500 is issued to the traveller. Alternatively, a new approver may be selected.

990 If the booking does conforms with corporate 546, the booking tool books tickets 570 and the trip is marked as booked.

Once tickets are booked 570 the traveller is notified 572 of the booked itinerary. Further trip edits may be allowed before the trip is booked 576. Alternatively, the booking may be 995 cancelled 574.

Fig. 16 shows a work flow for a cost approval only process incorporating an online booking tool. The traveller / arranger selects a workflow to begin the trip request 600, and completes 602 an initial travel itinerary including trip details, purpose, cost centre 1000 responsible for travel expenses and (optionally) any group booking information where the traveller is part of a group.

The traveller / arranger may provide further travel requirements 604 which may be customized for the particular workflow.

1005

The travel request is submitted 606 to booking tool 608, it will be noted that multiple booking tools are offered. Depending on the traveller's company office, profile or configuration they will be routed to the appropriate booking tool.

1010 Data from TMP is carried across 610 to the booking tool to automatically sign a user into the tool and begin searching based on the data entered by a traveller / travel arranger when building an itinerary.

The traveller / arranger may select 612 segment options. The booking is then checked for 1015 conformance with corporate policy 614. If it does not conform 616 the booking with itinerary is loaded into TMP automatically awaiting approval 620. A cost approval process 622 is then followed with review by an authorizer 624, cost centre authorizer 626 and business unit authorizer 628 who each receive the quotes 630, 632, 634. Any of the authorizers 624, 626, 628 may require editing of the trip for reasons of cost.

320

Where no editing is required, details of the itinerary and cost are passed for approval action, or other action where the itinerary is not approved. Where approved, the traveller is notified 638 of the approved itinerary and the booking tool books the tickets and the trip is marked as booked 640. Where declined, the booking tool cancels the booking 644 and the 325 trip is cancelled. Discussion may be required in which case a notification 646 is issued to the traveller. Alternatively, a new approver may be selected.

Once tickets are booked 640 the traveller is notified 642 of the booked itinerary. Further trip edits may be allowed before the trip is booked 648. Alternatively, the booking may be 330 cancelled 660.

The embodiment of Fig. 17 shows a work flow for a pre-trip approval only process, with both online and offline configurations.

335 The traveller / arranger selects a workflow to begin the trip request 700, and completes 702 an initial travel itinerary including trip details, purpose, cost centre responsible for travel expenses and (optionally) any group booking information where the traveller is part of a group.

340 The traveller / arranger may provide further travel requirements 704 which may be customized for the particular workflow.

The travel request is submitted 706 to an approver, the approver receiving details of the request by email 708. The trip may require to be edited (for example to increase or 345 decrease duration for business reasons), in which case it is returned to the traveller / arranger for input of amended details 702. Where no editing is required, the request is considered for approval. If approved, the traveller is notified 710 of the approved pre-trip and an email providing the itinerary and travel authorization code is provided.

Where declined, a notification 720 is forwarded to the traveller. Discussion may be required in which case the approver enters a message into chat feed 730 and a notification 740 is issued to the traveller. Alternatively, a new approver may be selected.

Pursuant to the notification at 710, the request may be checked to determine whether the proposed trip includes travel to a country having a high risk status 722. Where that check is negative 722, a further approval is gained and the traveller notified 724, the notification email also including itinerary and travel authorization code.

Where the request includes a high risk country, the approver receives a pre-trip approval email and clicks to review the request 726. The trip may be edited to avoid that country, and then sent for approval action. The edited request may be declined with the traveller receiving notification 742 and the traveller being permitted to amend the original request. The approver may enter a message into a chat feed 744, and the traveller notified 746 that discussion is required.

The present systems may comprise network connections between servers of any one or more of the traveller / travel arranger, a coordinating entity (such as Locomote™ travel management platform), a travel management company, a corporate, and an online booking company. Reference is made to Figs. 18 to 20 which show the various tasks carried out by the individual servers in the network for a range of activities viz; traveller profile creation (Fig. 18), profile amendment (Fig. 19) and profile deletion (Fig. 20). Central to the systems defined by Figs. 19 to 20 is the real time synchronization of servers of the coordinating entity and the online booking.

In the preceding specification, various embodiments have been described, and some with reference to the accompanying drawings. It will, however, be evident that various L080 modifications and changes may be made thereto, and additional embodiments may be implemented, without departing from the broader scope of the invention as set forth in the claims that follow. The specification and drawings are accordingly to be regarded in an illustrative rather than restrictive sense.

L085 Any text present in the drawings is included in the text of this description by reference. It will be understood that any feature or any combination of features disclosed in any of the drawings may form or comprise part of an embodiment of the present invention.

Reference throughout this specification to "one embodiment" or "an embodiment" is L090 intended to mean that a particular feature, function, structure or characteristic described in connection with the embodiment is included in at least one embodiment of the present invention. Thus, appearances of the phrases "in one embodiment" or "in an embodiment" in various places throughout this specification are not necessarily all referring to the same embodiment, but may. Furthermore, the particular features, structures or characteristics L095 may be combined in any suitable manner, as would be apparent to one of ordinary skill in the art from this disclosure, in one or more embodiments.

Similarly it should be appreciated that in the above description of exemplary embodiments of the invention, various features of the invention are sometimes grouped together in a L100 single embodiment, figure, or description thereof for the purpose of streamlining the disclosure and aiding in the understanding of one or more of the various inventive aspects.

This method of disclosure, however, is not to be interpreted as reflecting an intention that the claimed invention requires more features than are expressly recited in each claim.

Rather, as the following claims reflect, inventive aspects lie in less than all features of a L105 single foregoing disclosed embodiment. Thus, the claims following the Detailed Description are hereby expressly incorporated into this Detailed Description, with each claim standing on its own as a separate embodiment of this invention.

Furthermore, while some embodiments described herein include some but not other L110 features included in other embodiments, combinations of features of different embodiments are meant to be within the scope of the invention, and form different embodiments, as would be understood by those in the art. For example, in the following claims, any of the claimed embodiments can be used in any combination.