BaVelPay S.L.U (B-67506527)
[2022] APO 78
•30 November 2022
IP AUSTRALIA
AUSTRALIAN PATENT OFFICE
BaVelPay S.L.U (B-67506527) [2022] APO 78
Patent Application: 2019219863
Title:SYSTEM AND METHOD FOR FACILITATING TRAVEL PAYMENTS
Patent Applicant: BaVelPay S.L.U (B-67506527)
Delegate:Pradnya Satarkar
Decision Date: 30 November 2022
Hearing Date: Written submissions filed on 4 April 2022
Catchwords: PATENTS – examiner’s objection- manner of manufacture- automation of travel booking and payments- in substance directed to a mere scheme- alleged invention not a manner of manufacture- application refused
Representation: Patent attorney for the applicant: Griffith Hack
IP AUSTRALIA
AUSTRALIAN PATENT OFFICE
Patent Application: 2019219863
Title:SYSTEM AND METHOD FOR FACILITATING TRAVEL PAYMENTS
Patent Applicant: BaVelPay S.L.U (B-67506527)
Date of Decision: 30 November 2022
DECISION
The claims of the application, as proposed to be amended, do not define a manner of manufacture.
I do not see any subject matter in the body of the specification from which valid claims could be drafted to overcome this finding.
I refuse the application.REASONS FOR DECISION
Background
The Application (2019219863) was filed on 23 August 2019 in the name of Troovo Pty Ltd. The Application claims divisional status from Australian patent application no. 2017333594 (“Parent Application”), filed on 27 September 2017, which is the Australian National Phase Application of PCT application no. PCT/AU2017/051056, claiming priority from Australian provisional application no. 2016903907, filed 27 September 2016.
The Parent Application had four adverse reports issued on it, with the only objection being to the claims not defining a manner of manufacture in each of them. The Parent Application lapsed due to failure to gain acceptance.
The first examination report on the Application was issued on 22 September 2020 with the only objection to the claims not being for a manner of manufacture. A response to the examiner’s report was filed on 17 September 2021 and a hearing was requested on 22 September 2021. A second examination report was issued on 27 October 2021, with the only objection to the claims not being for a manner of manufacture.
Assignment of the Application to BaVelPay S.L.U (B-67506527) (“the Applicant”) was recorded on 15 December 2021.
The examination of the present application is governed by the Patents Act 1990 (“the Act”) as amended by the Intellectual Property Laws Amendment (Raising the Bar) Act 2012 (“the Raising the Bar Act”) as the application was filed after 15 April 2013. Thus, the standard of proof that applies in the present case is the balance of probabilities (subsection 49(1)). I must accept the application if satisfied on the balance of probabilities that the application complies with the Act. If I am not so satisfied, then I can refuse the application.
Pursuant to regulation 13.4(1)(g) when the Commissioner gives an applicant an opportunity to be heard in relation to an examiner’s objection and issues a written decision, the period for gaining acceptance of the application may be extended until three months from the date the decision is issued, or, pursuant to regulation 13.4(3), for a period of longer than three months if the Commissioner is satisfied that acceptance should be postponed.
The specification
Amendments to the specification were proposed on 01 November 2019. No new matter was added to the specification and no objection regarding the allowability of amendment was raised during the examination process. References to the specification in this decision relate to the specification as proposed to be amended.
The field of the invention is broadly summarised at the beginning of the specification as follows:
“The relevant technical field is computer system-based travel booking systems, and in particular travel booking systems to interwork with and integrate services of different travel suppliers and services including payment services.”[1]
[1] Specification, page 1, lines 15-19
The background of the invention lists different aspects of travel itinerary, for example, flights, transfers, accommodation, hire vehicles, tours, meal vouchers, tickets for attractions etc. It then goes on to explain the role of travel agents to coordinate travellers’ itinerary and bookings which is often by manually accessing a variety of different booking systems. It mentions that the travel agents typically facilitate travel payments by receiving pre-payment invoices or quotes from the various suppliers, and billing these to the traveller in a consolidated invoice which further requires significant manual reconciliation and processing. The background then notes that recent developments in internet-based travel booking systems have enabled travellers to plan and book their own travel online (without the need of travel agents). It then identifies some inconveniences associated with such systems:
“Such travel booking systems typically require payment up front using a credit card. But some aspects of travel costs are typically post-paid, such as payment of hotel accommodation at the conclusion of a stay, meals and incidental costs. A significant part of the cost overheads for corporate travel is associated with reconciliation of travel expenses incurred on a central billing account (whether it's a corporate credit card or other more sophisticated but similar solutions).
There is a need for improvements in systems for facilitating payments for different aspects of travel.”[2][2] Specification, page 2, lines 7-18
The specification includes consistory clauses which are mainly a repeat of the claims under ‘Summary of the Invention’.
The specification then provides an overview of the described systems and methods as follows (my emphasis):
“Systems and methods described herein provide a travel payment intermediary system configured to analyse travel booking data and identify itinerary item transactions eligible for virtual credit card (VCC) payments, and for each of these itinerary item transaction trigger generation of an appropriate VCC to affect payment.”[3]
[3] Specification, page 8, lines 21-26
The specification tries to distinguish the alleged invention from the current processes of using VCCs as follows (my emphasis):
“Virtual Credit Cards (VCC) enable creating a 1:1 match between the payment and the trip (or a component of the trip - e.g. a hotel stay). However, current processes for the use of the VCCs for travel bookings requires that a Travel Agent manually creates a VCC and assigns it to the booking (PNR - Passenger Name Record) or that the Online Booking Tool (OBT) used by the Traveller supports the creation of VCCs. The former adds extra complexity and unreliability to the process, defeating the underlying purpose of the VCCs. The latter requires third-party travel software tools to support individual banks' APIs and
this is not available for the majority of the OBTs currently used in the market.
The travel payment intermediary systems and methods disclosed herein advantageously automate the creation of the VCCs after the booking has been created by the Travel
Agent or by the Traveller directly.”[4]
[4] Specification, page 8, line 28- page 9, line 8
I note API to mean Application Programming Interface, Protocol for computer systems to exchange data.[5] API can also be understood as:
“An API is the interface that a software program presents to other programs, to humans, and in case of web APIs, to the world via the internet. An API’s design belies much about the program behind it-business model, product features, the occasional bug. Although APIs are designed to work with other programs, they’re mostly intended to be understood and used by humans writing those programs.”[6]
[5] Specification, page 61 (Acronym glossary)
[6] Designing Web APIs, Chapter 1- What’s an API, page 1, paragraph 3, accessible at >
A high-level block diagram of an embodiment of the alleged invention is illustrated in Figure 1, which I have reproduced below:
Figure 1
The specification explains that:
“The travel booking system interface 110 is configured to communicate with at least one travel booking system 120 used for a travel booking associated with at least one traveller, and obtain travel booking data for the at least one traveller. The booking data includes traveller data enabling identification of the at least one traveller and trip data defining one or more trip components of an itinerary for the at least one traveller. The booking analyser engine 116 is configured to analyse the obtained itinerary data and determine, for each trip component, cost component data associated with the trip component. The cost component data for a trip component includes virtual credit card payment eligibility for the trip component.
The virtual credit card (VCC) interface 114 is configured to generate a VCC request using the cost component data for a trip component where the cost component data indicates
eligibility for VCC payment. The VCC engine forwards the VCC request to a VCC issuing system, and monitors for receipt of a VCC generated by the VCC issuing system. The VCC is received by the VCC interface and in response the analyser engine is caused to associate the VCC with the trip component in the cost component data.”[7]I note GDS to mean Global Distribution System, Database and interface for searching, reserving and purchasing travel products (e.g. flights, hotels, cars)[8].
[7] Specification, page 9, line 20- page 10 line 5
[8] Specification, page 62 (Acronym glossary)
There does not appear to be any particular apparatus or architecture used to implement the claimed invention. The specification also admits:
“The system can be implemented using computer processing and memory resources in the form of one or more network connected servers and databases, these hardware resources
executing software programmed to implement the functions as described above. Alternatively the computer processing and memory resources may be network accessible distributed "cloud based" resources, executing software to implement the system functionality as described above. Some embodiments may utilise a combination of dedicated hardware and shared resources. A variety of different system architectures are contemplated within the scope of the present invention.”[9][9] Specification, page 10, lines 17-28
The process of booking the travel as per the alleged invention can be well understood with reference to Figure 2 which I have reproduced below:
Figure 2
The specification provides a thorough explanation of Figure 2 as follows (my emphasis):
“A traveller 210 can make enquiries and travel bookings via a Travel Management Company (TMC) 215 also commonly referred to as a Travel Agency, typically either by phone or face to face. The TCM (sic) agent will typically discuss the traveller's plans and lookup booking options via an agent interface to the GDS to query the GDS 230 for information such as availability. For example, the agent interface may be a software application operating on a computer system, such as an agent's desktop or tablet 215, having a data network connection to enable data communication with the GDS 230 via a communication network. In some instances the travel agent system may be a portal directly to the GDS without requiring an intermediary system or communication network.
The Travel Agent receives a request to make a booking for a Traveller. The Agent makes a booking for the flights, hotels and/or cars at the appropriate destinations, using the Traveller Profile stored in their booking systems. The source of the booking may be Global Distribution Systems (GDS - e.g. Amadeus, Sabre, Travelport etc.) or it may be performed through a supplier's system (e.g. airline's proprietary booking system, Expedia for hotel content etc.).
Alternatively the user 210 may access an online booking tool 220. Online booking tools are typically operate as an intermediary to one or more GDS systems, and provide software tools to allow users to browse different travel products and facilitate making reservations in the GDS. Most online booking tools aim to provide software services traditionally provided by human travel agents and allow travellers to manage their own bookings.
Via either an online interface 220 or an agent computer system 215 traveller data and booking information is entered into the GDS 230 and stored in a Passenger Name Record (PNR). Key data entered into the GDS 230 is traveller data and trip data. The Traveller Information is considered Personally Identifiable Information as it contains direct personal details of a traveller for each booking. This information can include data such as full
name, contact details and identification document details (for example, passport, social security number, driver's licence etc.). The traveller data is created and stored in the GDS as part of the travel booking (PNR). The Trip Information contains the travel details of the bookings. This information on its own does not contain Personally Identifiable Information. The trip data is created and stored in the GDS as part of the travel booking (PNR).The GDS can also store form of payment information, which can include credit card data. In the current manual workflow used in the travel industry, during the booking process, the Agent makes a decision which Form(s) of Payment to use for which parts of the transaction (e.g. American Express Business Travel Account for flights, corporate credit card for hotels, Traveller's credit card for cars, Invoice for fees etc.). In this traditional processing, for Virtual Credit Card (VCC) payment, the card issuer's VCC API must be integrated into the offline booking tool used by the Travel Agent (typically provided by the GDS they use).
In contrast, using the described travel payment intermediary system, during the booking process, the Agent is not required to decide or take any action in regard to which Form(s) of Payment are to be used, or to determine if different types of Form of Payments can be used for different parts of the transaction. In embodiments of the described system the determination of Form of Payment for each part of a transaction can be performed by the PNR Analyser 260 based on the Corporate Policy 265. An advantage of this is reduction of the work and capability required of the Agent (whether human or electronic i.e. an online booking tool). Further, the Agent need not communicate with a financial institution for requesting VCC. In the case of a human Agent there is no need to manually request a VCC. In the case of an Agent system tool (such as a proprietary/private online booking tool or offline booking tool used by human travel agents) there is no need to integrate with financial institutions for VCC generation. For example, for Virtual Credit Card (VCC) payment, the card issuer's VCC API 275 is not required to be integrated into the offline booking tool 215 used by the Travel Agent – in embodiments of the system this can be provided by the VCC Interface 270 after the booking is made. This has an advantage of significantly reducing the integration requirements for the Agent system (i.e. offline booking system) as functionality for both analysing the booking a data to determine Form of Payment for each component of the booking and generation of any VCC is handled via the travel payment intermediary system.
In another example the Traveller makes a booking directly for flights, hotels and/or cars through an Online Booking Tool (OBT). The source of the bookings may be GDS or third-party systems. In the current workflow used in the travel industry, during the booking process, the Traveller, depending on their corporate travel policy, may make a decision which Form(s) of Payment to use for which parts of the transaction. For VCC payment, the card issuer's API must be integrated into the OBT.
In contrast, using the described travel payment intermediary system, during the booking process, the Traveller 210 is not required to make a decision regarding which Form(s) of Payment to use for which parts of the transaction - this is decided by the PNR Analyser 260 based on the Corporate Policy 265. Further, for Virtual Credit Card (VCC) payment, the card issuer's VCC API 275 (for each card issuer to interwork with) is not required to be integrated into the OBT 220 used by the Traveller - this is provided by the VCC Interface 270 after the booking is made. As the booking analysis for Form of Payment and generation of VCCs is implemented in the travel payment intermediary system, this functionality need not be implemented nor maintained in the OBT 220.”[10]
[10] Specification, page 11 line 8- page 14 line 14
The system architecture is further illustrated in Figure 4 that I have reproduced below:
In very simple terms, each of these small rectangular blocks like PNR Writer (418) or PNR Analyser (426) represents ‘software modules running on a processor’ and each of the cylindrical boxes like PNR database (416) or main notification queue (444) represents ‘memory’ for storing data. Lines between these entities have arrows in the direction of data flow. For example- both the PNR Downloader (414) and PNR Writer (418) are configured for machine-to-machine communication with the GDS database interface (450) via the GDS API (412). PNR Downloader (414) retrieves booking data from the GDS and stores it in the PNR Database (416) for analysis. The PNR Writer (418) updates data in the PNR stored in the GDS via the GDS database interface (450).
The function of GDS API (412) is further explained in the specification as follows-
“Each GDS provides a machine-to-machine interface for exchanging data. The differences between these interfaces are significant in relation to connectivity, authentication, data structures and methods to read and write data, and these interfaces frequently change (e.g. to cater for a new type of travel product). Without the intermediary system GDS API 412, these differences would need to be coded into each component (PNR Reader and PNR Writer) separately and maintained on ongoing basis. The intermediary system GDS API 412 abstracts all of the differences and provides efficiency in changes and expansions to support additional GDSs only having to be maintained in one component: GDS API 412”.[11]
[11] Specification, page 17 lines 18-30
Figures 5a and 5b are illustrations of architecture of the present intermediary system and traditional system without GDS API respectively. The visual distinction between the two architectures is self-evident and I have reproduced both the figures below for ease of reference.
Figure 5c conceptually illustrates the GDS API functionality as reproduced below-
GDS API like any API acts like a middleman allowing interactions between various applications. In this case, the modules PNR Reader/Downloader (414) and PNR Writer (418) use a common message format that is GDS agnostic to request standard GDS operations (i.e. READ and EDIT) via GDS API. The request is translated into message format 590a-n appropriate for the destination GDS by translation function 585. Similarly, return messages in GDS specific format 590a-n are translated into the common format messages 580 for the PNR Reader/Downloader and PNR Writer.
The specification briefly discusses the kind of information stored in the PNR Database and the possibility of encrypting data as preferred embodiments. The specification then goes on to discuss various kinds of rules/policies that can be stored in ‘Corporate Policy Database’ (424) and used by PNR Analyser (422) to try to match against the Traveller(s) and Trip(s) Data and to assess eligibility for VCCs. An example of rules in Corporate Policy where the Corporation is a customer of the travel agency is-
“Use Corporate VCC for flight segment if
Traveller Job Status is "Contractor" AND
Airline Flight Location is "Domestic"
Use Corporate VCC for car segment if
Traveller VIP Status is "No" AND
Car Rental Name is "*Hertz*"
Use Corporate VCC for all trip segments if
(Traveller Project Code is "6-2*" AND
Traveller VIP Status is NOT "No") OR
(Traveller Quantity > 2 AND
Trip Duration >= 3)
Use TMC VCC for hotel segment if
Hotel Value >= 200”[12]
[12] Specification, page 26 lines 9-21
The specification then describes in detail the VCC manager (430 of Figure 4). The functionality of the four main modules of the VCC manager can be understood as follows:
If a VCC is required, determined by the PNR analyser in accordance with the relevant rules, a VCC Request is sent to the VCC Creator to generate a virtual credit card. The VCC Creator stores the VCC information in the VCC Queue. The VCC Interface checks the VCC queue at frequent regular intervals to retrieve all requests and sends them to VCC API to generate a VCC.
Various possible rules that define circumstances in which VCC request is to be sent to the different financial institutions are also discussed. For example- a rule may define that for the hotel stay the system will use the customer’s Amex arrangements and for the car rental it will use the customer’s ANZ Visa arrangements.
The specification also goes on to emphasize the advantage of VCC API (438) that provides a standardised interface for generating VCCs by abstracting the differences of each financial institution and providing efficiency in changes and expansions to support additional financial institutions. The implementation of VCC API is similar to that of GDS API discussed previously, such that a common format is provided for sending to all VCC issuing systems via the VCC API.
In summary, the two alleged advantages of the present system over traditional booking systems are as follows-
·The use of generic superset API (GDS API) in the present system provides a standardised interface for communicating with the different GDSs as opposed to each GDS using its own specific API in traditional systems creating compatibility problem where there is a need to interact with more than one type of GDS system.
·The automatic generation of Virtual Credit Cards (VCCs) and association of the VCCs with travel components such that the VCC details can be communicated for application to affect payments for the associated travel components simplifies the process of managing and reconciling travel expenses.
The claims
The specification ends with 12 claims with only two independent claims. Independent claim 1 is directed to a travel payment intermediary system and independent claim 12 is directed to a corresponding method of facilitating a travel payment executed by a travel payment intermediary system. The entire claim set is reproduced at Annex A of this decision. Claim 1 reads as follows:
A travel payment intermediary system implemented using computer processing and memory resources and configured to integrate with one or more travel booking systems and one or more external virtual credit card issuing systems using machine to machine communication via a communication network, the system comprising:
a travel booking system interface configured to communicate with at least one travel booking system to obtain travel booking data stored in the travel booking system of a travel booking associated with at least one traveller the booking data having been prepared using the travel booking system, the booking data including traveller data enabling identification of the at least one traveller, and trip data defining one or more trip components of an itinerary for the at least one traveller;
a booking analyser engine configured to analyse the obtained booking data and automatically determine, for each trip component, cost component data associated with the trip component and assess whether a virtual credit card payment method is accepted for the trip component; and
a virtual credit card (VCC) interface comprising a machine to machine (M2M) interface configured to utilise a generic superset API to communicate with one or more VCC supplier application programming interfaces (APIs), manage asynchronous requesting and receiving of VCCs and a queuing system comprising at least one temporary database, the VCC interface being configured to:
automatically generate a VCC request using the cost component data for a trip component where the trip component is assessed as payable using a VCC;
forward the VCC request to an external VCC issuing system via the communication network using the M2M interface;
store a copy of the transmitted VCC request in a database record in the queuing system temporary database, the database record including VCC request data and VCC request status;
monitor for asynchronous receipt of a VCC generated by the external VCC issuing system;
receive the VCC from the external VCC issuing system via the communication network using the M2M interface; and
in response to receiving the VCC from the external VCC issuing system, updating the database record with VCC details and the VCC status, triggering the analyser engine to associate the VCC with the trip component in the cost component data, and send, via
the communication network using the M2M interface, updated trip component data to the travel booking system to update the travel booking data stored in the travel booking system for the trip component to enable payment for the trip component using the VCC.
No issues regarding the construction or clarity of claims have been raised during examination. It is apparent that the travel booking system receives the travel booking data through a travel booking system interface, the booking analyser engine analyses the booking data and assesses whether a VCC payment method is accepted for the trip component, and the VCC interface manages asynchronous requesting and receiving of the VCCs. The independent claims do not describe the ‘Global Distribution System’ or the associated GDS API and are directed to the VCC generation part of the system.
The remaining objection
The objection of lack of manner of manufacture maintained in the second examination report is the subject of the applicant’s request to be heard and reads as follows:
Thank you for your response, I have considered it but it is not persuasive. Claims 1-12 do not define a manner of manufacture within the meaning of Section 18(1)(a) of the Patents Act 1990. The response disagrees with the characterisation in the previous report that the substance of the claimed invention lies in the scheme (a plan or program of action) to consolidate the operations between a plurality of travel booking systems connecting with a plurality of VCC issuing systems through the use of a single intermediary system.
While not explicitly suggesting an alternate substance of the invention the response states ”The applicant’s solution to these problems is a new intermediary system to introduce functionality that manages and provides a standardised interface for communication between multiple travel booking systems and financial systems for generating VCCs, and enable full automation of booking analysis, generation of the VCC financial instruments and associating these with the trip components” (emphasis mine). While the claimed invention is new and produces a practical and useful result this is not sufficient for the invention to be considered patentable subject matter.
In Commissioner of Patents v RPL Central Pty Ltd [2015] FCAFC 177 (RPL) [099], the Full Federal Court indicated several factors relevant to consider when determining whether a claimed invention as a matter of substance relates to patentable subject matter. These included:
· Is the contribution to the claimed invention technical in nature?
· Does the claimed invention solve a “technical” problem within the computer or outside the computer?
· Does the claimed invention result in an improvement in the functioning of the
computer, irrespective of the data being processed?
· Does the claimed invention merely require generic computer implementation? Is the computer merely the intermediary, configured to carry out the method, but adding nothing to the substance of the idea?
In weighing up the variety of factors which indicate what the substance of the claimed invention is and whether or not the claimed invention as a matter of substance relates to patentable subject matter, I have concluded that your claimed invention, as a matter of substance, does not relate to patentable subject matter. The response notes: “using VCCs can solve the business problem of reconciling travel payment – but current processes for utilising VCC are substantially manual and complicated, or through online booking tools (OBT) “requires third-party travel software tools to support individual banks' APIs and this is not available for the majority of the OBTs currently used in the market.” (emphasis mine). The claimed invention is also a third party tool which acts an intermediary between existing OBT systems and existing VCC systems so it is replacing one 3rd party tool with another.
The response goes on to state: “The specification also describes problems of excessive manual processing and system complexity to use VCCs with travel booking technology at the relevant priority date as background to the invention” However, the specification also discusses technical problems inhibiting integration of travel booking systems with VCC generation systems all from different providers, these include: Proliferation of proprietary systems and proprietary APIs requiring separate integration (see page 15 line 35 to page 16 line 2Proprietary Machine to machine interfaces which may frequently change, leading to incompatibility (see P16 lines 11-16)Requirement to integrate a VCC API for each VCC provider that a travel booking system want to use into the travel booking system (see p11 lines 22-26, page 32 lines 19-26)Increased complexity of travel booking systems to support and maintain multiple integrations VCC (page 33, lines 2-8)Further when introducing the intermediary system solution of the invention, managing asynchronous communications for VCC requests presents further problems (see page 27 lines 17-32)."
I believe the first four of these problems are business problems not technical problems with existing systems. While a proliferation proprietary systems and
proprietary APIs from multiple VCC providers can be considered a problem, it is a problem of excessive human effort needed in implementing multiple API communication rather than any underlying technical problem to be overcome in the implementation. The claimed invention allows communication between all of the proprietary systems and VCC providers by implementing all of the API’s. Similarly the claimed invention doesn’t reduce the number of proprietary machine to machine interfaces (or VCC suppliers) or affect how often the API’s may change. Furthermore, the claimed invention does not require changes to the end systems (as stated in the response “It is therefore an advantage of the present invention that it provides functionality to enable integration of these systems, in an automated end to end process, in a manner which essentially obviates the need for modification of the end systems” (emphasis mine). The complexity of a system to support and maintain multiple integrations with VCC API’s is not reduced or overcome by the claimed invention, the complexity is merely shifted to the claimed intermediary system.The fifth point alleges that when introducing the intermediary system solution of the invention, managing asynchronous communications for VCC requests presents further problems. Asynchronous communication is not new in this application. It is considered common general knowledge as is the manner in which the claimed invention implements the communication (as per page 27 lines 17-32).
Page 3 of the response list the essential features of the claims, namely:
· a machine to machine (M2M) interface configured to utilise a generic superset API
· a queuing system comprising at least one temporary database to manage asynchronous communication
· a precisely delineated series of steps of operations (a scheme) performed by the intermediary system to perform end to end automation
These features when considered individually and in combination do not overcome any technical limitations, Therefore, they are not a technical solution or technical improvement to computer systems. The configurations described are connecting various generic computer systems. The combination consists of a first computer (intermediary system) connected to a second computer (an OBT system) wherein data entered at the second computer is sent to the first computer for analysis and display, and the first computer communicates with a third computer (a VCC system) to also send and receive data. This combination represents standard networked computer architecture used to gather, send and receive data.
The response states: “a contribution by the inventors is how to implement automated VCC generation for travel bookings using computer technology and the intermediary system functionality”. However, I cannot agree that the contribution by the inventors is how to implement automated VCC generation because the invention as claimed does not claim any particular implementation. All that is claimed is the series of steps the virtual credit card interface is configured to perform, the steps of:
· automatically generate a VCC request
· forward the VCC request to an external VCC
· issuing system
· store a copy of the transmitted VCC request in a temporary database
· monitor for asynchronous receipt of a VCC generated by the external VCC
issuing system
· receive the VCC from the external VCC issuing system
· in response to receiving the VCC, updating the database record with VCC
details and the VCC status.
The claim requires automated generation of VCC’s through communication with the VCC supplier but how that is implemented is not claimed. It is left entirely to those wishing to use the method to devise, and then to implement, suitable computer programming for that purpose.
The virtual credit card interface utilises a generic superset API to communicate with one or more VCC supplier application programming interfaces (APIs), this is merely a collocation or consolidation of all of the existing VCC APIs. As has been noted, the claimed system obviates the need for modification of the end systems. Therefore, the end systems must be communicating using their existing APIs.
The response states “The inventors have provided a concrete practical solution for automating VCC generation for travel bookings” I respectfully disagree. The specification acknowledges that existing travel booking systems and Bank’s VCC system have existing machine to machine interfaces and API’s, the claimed invention use’s those existing M2M interfaces and API’s for VCC generation and is collocating or consolidating the implementation of this functionality into a single system to relieve the many travel booking systems of the need to programme their own implementations for each VCC API.
The invention defined by claim 1 as proposed to be amended is a system having three areas-booking website, VCC website and an intermediary; in which certain actions in relation to the booking of a trip component, analyse the booking, send a VCC request, and generate a VCC to pay for the trip component, occur respectively. The information gathered in each area is collected and linked together. As is clear from figures, the present invention includes computers and associated hardware. To that extent some of the language used in RA, RPL, Encompass and Rokt dealing with computer-implemented inventions, is directly applicable. Specifically, the principles of looking to the substance of the invention and considering the inventors contribution to the invention are applicable.
As discussed above the substance of the claimed invention lies in the scheme (a plan or program of action) or to use the words of the response "a precisely delineated series of steps" to consolidate the operations of a plurality of travel booking systems connecting with a plurality of VCC issuing systems using a single intermediary system through which all communication flows. While the specification provides some degree of specificity about what fields of data are communicated or stored at each stage, the claims define what steps are performed but does not claim how particular implementations of the automation are done such that a technical improvement/solution can be seen.
The claimed invention, as a matter of substance, is a scheme, a set of steps or instructions that a person skilled in the art can programme a generic computer to perform. Therefore, the objection that that claimed invention, including all features of all dependent claims, as a matter of substance, does not define subject matter suitable for a patent is maintained.The Law on Manner of Manufacture
Section 18 of the Patents Act 1990 sets out necessary conditions for a patentable invention. Among others, the invention must be ‘manner of manufacture within the meaning of section 6 of the Statute of Monopolies’.
The High Court in the landmark case of National Research Development Corporation v Commissioner of Patents, set out a test defining a patentable process based on the facts of the case:
“The point is that a process, to fall within the limits of patentability which the context of the Statute of Monopolies has supplied, must be one that offers some advantage which is material, in the sense that the process belongs to a useful art as distinct from a fine art…that its value to the country is in the field of economic endeavour”.[13]
[13] [1959] HCA 67; 102 CLR 252 (“NRDC”) at [22], 275
However, the High Court has not suggested any rigid formula to be applied unthinkingly. As is clarified in D’Arcy v Myriad genetics Inc:
“This Court in NRDC did not prescribe a well-defined pathway for the development of the concept of ‘manner of manufacture’ in its application to unimagined technologies with unimagined characteristics and implications. Rather, it authorised a case-by-case methodology.”[14]
[14] [2015] HCA 35; 258 CLR 334 at [23] (“Myriad”).
This case-by-case methodology requires consideration of the substance of the claimed invention, not simply the form of the claim. This point was made succinctly in Myriad by Gageler and Nettle JJ:
“Whatever words have been used, the matter must be looked at as one of substance and effect must be given to the true nature of the claim.”[15]
[15] Myriad at [144].
Overtime, to assess patentable subject matter in the context of computer implemented inventions, a range of principles have been developed. These principles were usefully summarised by Robertson J in Rokt1 as follows:
“The respondent submitted that the law as laid out in Research Affiliates and RPL Central held that:
17.1 The Court must decide, as matter of substance not form, whether the claimed invention is the proper subject-matter for a patent: RPL Central at [99]; Research Affiliates at [106], [117].
17.2 This requires consideration of both the claims of the Application and the invention described in the body of the specification: RPL Central at [114].
17.3 The assessment is not done mechanically. There are no precise guidelines or mathematical formula. It is “a question of understanding what has been the work of, the output of, and the result of, human ingenuity” and then applying the developed principles: Research Affiliates at [116]. See further RPL Central at [112]:
Recognising that the claims are to a method and system comprising a combination of integers, it is necessary to understand where the inventiveness or ingenuity is said to lie ...
17.4 One well-settled principle is that a distinction exists between a technological innovation and a business innovation. A technological innovation is patentable. A business innovation is not: Research Affiliates at [94]; RPL Central at [100]. Consequently, a business method or scheme is not, per se, a proper subject for letters patent: RPL Central at [96]. Nor are abstract ideas, mere intellectual information or mere directions for use patentable: Research Affiliates at [101]; RPL Central at [100].
17.5 A computerised business method or scheme can, in some cases, be patentable. However, “[w]here the claimed invention is to a computerised business method, the invention must lie in that computerisation”: RPL Central at [96] (emphasis added). This requires “some ingenuity in the way in which the computer is used”: RPL Central at [104]. It is not a patentable invention “to simply ‘put’ a business method ‘into’ a computer to implement the business method using the computer for its well-known and understood functions”: RPL Central at [96]. In other words, if the ingenuity lies in the business method or scheme alone, the invention will not be patentable despite the computer-implementation.
17.6 Thus, a claimed invention must be examined to ascertain whether it is in substance a scheme or plan, or whether it can broadly be described as an improvement in computer technology: RPL Central at [96]. Contrary to [the applicant’s submissions at [49]], this is a binary distinction: the invention is either an unpatentable scheme or plan, or it is a patentable improvement in computer technology. In conducting the analysis, it is useful to:
17.6.1 ascertain whether the contribution to the claimed invention is technical in nature: RPL Central at [99], Research Affiliates at [114];
17.6.2 consider whether the invention solves a “technical” problem within the computer or outside the computer: RPL Central at [99]; Research Affiliates at [103];
17.6.3 consider whether the invention results in an improvement in the functioning of the computer, irrespective of the data being processed: RPL Central at [99], Research Affiliates at [118];
17.6.4 consider whether the invention requires merely “generic computer implementation”, as distinct from steps which are “foreign” to the normal use of computers: RPL Central at [99], [102]; Research Affiliates at [101]; and
17.6.5 consider whether the computer is merely the intermediary, configured to carry out the method using program code for performing the method, but adding nothing to the substance of the idea: RPL Central at [99].”[16]
[16] Rokt Pte Ltd v Commissioner of Patents [2018] FCA 1988 (“Rokt1”) at [189]
These principles were accepted by Robertson J.[17] Even though Rokt1 was later overturned by the Full bench of Federal Court in Rokt2[18], it was not due to any error in the principles themselves. These general principles remain relevant in view of subsequent decisions.
[17] Rokt1 at [201]
[18] Commissioner of Patents v Rokt Pte Ltd [2020] FCAFC 86 (“Rokt2”)
The Full Court in Encompass Pty Ltd v InfoTrack Pty Ltd[19] concurred with the principles set out in RPL Central and Research Affiliates, explaining that:
“In each case, the Full Court was seeking to describe the conceptual distinction between a manner of manufacture and an unpatentable abstraction. In each case, the Full Court was explaining that a claimed method that is unpatentable does not change its legal character merely because the method is implemented by the instrumentality of a computer.”[20]
[19] [2019] FCAFC 161at [7] (“Encompass”).
[20] Encompass at [91].
More recently, the Full Court in Commissioner of Patents v Aristocrat Technologies Pty Limited[21] found that a game implemented on an electronic gaming machine was not patentable. On appeal to the High Court, the Court was evenly split, and pursuant to s 23(2)(b) of the Judiciary Act 1903, the appeal was dismissed, and the decision of the Full Court was affirmed. As such there is no binding precedent resulting from the High Court decision and the other Full Court decisions in this area (discussed above), including Research Affiliates, RPL Central, Encompass, Rokt2 remain undisturbed. All six members of the High Court treated those decisions as having been correctly decided.[22] I note, however, that both sets of reasons from the High Court decision[23] suggest a need for some caution in relation to the consideration of ‘advance in computer technology’ as part of the two-step analysis proposed by Middleton and Perram JJ in Aristocrat’21[24]. In particular, the reasons of Kiefel CJ et al. point to the concept of an adaptation to computer technology as being a useful consideration. Nonetheless, the principles developed around the patentability of an invention in the earlier Full Court cases are preferred over the two-step analysis of Aristocrat’21.
[21] [2021] FCAFC 202 (“Aristocrat’21”)
[22] Aristocrat Technologies Australia Pty Ltd v Commissioner of Patents [2022] HCA 29 at [29], [121-122]
[23] Ibid at [77], [122]
[24] Aristocrat’21 at [26]
Consideration
I have used the considerations from Rokt1 to assess the patentability of the alleged invention. In doing so, I have had regard to the applicant’s submissions as they relate to those considerations.
Does the invention solve a technical problem within the computer or outside the computer?
The applicant submitted that:
“…in relation to the SABRE system of the prior art, travel agents need to open a portal to the financial institute system to manually request a VCC and wait for this to issue with this portal open to receive the VCC. Whereas in an asynchronous system communication the request is sent without a requirement to hold communication open for a reply, the reply (issuance of VCC) is received in an independent signal (which may be after some time delay) necessitating management of these replies. In the claimed system the solution is using the queuing database. This asynchronous signalling enables efficient automation of the request. Thus, a technical innovation in this art”.[25]
[25] Written submissions, paragraph [39]
Thus, the applicant alleged that the use of asynchronous system for generating VCCs in the present application makes it more efficient than the prior art’s use of synchronous system. The applicant further mentioned that a problem with the asynchronous systems is that of managing received replies at different times. In the present application, this problem is solved using queuing database. I note that the said problem in asynchronous system is present by the very virtue of how the asynchronous systems function. The specification as discussed is accepting of the known limitations and resolution to the limitations of using asynchronous APIs. It can be inferred that the choice between synchronous and asynchronous APIs is based on the functionality requirement in a system as both synchronous and asynchronous APIs have their own set of advantages and disadvantages. Choosing one of the two kinds, for its specific known functionality cannot be considered as solving a technical problem within a computer in the sense used by the Courts.
The applicant also submitted:
“the problem solved by the invention is not one of simply noting the need for a new system where one did not previously exist. The problem is better formulated as how to utilise computer technology to enable integration and automation of generating and applying VCCs to travel bookings.”[26]
[26] Written submissions, paragraph [41]
I accept that this is a reasonable characterisation of the problem addressed in the specification. As per my discussion of the specification above, the specification explains determining whether VCC is required for a trip component based on certain rules stored in the memory and then sending those VCC requests to the VCC API which interacts with different financial institutions (the selection of the financial institutions is also based on the pre-set rules) to generate VCC. While computer systems are used in this automation process, and there is a high-level description of how various functional modules interact with each other and memory component, there is no suggestion in the specification about what, if any technical problem within or outside the computer has been solved to arrive at the claimed invention.
The applicant further referred to Advanced New Technologies 1[27] while attempting to draw analogy with the present application and states:
“…it addressed a business problem, however this was not found determinative as the claimed solution involved application of technology to enable practical and useful results – improved security for information stored in a block chain. We submit that the presently claimed invention is also an application of technology to enable practical and useful results and as such is for a manner of manufacture for reasons consistent with those of the Advanced NewTechnologies 1 decision.”
[27] Advanced New Technologies Co., Ltd [2021] APO 29, (“Advanced New Technologies 1”)
I will discuss Advanced New Technologies 1 in more detail below. However, at this stage it suffices for me to accept that the presence of a technical problem is not the only consideration to determine whether the claimed invention is for a manner of manufacture. While acknowledging that there is no technical problem identified in the present specification, I will move on to consider other factors.
Does the invention result in improvement in the functioning of the computer, irrespective of the data being processed?
The applicant submitted:
“We refer to paragraphs 83-85 of Facebook, in which functionality of the computer (in that case, a mobile device) was improved by providing a workaround to the device’s inherent sandboxing structure, enabling the device to do something it could not previously. The present invention is similar because it solves an inherent deficiency in travel booking system technology, requirements to log into the VCC systems to wait for VCC generation forcing manual intervention, which is solved by the queuing of asynchronous communication during VCC generation by the intermediary system. The claimed intermediary system enables functionality that did not exist before. We submit (sic) is for a manner of manufacture for reasons consistent with Facebook.”[28]
[28] Written submissions, paragraph [50]
I note that in Facebook, Inc.[29], the delegate concluded that the invention resulted in improving the functionality of the mobile device due to the invention providing a work around the architectural limitation of sandboxing of native applications. The invention in Facebook allowed the mobile device to do something it could not do previously. Here, it is worthwhile to emphasise the difference between an invention allowing a computer to do something it could not do previously from an invention utilising a computer to do something it had not done previously. While the former is in the category of improvement in or adaptation of the functioning of the computer, the latter may merely be a ‘new’ function implemented on the computer.
[29] [2020] APO 19 at [53-55], (“Facebook”)
This difference is also explained in Rokt2[30]:
“It is axiomatic that a change in software can modify the operation of a computer. In each of RPL Central, Research Affiliates and Encompass, the fact that software was used to perform a different and new function was not of itself sufficient to found a conclusion that there was a technical advance in the use of computers such that a mere business scheme was patentable because of its means of implementation.”
[30] Rokt2 at [98]
The present specification does not identify any limitation or deficiency in the existing computer systems that is overcome by the alleged invention. The inherent deficiency in travel booking system technology, as remarked upon by the applicant is the limitation of using synchronous APIs. Asynchronous APIs overcome the problem of waiting for the return signal (VCC generation, in this case). The applicant neither explains why asynchronous APIs could not be used in the travel booking systems before nor elaborates on how (if, at all) the computer was improved/modified to allow the use of asynchronous APIs in the present system. Hence, I conclude that the invention does not result in any improvement in the functioning of the computer.
Are there any steps foreign to the normal use of computer?
The idea of identifying steps foreign to the normal use of computer was discussed in IBM[31] where Burchett J found:
“Although there was nothing new about the mathematics of the invention what was new was the application of the selected mathematical methods to computer, and, in particular, to the production of the desired curve by the computer. This involved steps which were foreign to the normal use of computers and, for that reason, were inventive. A method of producing that by computer, which is novel and inventive, is entitled to the protection of the patent laws.”
[31] International Business Machines Corporation v Commissioner of Patents (1991) 22 IPR 417, (“IBM”)
As elaborated by the Deputy Commissioner in Accenture Global Solutions Limited[32]:
“The use of floating-point arithmetic was common for processing such algorithms for generating curves. This invention however, claimed that calculations were performed without the use of floating-point arithmetic, that is, using fixed point or “integer” arithmetic. At the time of the invention, it was new and non-obvious to perform such mathematical algorithms in a computer, using something other than floating point arithmetic. This integer arithmetic, as described in the specification, comprised a particular way of performing calculations using components in a computer that changed the way a computer normally worked in the relevant context. It followed that the claim was directed to a process containing steps that were foreign to the normal use of computers.”
[32] [2022] APO 8 at [42]
The present specification discusses functional steps of automating the generation of VCCs by using superset APIs. As discussed in detail above, the specification mentions the use of generic superset GDS API to provide a standardised interface for communicating with the different GDSs and VCC API to communicate with different financial institutions to generate VCCs. As by very definition, APIs are used to abstract the differences of various entities by providing a common format for data transfer among them. There is no indication throughout the specification of using the computer to perform steps foreign to the normal use of computers.
Is the computer merely an intermediary or tool for performing the method while adding nothing of substance to the idea
The Applicant submitted:
“A key difference between the nature of the present invention when compared to that in Research Affiliates, RPL Central, Encompass, and Rokt, lies in the technical contribution it makes to enable the business method of automating generation and allocation of VCCs to travel bookings by expressly claiming functionality to this end. In these earlier decisions, the claims were instead directed towards the business method/scheme itself, and the computer was merely an intermediary facilitating the non-patentable subject matter. That is, the claims in these earlier cases were defined by an instruction to use a computer to implement the novel method, without anything more. However, as is clear, the computer for the present invention is integral to the invention as claimed. The present invention is not merely an instruction to implement a business scheme with the claims and specification leaving entirely to those wishing to use the method to devise and implement a suitable computer program for purpose.”[33]
[33] Written submissions, paragraph [47]
I do not find the applicant’s arguments regarding the difference between the nature of the presently claimed invention and that of the inventions referred in the earlier Full Court decisions convincing. Both the categories require some business methods to be implemented on a computer. A business method claimed as a functionality rather than instructions to use a computer does not change its legal character. I note that both require writing a code to implement the said functionality or instructions. The present invention like the inventions referred in earlier Full Court decisions, fails to identify any technical problem overcome in the computer implementation.
It appears that the applicant’s use of the term ‘integral’ is in line with that used by Robertson J in Rokt1[34] which was later overturned in Rokt2:
“However, the question is not simply whether the claimed invention could not be implemented other than by the use of computers. That fact of itself is not sufficient, as the Full Court in Encompass observed at [91]. A claimed method that is unpatentable does not change its legal character merely because the method is implemented by the instrumentality of a computer.”[35]
[34] Rokt1 at [53-55]
[35] Rokt2 at [99]
The present invention is to the process of automating the generation of VCCs, and although I accept that it can only be implemented using computers, that alone is not sufficient to confer patentability to the business method. This idea is well elaborated in RPL Central[36]:
“Where the claimed invention is to a computerised business method, the invention must lie in that computerisation. It is not patentable invention simply to “put” a business method “into” a computer to implement the business method using the computer for its well-known and understood functions.”
[36] Commissioner of Patents v RPL Central Pty Ltd [2015] FCAFC 177 at [96]
As discussed above, there is no invention in the computerisation; the computer is merely an intermediary for performing the business method.
Is there a practical and useful effect?
The applicant submitted that the claimed invention enabling end-to-end automation of generating and adding VCCs is a practical, useful effect. One may go on further to say that any computerisation or automation of a process is useful, however, the question to consider is whether this is useful in the relevant sense. As noted by the Deputy Commissioner in CareFusion 303[37]: “Not every result which might colloquially be considered useful is relevant. There needs to be a physical, tangible phenomenon coming into existence as mentioned at [114] of Research Affiliates[38] for an invention to be considered relevantly useful.
[37] CareFusion 303, Inc. [2021] APO 11 at [58]
[38] Research Affiliates LLC v Commissioner of Patents [2014] FCAFC 150, (“Research Affiliates”)
The applicant compared the present invention with that of Facebook, eBay[39] and Advanced New Technologies 1 to draw similarities between all. I have already discussed the differences between the present application with Facebook above.
[39] eBay Inc. [2020] APO 49
In eBay, the delegate identified a technical solution to the technical problem that resulted in producing a technical and useful result, not related to a business process or rules and concluded:
“In contrast to that defined in Research Affiliates, RPL, Encompass, and Rokt, the claims of this application clearly define more than an abstract idea. In combination the claims define changing the physical directions provided to a user based on at least the current time, a time to start or restart of the event and congestion along the route to get to the point of interest. The provision of physical directions for the user to take, as claimed, is not considered to be abstract or implementing a business process, but rather a physical and technical solution to a physical and technical problem that provides a practical and useful result.”[40]
[40] Ibid at [43]
In Advanced New Technologies 1, the delegate identified a technical solution provided to a business problem that was also considered to provide a practical and useful effect. The delegate noted:
“It is therefore clear that while not all of the steps of the claimed method can be considered to be technical steps, the critical steps of converting the transaction data into an indecipherable data abstract and then generating a transaction abstract based on digitally signed approvals from the transaction nodes involves the application of information technology techniques. On balance, when the claim is considered as a whole, I am satisfied that the claimed invention provides a technical solution to the problem of breach of privacy information.”[41]
[41] Advanced New Technologies 1 at [63]
On the contrary, the present invention does not appear to provide any technical solution. Neither does the process of automating the generation of VCCs by using a superset API can be considered to provide a physical and useful effect in the relevant sense.
Balancing the considerations
The invention can be characterised as automation of generating and applying VCCs to travel bookings. The invention does not solve any technical problem within or outside the computer, it does not involve steps foreign to the normal use of the computer, it does not result in any improvement to the working of the computer or a practical and useful effect in the relevant sense. The computer is merely a tool to affect the automation process.
Having regard to the complete specification, invention as claimed (in independent claims 1 and 12, along with dependent claims 2 to 11) and the above considerations, the substance or the ingenuity of the invention lies in mere automation of generating VCCs based on rules stored in the memory, by using asynchronous APIs, such that on receiving the VCCs, the trip component is updated for payment using the VCCs. This is an administrative scheme implemented on a computer system. The specification does not suggest any adaptation or alteration of the computer system in order to implement the scheme, indicating that the contribution to the claimed invention is not technical in nature. Hence, I find that independent claims 1 and 12 are not for a manner of manufacture. The dependent claims add features like application of rules to determine cost component of travel data or using another generic superset API to communicate with one or more GDS that are merely additional elements of the administrative scheme. Therefore, the dependent claims also are not for a manner of manufacture.
Conclusion
I conclude that the claimed invention is not for a manner of manufacture. Having reviewed the specification in detail, I can see no subject matter that could be made the subject of a valid claim to overcome this finding. I therefore refuse the application.
Pradnya Satarkar
Delegate of the Commissioner of Patents
Annex A:
1. A travel payment intermediary system implemented using computer processing and memory resources and configured to integrate with one or more travel booking systems and one or more external virtual credit card issuing systems using machine to machine communication via a communication network, the system comprising:
a travel booking system interface configured to communicate with at least one travel booking system to obtain travel booking data stored in the travel booking system of a travel booking associated with at least one traveller the booking data having been prepared using the travel booking system, the booking data including traveller data enabling identification of the at least one traveller, and trip data defining one or more trip components of an itinerary for the at least one traveller;
a booking analyser engine configured to analyse the obtained booking data and automatically determine, for each trip component, cost component data associated with the trip component and assess whether a virtual credit card payment method is accepted for the trip component; and
a virtual credit card (VCC) interface comprising a machine to machine (M2M) interface configured to utilise a generic superset API to communicate with one or more VCC supplier application programming interfaces (APIs), manage asynchronous requesting and receiving of VCCs and a queuing system comprising at least one temporary database, the VCC interface being configured to:
automatically generate a VCC request using the cost component data for a trip component where the trip component is assessed as payable using a VCC;
forward the VCC request to an external VCC issuing system via the communication network using the M2M interface;
store a copy of the transmitted VCC request in a database record in the queuing system temporary database, the database record including VCC request data and VCC request status;
monitor for asynchronous receipt of a VCC generated by the external VCC issuing system;
receive the VCC from the external VCC issuing system via the communication network using the M2M interface; and
in response to receiving the VCC from the external VCC issuing system, updating the database record with VCC details and the VCC status, triggering the analyser engine to associate the VCC with the trip component in the cost component data, and send, via
the communication network using the M2M interface, updated trip component data to the travel booking system to update the travel booking data stored in the travel booking system for the trip component to enable payment for the trip component using the VCC.
2. A travel booking payment intermediary system as claimed in claim 1 wherein the booking analyser engine is configured to, for each item of an itinerary, apply analysis rules to:
determine if a cost component is associated with the itinerary item, and
where a cost component is associated with the itinerary
item:
determine item value data, and cost timing data;
determine, for the cost component, payment types accepted and where the itinerary item cost component is VCC eligible generate VCC request data.3. A travel booking payment intermediary system as claimed in claim 2 wherein the booking analyser engine is configured to apply analysis rules to select a VCC supplier for a VCC eligible cost component.
4. A travel payment intermediary system as claimed in any one of claims 1 to 3 wherein the travel booking system interface is a machine to machine (M2M) interface configured to retrieve travel data from one or more global distribution systems storing traveller booking data.
5. A travel payment intermediary system as claimed in any one of the preceding claims wherein the travel booking system interface M2M interface provides a standardised interface for communication with each of the one or more GDSs using a generic superset application programming interface (API) for communicating with the one or more global distribution systems.
6. A travel payment intermediary system as claimed in any one of the preceding claims wherein the travel booking system interface is configured to periodically query each of the one or more travel booking systems to retrieve travel booking data.
7. A travel payment intermediary system as claimed in any one of the preceding claims further comprising a communication interface configured to provide generated VCC data to a destination associated with the trip component associated with the VCC.
8. A travel payment intermediary system as claimed in claim 7 where the generated VCC data is provided via a secure communication interface.
9. A travel payment intermediary system as claimed in claim 8 wherein the communication interface is configured to automatically transit the VCC data to a destination.
10. A travel payment intermediary system as claimed in claim 8 wherein the communication interface is configured to provide controlled access to the VCC data.
11. A travel payment intermediary system as claimed in claim 10 wherein the communication interface is configured to provide access to the VCC data for a limited period of time, the limited period of time being temporally associated with the trip component for which the VCC was generated.
12. A method of facilitating a travel payment executed by a travel payment intermediary system implemented using computer processing and memory resources and configured to integrate with one or more travel booking systems and one or more external virtual credit card issuing systems using machine to machine communication via a communication network, the method comprising the steps of:
obtaining travel booking data stored in the travel booking system the booking data having been prepared using the travel booking system, by a travel booking system interface configured to communicate with at least one travel booking system, the travel booking data being of a travel booking associated with at least one traveller, the booking data including traveller data enabling identification of the at least one traveller, and trip data defining one or more trip components of an itinerary for the at least one traveller;
analysing, by a booking analyser engine, the obtained booking data to automatically determine, for each trip component, cost component data associated with the trip component and assess whether a virtual credit card payment method is accepted for the trip component; and
for each trip component where the trip component is assessed as payable using a VCC, causing a virtual credit card (VCC) interface, comprising a machine to machine (M2M)
interface configured to utilise a generic superset API to communicate with one or more VCC supplier application programming interfaces (APIs), and a queuing system comprising at least one temporary database to manage asynchronous requesting and receiving of VCCs, to perform the steps of:
generating automatically a VCC request using the cost component data for a trip component;
forwarding the VCC request to an external VCC issuing system via the communication network using the M2M interface;
storing a copy of the transmitted VCC request in a database record in the queuing system temporary database, the database record including VCC request data and VCC request status;
monitoring for asynchronous receipt of a VCC generated by the external VCC issuing system;
receiving the VCC from the external VCC issuing system via the communication network using the M2M interface; and
in response to receiving the VCC from the external VCC issuing system, updating the database record with VCC details and the VCC status, triggering the analyser engine to associate the VCC with the trip component in the cost component data, and sending, via
the communication network using the M2M interface, updated trip component data to the travel booking system to update the travel booking data stored in the travel booking system to enable payment for the trip component using the VCC.
4
13
6