Amadeus S.A.S.
[2022] APO 76
•28 November 2022
IP AUSTRALIA
AUSTRALIAN PATENT OFFICE
Amadeus S.A.S. [2022] APO 76
Patent Application: 2016200417
Title:Undo/redo of database files for modifying re-accommodation
Patent Applicant: Amadeus S.A.S.
Delegate: Dr V. Z. Kolev
Decision Date: 28 November 2022
Hearing Date: Written submissions filed on 13 December 2021
Catchwords: PATENTS – sections 45 and 49 – hearing with respect to examiner’s objections – manner of manufacture – inventive step – computerised reservation systems for travel-related services – re-accommodation of travel itineraries due to schedule changes – modifying previous re-accommodation – business innovation – the claimed invention is not a manner of manufacture – no patentable subject matter described in the specification – inventive step not considered – application refused
Representation: Patent attorney for the applicant: Griffith Hack
IP AUSTRALIA
AUSTRALIAN PATENT OFFICE
Patent Application: 2016200417
Title:Undo/redo of database files for modifying re-accommodation
Patent Applicant: Amadeus S.A.S.
Date of Decision: 28 November 2022
DECISION
The invention claimed in each one of the claims, as proposed to be amended, is not a manner of manufacture. Furthermore, based on the matter described in the body of the specification, I am of the opinion that no allowable amendment could result in claiming a patentable invention. In light of this, I will not decide with respect to inventive step as this will be inconsequential.
I refuse the application.
REASONS FOR DECISION
Throughout this decision, unless explicitly stated otherwise, any reference to the Act, or to a specific section or subsection, refers to the Patents Act 1990, and any reference to the Regulations, or to a specific regulation or subregulation, refers to the Patents Regulations 1991. In addition, any reference to the Commissioner refers to the Commissioner of Patents as per the Act.
BACKGROUND
The matter relates to patent application 2016200417 (the Application) in the name of Amadeus S.A.S. (the Applicant). The Application was filed on 25 January 2016 as a Convention application claiming priority from EP 15 290 017.1 and US 14/604,977. The earliest claimed priority date is 26 January 2015.
The request for examination was filed on 16 December 2019 and the Application was subject to two examination reports as detailed below.
Examination report No. 1 was issued on 5 November 2020. The report contained objections with respect to manner of manufacture and inventive step. A response to the report was filed on 17 June 2021 together with a set of proposed amendments to the specification of the Application (the Specification). In this first statement of proposed amendments, the Applicant proposed, under item 1, amendments to the description.
Examination report No. 2 (the Last Report) was issued on 9 July 2021. In the report, the Examiner maintained the objections with respect to manner of manufacture and inventive step. No new objections were raised.
On 24 August 2021, the Applicant requested a hearing, which was conducted by way of written submissions.
SUBMISSIONS
On 13 December 2021, the Applicant filed a document titled “Written Submissions” (the Applicant’s Submissions or AS). At the same time, the Applicant filed a second statement of proposed amendments, in which the Applicant proposed, under item 2, amendments to the claims.
THE SPECIFICATION
The proposed amendments
It would appear that the amendment item 1 does not materially affect the Specification, and the amendment proposed under item 2 adds to the claims some clarifications and features from the description.
While I cannot see any immediate reasons why the amendments would not be allowable, I do not need to decide this conclusively as it will not affect the outcome of my decision. Suffice to say that, for the benefit of the Applicant, I will consider the Specification as proposed to be amended by the amendment items up to and including item 2.
The invention as described
The field of the invention and the shortcomings of the prior art
10. In the section “Technical Field”, it is stated that “[t]he invention generally relates to computers and computer software, and in particular to methods, apparatus, and computer program products that update files in travel-related databases to modify a previously executed re-accommodation” (paragraph [0001]).
11. The section “Background” explains that:
“[0002] A Computer Reservations System (CRS) typically comprises one or more networked computers or computer systems configured to store and retrieve information. The CRS may be configured to facilitate transactions related to air and train travel, hotels, car rental, or other travel-related services. A CRS that is capable of booking and selling tickets for services offered by multiple travel service providers may be referred to as a Global Distribution System (GDS). Typically, CRSs include or access multiple systems and associated databases that store information relating to the aforementioned transactions. These databases may include, for example, a Passenger Name Record (PNR) database for storing travel itinerary data, an Electronic Ticketing System (ETS) database for storing ticketing data, a Departure Control System (DCS) database for storing traveler check-in and service use data, and an inventory system database for storing availability data. These systems may comprise a processing and database system or apparatus for selling and managing the use of travel-related services.
[0003] Various types of schedule changes can disrupt booked travel itineraries, thereby prompting a need to rebook travelers with alternative arrangements. Exemplary events that may cause rebooking of travelers include flight schedule changes to re-optimize the airline network, routing and equipment changes, and flight delays or cancellations arising from mechanical problems with equipment, crew availability, or weather conditions. The process of modifying travel itineraries to account for schedule changes is sometimes referred to as a re-accommodation.” (underlining and bold added)
12. Later in the description, in the context of describing the instant invention, it is explained that:
“[0019] A travel itinerary may include one or more segments that connect an origin location and a destination location. In the context of air travel, a segment may comprise operation of a flight with a single flight designator between one point where travelers first board an aircraft (the boarding point) and another point where the travelers disembark the aircraft (the disembarkation point). … Thus, the travel itinerary may comprise a plurality of connected segments, with the traveler changing planes at each connection point between consecutive segments.
…
[0029] … Each PNR may comprise one or more reservation records each defining one or more reservations booked by the traveler. The PNR may also track usage of purchased travel services. The PNR may be identified by a record locator unique to that PNR, and may include records defining the travel itinerary for a particular trip, service, passenger, or group of passengers. The travel itinerary may include services from multiple carriers (e.g., seats on flight, bus, or rail segments), ancillary services from one or more carriers (e.g., a right to check additional baggage or an in-flight meal), auxiliary services from non-carriers (e.g., hotel reservations or rental car reservations), or any other travel-related service.” (underlining and bold added)
13. The re-accommodation is performed by replacing, in the impacted travel itineraries, at least the segments affected by the schedule changes, and this ultimately results in changes to the PNR database where travel itineraries are stored, and most likely also to the data recorded in the ETS, DCS, and inventory systems databases (paragraph [0004]).
14. In certain circumstances, however, “it may be desirable to undo a re-accommodation by modifying the database files to their pre-re-accommodation state, or redo a re-accommodation by modifying the database files to include a different set of replacement segments” (paragraph [0005], underlining and bold added). Examples for such circumstances include a re-accommodation done by mistake, incorrectly selected replacement segments, etc. (paragraph [0005]).
15. The shortcomings of the prior art systems appear to be related to their inability to easily perform such required undo a re-accommodation or redo a re-accommodation:
“[0006] In a conventional CRS, it may be difficult to determine which PNRs have been modified as a result of a previous re-accommodation, or what those modifications were. For example, a canceled flight that triggered the re-accommodation may no longer exist in the CRS or be active in the PNR database. In addition, because not all passengers subject to the re-accommodation will necessarily be rebooked on the same replacement segment, it may not be possible to determine which PNRs have been modified by the re-accommodation based on currently booked segments. This problem may be further magnified by the number of interrelated databases impacted by the re-accommodation, by loss of original data when these database files are modified, and by cascading effects of the schedule change. Additional modifications to the travel itinerary subsequent to the re-accommodation may further obscure the database modifications that need to be rolled back in order to undo the re-accommodation.” (underlining added)
16. The section concludes with the statement that “improved methods, apparatus, and computer program products for identifying and rolling back database modifications caused by a re-accommodation are needed to assist CRS users in modifying previously executed re-accommodations” (paragraph [0007]).
The proposed solution
17. The section “Summary” is written in a language suggestive of consistory statements broadly reflecting some of the claims as originally filed. This is followed by the section “Brief Description of the Drawings”, where the drawings, consisting of Figures 1 to 7, are briefly introduced. The next section, “Detailed Description”, describes the invention mainly by reference to the drawings.
The apparatus
18. Figure 1, reproduced below, illustrates “a processing and database apparatus 10 in accordance with an embodiment of the invention” (paragraph [0024]). While all of the illustrated systems are interconnected and provide functionalities necessary for the operation of the invention, in light of the background to the invention, the main focus appears to be on the re-accommodation system 12, which “may host or otherwise provide one or more modules that build and execute re-accommodations” (paragraph [0025]) and, to a somewhat lesser degree, on the CRS 14 containing the PNR database 15. The re-accommodation system “may be accessed via the user system 22, thereby enabling a system user to build or select a re-accommodation configured to implement one or more options for solving the impacted travel itineraries”, whereas “[t]he options provided for solving the problems caused by the flight schedule change may include deleting the impacted segment from the PNR and adding one or more replacement segments to replace the impacted segment” as well as “updating the segment timing in case of timing change, applying the schedule change (e.g., changing routing), and replacing additional inbound or outbound segments connected to the impacted segment” (paragraph [0026], bold added).
19. Importantly:
“[0021] … The re-accommodation system may execute the re-accommodation, collect data relating to the execution, and generate a report including this data. The report may include a list of segments impacted by the re-accommodation, the solutions implemented by the re-accommodation, and a table of impacted PNRs modified by the re-accommodation. Each PNR in the list of PNRs may be associated with a history file comprising a plurality of data structures, or envelopes, each having an identifier. Each envelope in turn may include data defining modifications made to the PNR, such as the state of the PNR at a specific point in time, e.g., immediately after the modifications were made. The table of impacted PNRs may include data identifying envelopes added to the history file of each PNR as a result of actions taken by the re-accommodation. By identifying the envelopes added as a result of the re-accommodation, the table of impacted PNRs may be used to determine the state of each impacted PNR as the PNR existed immediately after the initial re-accommodation. This state may then be compared to the current state of the PNR in question, thereby enabling the re-accommodation system to identify modifications made to a PNR as a result of a previously executed re-accommodation.
…
[0023] To implement a modifying re-accommodation, the re-accommodation system may retrieve the report generated by the previous re-accommodation. The re-accommodation system may then use the data in the report to determine which PNRs were modified by the previous re-accommodation, how they were modified, and whether they are eligible for modification by the modifying re-accommodation. The re-accommodation system may then recover eligible PNRs by returning them to the state they were in prior to execution of the previous re-accommodation, or modify the PNRs to implement an alternative solution that addresses the schedule change. The re-accommodation system may also cause files maintained by other systems to be synchronized with the PNR files in the PNR database.” (underlining and bold added)
20. It is important to note that the re-accommodation system generates a report for each executed re-accommodation. The reports are stored in the report database 13, and “may include data indicative of the actions performed to execute the corresponding re-accommodation, and the results of these actions”, wherein the “re-accommodation may comprise one or more actions configured to modify database files to implement the solutions to the schedule change” and “[t]hese actions may include database queries and instructions to modify PNRs, inventories, e-tickets, and DCS data” (paragraph [0027]).
The history files
21. With respect to the history files, each one associated with a corresponding PNR, it is further explained that:
“[0030] … The history file may comprise a record of the creation of, and any subsequent modifications to, the PNR. The history file may provide data that enables a system to determine if and when an element of the PNR has been modified, and what the modification included. Each time the PNR is updated, an additional envelope may be created and appended to the history file. Each envelope may include an identifier, such as a sequential number. For identifiers comprising sequential numbers, the lowest envelope number (e.g., envelope 000) may correspond to the envelope associated with creation of the PNR. Each envelope may include data defining a modification made to the PNR, a state of the PNR before or after the modification, a time and date the modification was made or the state of the PNR existed, information about the travel agent or the automated system making the modification, the name of the person that requested the modification, or any other suitable information relating to the PNR.” (underlining added)
22. An example of a history file is illustrated on Figure 2, reproduced below. In this particular case, “an exemplary history file 25, or a portion thereof, may include three envelopes 26a-26c” (paragraph [0031]). Paragraphs [0031]-[0032] further explain the figure in the following way. The envelope 26a represents the initial state of the PNR associated with this history file. The initial state includes two segments (represented in 26a by the two lines having line numbers 2 and 3), namely from Nice Cote D’Azur to London Heathrow on 30 June and from London Heathrow to Seoul Incheon on 30 June. Envelope 26b was added to the history file as a result of a re-accommodation triggered by the cancellation of the segment from Nice Cote D’Azur to London Heathrow. The re-accommodation was recorded by changing the status codes of the initial segments (see the lines having line numbers 2 and 3 in 26b) to indicate that these segments are no longer active, and by adding two replacement segments (represented in 26b by the two lines having line numbers 4 and 5). Envelope 26c represents “a current state of the PNR” which is “the state of the PNR at a time immediately before a modifying re-accommodation is to be executed” (paragraph [0032]).
23. For illustrative purposes, in 26c, the previously added replacement segments are removed and apparently replaced with a single segment (represented in 26c by the line having line number 2). This change may be a result of an intervening re-accommodation or a manual cancellation. If no such event has occurred, the current state and the state immediately after the previously described re-accommodation will be the same. What is important for the invention is that “the history file may be configured so that it is possible to retrieve the state of the PNR corresponding to any envelope stored in the PNR history” (paragraph [0032]).
The table of impacted PNRs
24. As mentioned above, for each re-accommodation, the re-accommodation system generates a report including a table of impacted PNRs that were modified by that re-accommodation. The table defines, for each one of the PNRs modified by the re-accommodation, the correspondence between the PNR and the respective envelope in the history file, associated with the PNR, the envelope specifying how the PNR was modified by the re-accommodation. Figure 5, reproduced below, represents such “an exemplary impacted PNR table 72” (paragraph [0047]). As illustrated, the correspondence is recorded in the table by associating the unique record locator for each one of the impacted PNRs with the respective envelope identifier or, in this case, envelope identity number.
25. In other words, the table of impacted PNRs is the part of the report, generated for a particular re-accommodation, which stores information identifying each one of the PNRs impacted by the particular re-accommodation as well as, for each impacted PNR, information pointing to the location (i.e., the envelope) in the history file, associated with that PNR, containing the record of how that PNR was modified. Importantly, “[t]he data provided by the impacted PNR table 72 may be used by the re-accommodation system 12 to identify impacted PNRs and their history files” (paragraph [0047]).
The options
26. As I already mentioned, a system user can “build or select a re-accommodation configured to implement one or more options for solving the impacted travel itineraries” (paragraph [0026]). The options can “be built based on the report generated by the previous re-accommodation and the history files of the impacted PNRs” (paragraph [0047]). The description further explains that:
“[0048] Each re-accommodation may comprise one or more options … . Each option may include data defining segments comprising the initial travel itinerary, actions to be performed on each segment, and one or more replacement segments that provide a solution to the scheduling change. Each option may be applied to a group of travelers that have booked the impacted flight, and may, upon execution, rebook the travelers using the specified solution. Each re-accommodation may comprise multiple options, each of which applies to a different set of impacted PNRs.” (underlining added)
27. One such option is illustrated on Figure 6 reproduced below. It is explained that:
“[0049] By way of example, FIG. 6 depicts an exemplary option 80 that includes a selected journey field 82, an action field 84, and a solution field 86. The journey field 82 may include an option type field 88, a date field 90, and a plurality of segment fields 92, 94. The depicted option type field 88 includes the type identifier ‘REDO’, which may indicate to the execution module 62 that the re-accommodation is intended to redo a previously executed re-accommodation by implementing an alternate solution. That is, the re-accommodation is ‘modifying’ the previous re-accommodation rather than implementing a new re-accommodation.
[0050] The modifying re-accommodation may be based on the impacted segment that triggered the previous re-accommodation, since this data may be common to all PNRs impacted by the previous re-accommodation. To this end, data identifying the impacted segment may be included in segment field 92, and may provide a reference to the travel itinerary defined by the PNRs prior to execution of the previous re-accommodation. Because the impacted segment should have been deleted from the PNRs by the previous re-accommodation, no action on the PNR may be needed with respect to the impacted segment. This may be indicated by the indication ‘none’ in the PNR action field 96 corresponding to segment field 92.
[0051] The option 80 may also include data identifying one or more replacement segments added by the previous re-accommodation in segment field 94. If a previous replacement segment is being replaced by a new replacement segment, a ‘cancel’ instruction may be included in a PNR action field 98 corresponding to segment field 94. In the example depicted, this instruction may cause the execution module 62 to delete flight 6X2 from each PNR to which the option 80 is applied. The solution field 86 may include a segment field 100 that includes data identifying one or more new replacement segments (e.g., flight 6X3).
[0052] In some cases, the previous re-accommodation may have replaced a complete travel itinerary in the PNR. In this scenario, segments that were not impacted may nevertheless have been rebooked by the previous re-accommodation in order to remedy itineraries impacted by the schedule change. These additional segments may need to be taken into account (e.g., canceled) by the modifying re-accommodation. To this end, the option may include the segments in question in association with the PNR action ‘cancel’. Upon execution of the re-accommodation, the solutions chosen by the user may be applied, and the non-impacted segments canceled by the previous re-accommodation reinstated.
[0053] In cases where non-impacted segments were deleted from the PNR by the previous re-accommodation, the build module 60 may evaluate the option to determine if the one or more segments selected by the user as the solution properly connects the reinstated segments. This evaluation may be performed by analyzing the travel itinerary that would result from implementing the solution. To this end, the build module 60 may determine if the travel itinerary to be implemented by the modifying re-accommodation connects the original origin and destination locations. If not, the build module 60 may generate an error. The build module 60 may also automatically select a new solution that produces a travel itinerary that connects the origin and destination locations.” (underlining and bold added)
28. In the above quotation, the references to “the build module 60” and “the execution module 62” are directed to the modules of the re-accommodation system 12 as per Figure 4 reproduced below.
The process
29. Figure 4 is “a sequence diagram depicting a process that may be implemented by one or more of the systems comprising the processing and database apparatus of FIG. 1 to build and execute a modifying re-accommodation” (paragraph [0015]). The sequence (starting with item 68 and finishing with item 156) illustrates the order of the procedures performed by the systems of Figure 1, including the data communication between these systems. The procedures are as follows (paragraphs [0045], [0062]-[0064], [0068]-[0069], [0072]-[0074], [0088]-[0089], [0095], [0102], [0104]):
68 – the re-accommodation system receives from the user system a request to modify a previously executed re-accommodation;
70 – the re-accommodation system retrieves the report associated with the previously executed re-accommodation from the report database (item 13 on Figure 1);
102 – the build module analyses the impacted segment and, based on the analysis, creates one or more options for re-accommodating each of the impacted travel itineraries;
104 – the build module retrieves schedule data from the inventory system, the data apparently are also used in creating the one or more options;
106 – the created options are transmitted to the user system for display to the user;
108 – the user selects one or more of the options to create the modifying re-accommodation;
110 – following the selection, the user instructs the user system to transmit a commit message to the re-accommodation system;
112 – the execution module validates the re-accommodation, including validating the options comprising the modifying re-accommodation to avoid the creation of scheduling problems;
114 – apparently, as part of the validating, the execution module launches a query to the inventory system to check the options being implemented against the carrier schedule;
116 – upon successful validation, the execution module executes the modifying re-accommodation;
118 – the execution module transmits a select impacted PNRs request to the CRS to trigger execution of the modifying re-accommodation in the CRS, the request including the options to be implemented, record locators identifying the impacted PNRs, and envelope identifiers;
120 – the eligibility module performs a process to determine the eligibility of each impacted PNR to be modified by the modifying re-accommodation (some more discussion of the process is provided later in the decision with reference to Figure 7);
144 – the update module transmits an update inventory request to the inventory system, the request including the eligible PNRs and instructions relating to updating the inventory;
146 – the inventory system updates inventories relating to bookings, seats, and services in accordance with the replacement travel itineraries implemented by the modifying re-accommodation;
148 – the inventory system transmits a synchronize PNRs request to the update module, the request including data relating to the booked segments and services that were updated in the inventory database (item 17 on Figure 1);
150 – the update module executes instructions that update the impacted PNRs in the PNR database to reflect the modifications to the travel itineraries, including changed segments and services;
152 – the update module transmits one or more e-ticket update requests to the ETS to update the e-ticket database (item 19 on Figure 1);
154 – the update module transmits one or more DCS update requests to the DCS, the requests including instructions for updating files in the DCS database (item 21 on Figure 1); the requests may be transmitted while updating the PNRs (e.g., each time a PNR is updated), or upon completion of all or a portion of the PNR updates; the DCS transmits results of the instructions to the CRS to confirm that the updates have been processed;
156 – the update module transmits a report to the re-accommodation system for inclusion in a re-accommodation report.
The rules
30. It must be noted that the outcomes of the described processes employed to realise the undo a re-accommodation or redo a re-accommodation are governed by a number of complicated rules, for example:
“[0054] If the previous re-accommodation has rebooked PNRs on another carrier, it may be necessary to verify that the carrier originating the modifying re-accommodation (e.g., the carrier providing the impacted segment) has the right to update the PNRs of the carrier operating the replacement segment.
[0055] If the impacted segment includes a negotiated space, the negotiated space may need to be created on the replacement segments. Negotiated space may refer to seats belonging to a specific class dedicated to the negotiated space. Passengers with tickets in the negotiated space may benefit from special conditions. A negotiate space may be obtained, for example, by a tour operator that resells the seats as part of a tour package. In this case, the negotiated space may be represented in a segment by a block of seats that can only be sold by the tour operator.
[0056] During a re-accommodation, blocks of negotiated space seats on the impacted segment may be transferred onto the replacement segments. If no blocks of the negotiated space exist on the replacement segment, blocks of the negotiated space may be created. In either case, in order for negotiated blocks to be merged, the negotiated blocks on the impacted segment may have to share at least some characteristics with the negotiated blocks on the replacement segments. For example, the negotiated blocks may require the same owner. In other cases, the size of an existing block of negotiated space may be increased to accommodate additional travelers being transferred from the impacted segment.
…
[0071] In some cases, re-accommodations may be executed as batches based on flight date. If the validation fails on a specific flight date, the flight date may be discarded and unlocked, and the validation attempted for PNRs having a different flight date, e.g., the following day. If more than a predetermined number of flight dates are discarded, the re-accommodation may be stopped, and an error reported. If validation is successful for the other flight dates, these other flight dates of the period may be processed, and the flight dates in error reported. The user may then manually modify PNRs for the problematic flight dates at a later time. Each carrier may set the predetermined number of flight dates that triggers stoppage of the re-accommodation. This predetermined number may be set to limit the amount of manual handling required by correcting errors in a faulty re-accommodation before launching the re-accommodation for an entire flight period.
…
[0090] The one or more replacement segments and PNR eligibility checks may be based on travel itinerary analysis performed at a segment level. To account for changes in SSRs [i.e., Special Service Requests], tickets, or DCS data, the update module 64 may include a ‘segment mapping’ feature. Segment mapping may provide logic that maps each segment of the solution to a segment of the impacted travel itinerary so that the re-accommodated travel itinerary includes the same level of services, e.g., booking classes, SSRs, seats, and segment status. The mapping logic may include class mapping logic, status mapping logic, and service mapping logic.
…
[00100] … the update module 64 may use e-ticket data associated with previous replacement segments, or taken from the history file. Re-issue may be attempted when revalidation is not possible. The decision to re-issue or revalidate each e-ticket may be based on rules defined by the carrier. For example, revalidation may not be possible if the modifying re-accommodation is changing routing, class, or the operating carrier.” (underlining and bold added)
31. Other examples include the rules for dealing with segments sold under code-share arrangements, where “[a] code-share agreement may refer to a business arrangement where two or more carriers publish and market a flight under their respective airline designator and flight number as part of their published time table or schedule” (as per paragraphs [0058]-[0059]); as well as the set of rules that forms the basis of the above mentioned at item 120 of Figure 4 process to determine the eligibility of each impacted PNR to be modified by the modifying re-accommodation. These latter rules are illustrated on the flow-chart of Figure 7, reproduced below:
32. Figure 7 appears more or less self-explanatory, perhaps with the exception of the concept of “check level”, which is explained in the following way:
“[0077] In block 126, the process 120 may determine a ‘check level’ that is to be applied to the PNR. The check level may be one of a plurality of levels (e.g., four levels) applied to determine how rigorously the PNR is evaluated for eligibility. The level applied may depend on a requirement set by the carrier, and may be adjustable for each re-accommodation modified. In the exemplary embodiment shown, if level one is being applied (‘L1’ branch of decision block 126), the process 120 may proceed to block 128 and determine that the PNR is eligible for modification. Thus, under the exemplary level one, all existing PNRs impacted by the previous re-accommodation are eligible for modification by the modifying re-accommodation, even if the PNR was modified since execution of the previous re-accommodation.” (underlining and bold added)
Exemplary levels two, three, and four require additional conditions to be checked to determine the eligibility of the PNR in question as it can be seen from the flow-chart.
33. Another part of Figure 7 that may warrant further explanation is block 132, where the eligibility module performs a check as to whether the travel itinerary defined by the PNR is “similar” to the travel itinerary proposed by the modifying re-accommodation. The description explains how the similarity is determined:
“[0081] … The process 120 may determine that the current travel itinerary defined by the PNR is similar to the expected travel itinerary if the current and expected travel itineraries each include a similar origin and destination location, and a similar date. ‘Similar’ origin and destination locations may be selected by the carrier at an airport level (the origination and destination airports must be the same e.g., JFK to LHR), a city level (the origination and destination airports must serve the same city, e.g., JFK or LGA to LHR or LTN), or a country level (the origination and destination airports must serve the same country e.g., United States to England). A similar date may be considered to be a segment departing on the same day, or a predetermined number of days before or after the departure date of the impacted segment.” (underlining and bold added)
The implementation of the solution
34. The computer technology utilised for the implementation of the systems of Figure 1 is illustrated on Figure 3 reproduced below. It is explained that:
“[0038] Referring now to FIG. 3, the re-accommodation system 12, CRS 14, inventory system 16, ETS 18, DCS 20, and user system 22 of the processing and database apparatus 10 may be implemented on one or more computer devices or systems, such as exemplary computer system 30. The computer system 30 may include a processor 32, a memory 34, a mass storage memory device 36, an input/output (I/O) interface 38, and a Human Machine Interface (HMI) 40. The computer system 30 may also be operatively coupled to one or more external resources 42 via the network 24 or I/O interface 38. External resources may include, but are not limited to, servers, databases, mass storage devices, peripheral devices, cloud-based network services, or any other suitable computer resource that may be used by the computer system 30.” (underlining added)
35. Importantly, the hardware components of the system 30, including the processor 32, the memory 34, and the mass storage device 36, are described quite broadly by encompassing a large number of alternative possibilities (paragraph [0039]). The operating system 46 may be omitted (paragraph [0040]), whereas the input/output (I/O) interface 38, the network 24, the one or more external resources 42, and the human machine interface (HMI) 40 are described entirely through their respective high-level functionality (paragraphs [0041]-[0042]).
36. In addition:
“[0041] … The application 48 may thereby work cooperatively with the network 24 or external resource 42 by communicating via the I/O interface 38 to provide the various features, functions, applications, processes, or modules comprising embodiments of the invention. The application 48 may also have program code that is executed by one or more external resources 42, or otherwise rely on functions or signals provided by other system or network components external to the computer system 30. Indeed, given the nearly endless hardware and software configurations possible, persons having ordinary skill in the art will understand that embodiments of the invention may include applications that are located externally to the computer system 30, distributed among multiple computers or other external resources 42, or provided by computing resources (hardware and software) that are provided as a service over the network 24, such as a cloud computing service.” (underlining added)
37. Further, with respect to the database 44 and its structure, the description states:
“[0043] A database 44 may reside on the mass storage memory device 36, and may be used to collect and organize data used by the various systems and modules described herein. The database 44 may include data and supporting data structures that store and organize the data. In particular, the database 44 may be arranged with any database organization or structure including, but not limited to, a relational database, a hierarchical database, a network database, or combinations thereof. A database management system in the form of a computer software application executing as instructions on the processor 32 may be used to access the information or data stored in records of the database 44 in response to a query, where a query may be dynamically determined and executed by the operating system 46, other applications 48, or one or more modules.” (underlining added).
38. Later in the description, it is briefly noted that “[t]o enable users to build and implement re-accommodations, the respective modules may provide a plurality of interfaces to the user via the user system 22” (paragraph [00105]). These include “a ‘launch re-accommodation from report’ interface, or RFR interface” that “may provide the user with a plurality of selectable previously executed re-accommodations” (paragraph [00105]) as well as “[a] commit RFR interface” that “may provide the user with an interface for selectively instructing the re-accommodation system 12 to commit to execution of the selected re-accommodation” (paragraph [00107]). The description does not go into any specifics beyond the functional capabilities of the interfaces.
39. Paragraphs [00108]-[00112] describe the software implementation, explicitly noting that none of the specifically described techniques is vital for the working of the invention. For example:
“[00109] Various program code described herein may be identified based upon the application within that it is implemented in specific embodiments of the invention. However, it should be appreciated that any particular program nomenclature that follows is used merely for convenience, and thus the invention should not be limited to use solely in any specific application identified and/or implied by such nomenclature. Furthermore, given the generally endless number of manners in which computer programs may be organized into routines, procedures, methods, modules, objects, and the like, as well as the various manners in which program functionality may be allocated among various software layers that are resident within a typical computer (e.g., operating systems, libraries, API’s, applications, applets, etc.), it should be appreciated that the embodiments of the invention are not limited to the specific organization and allocation of program functionality described herein.
…
[00112] … The computer program instructions may be provided to one or more processors of a general purpose computer, a special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the one or more processors, cause a series of computations to be performed to implement the functions, acts, and/or operations specified in the flow-charts, sequence diagrams, and/or block diagrams.” (underlining added)
40. In another example, with respect to Figure 4, it is explained that:
“[0044] … The modules 60, 62, 64, 66 are shown as distinct components, which may indicate the use of modular programming techniques. However, the software design may decrease the extent to which the modules 60, 62, 64, 66 are distinct by combining at least some program functions of multiple modules into a single module. Moreover, a person having ordinary skill in the art would understand that the functions attributed to the modules 60, 62, 64, 66 could be distributed in other ways, or on other systems than those depicted. Thus, embodiments of the invention are not limited to the specific arrangement of systems or modules shown in FIG. 4.” (underlining added)
41. Finally, it is perhaps worth noting that:
“[0072] … The amount of time and system resources required to execute a re-accommodation may depend on the number of PNRs impacted, and the number of flight dates being re-accommodated. To discretize execution of a re-accommodation for impacted flights occurring over a period of time, the execution module 62 may categorize the PNRs by the flight date of the impacted segment. The re-accommodation may then be executed in parallel for the categorized PNRs based on flight date. This may permit updating database files for flight dates within the period while the re-accommodation is being executed.”
42. As a brief summary of the disclosure in the body of the Specification, the described invention proposes a solution to the prior art problems, and this solution involves keeping detailed records (in reports for each re-accommodation and history files associated with each PNR) of all changes to travel itineraries that are made to accommodate various scheduling changes. These detailed records allow the recovery of any previous state of the travel itineraries and their subsequent modifications. The body of the Specification does not suggest that any specific hardware components or software techniques beyond the capabilities of the skilled addressee are required for implementing the invention.
The claimed invention
43. The Specification ends with 15 claims, from which claim 1 is the only independent claim. It is worth noting that while claims 1 to 13 define a method, claim 14 defines a corresponding apparatus “comprising: one or more processors; and a memory coupled to the one or more processors” which ultimately “perform[s] the method of any one of claims 1 to 13”, whereas claim 15 defines a computer program that is “configured to, when executed by one or more processors, cause the one or more processors to perform the method of any one of claims 1 to 13”.
44. Claim 1 is reproduced below (some formatting added to assist readability):
“1. A method of implementing a modification of a first re-accommodation
in a processing and database apparatus comprising
a re-accommodation system and
a computer reservations system
configured to interface with the re-accommodation system,
the method comprising:
receiving, by the re-accommodation system, a first request to execute a second re-accommodation that modifies the first re-accommodation;
in response to receiving the first request, retrieving, by the re-accommodation system from a first database, a report associated with an execution of the first re-accommodation,
the report including a record locator that identifies, in a second database, a passenger name record modified by execution of the first re-accommodation,
the passenger name record being associated with a history file comprising a plurality of envelopes that provide a record of a creation of, and any subsequent modifications to, the passenger name record,
each envelope including data defining a respective modification made to the passenger name record, and
the history file being configured so that the state of the passenger name record corresponding to any envelope stored in the history file can be retrieved, and
the report further including an identifier that identifies a first envelope of the plurality of envelopes of the history file,
the first envelope being associated with data defining the modification made to the passenger name record as a result of execution of the first re-accommodation;
identifying, by the re-accommodation system based on the record locator, the passenger name record in the second database,
the passenger name record being in a first state that represents a current status of the passenger name record immediately before execution of the second re-accommodation;
identifying, by the re-accommodation system based on the identifier, a portion of the history file including the first envelope;
determining, by the re-accommodation system based on the portion of the history file, a second state of the passenger name record that represents a first previous status of the passenger name record before execution of the first re-accommodation;
determining, by the re-accommodation system based on the first request, a third state of the passenger name record that represents a desired status of the passenger name record after execution of the second re-accommodation;
executing, by the re-accommodation system, the second re-accommodation modifying the first re-accommodation,
wherein execution of the second re-accommodation by the re-accommodation system triggers transmission of an impacted passenger name record request to the computer reservations system,
the impacted passenger name record request including
the third state of the passenger name record,
the record locator identifying the passenger name record in the second database modified by execution of the first re-accommodation, and
the identifier identifying the first envelope of the history file, and
modifying, by the computer reservations system in response to receiving the impacted passenger name record request and based on the first state and the second state, the passenger name record from the first state to the third state,
the modifying causing the creation of an additional envelope to the history file,
the additional envelope being appended to the history file to represent the state of the passenger name record immediately after the second re-accommodation.”
45. The claim construction does not appear to present any difficulties for the present purposes of characterising the claimed invention to ascertain whether it is a manner of manufacture. The claimed method appears reflective of the solution discussed in the body of the Specification, perhaps with the exception of the generation and storing of a report for the execution of the second re-accommodation, which is not explicitly defined.
APPLICABLE LAW
46. On 15 April 2013, the Intellectual Property Laws Amendment (Raising the Bar) Act 2012 commenced which resulted in significant amendments to the Act and Regulations. The Application was filed on 25 January 2016; hence the amended provisions of the Act and Regulations apply to the examination of the Application and to the instant hearing decision. This means that I must accept the Application if I am satisfied, on the balance of probabilities, that the application complies with the Act. If I am not so satisfied, I may refuse the Application. In such a situation, the extended period for gaining acceptance provided under reg 13.4(1)(g) will make no difference if the Application is refused. However, I consider that it is only appropriate to refuse the Application if I am satisfied that providing the Applicant with an opportunity to overcome any negative finding(s) would serve no useful purpose; in other words, if I consider that any potential negative findings are inevitably fatal to the Application.
MANNER OF MANUFACTURE
47. I will now consider the objection with respect to manner of manufacture.
The law on manner of manufacture
48. The relevant parts of s 18 stipulate:
“(1) Subject to subsection (2), an invention is a patentable invention for the purposes of a standard patent if the invention, so far as claimed in any claim:
(a) is a manner of manufacture within the meaning of section 6 of the Statute of Monopolies; and
…
(2) Human beings, and the biological processes for their generation, are not patentable inventions.”
49. A number of Court decisions have discussed and determined whether the particular invention in each case “is a manner of manufacture within the meaning of section 6 of the Statute of Monopolies”. These Court decisions constitute a significant body of case law that the Commissioner must follow. For the purpose of this decision, I do not consider it necessary to provide a comprehensive review of the case law and I will only point to Court decisions which I consider pertinent to the instant considerations.
50. National Research Development Corporation v Commissioner of Patents [1959] HCA 67; (1959) 102 CLR 252 (NRDC) is the seminal authority on the issue, establishing, inter alia, the general approach for deciding the question of manner of manufacture at [14] (at p 269):
“The right question is: ‘Is this a proper subject of letters patent according to the principles which have been developed for the application of s. 6 of the Statute of Monopolies?’”
51. D’Arcy v Myriad Genetics Inc [2015] HCA 35 (Myriad) is a much more recent High Court decision on manner of manufacture; however, I note that both NRDC and Myriad are not related to inventions implemented on computing devices, hence they do not discuss some of the more specific issues associated with such inventions. In contrast, the decisions of the Full Court of the Federal Court in Research Affiliates LLC v Commissioner of Patents [2014] FCAFC 150 (Research Affiliates) and Commissioner of Patents v RPL Central Pty Ltd [2015] FCAFC 177 (RPL Central) were made with respect to business methods implemented on computing devices. In particular, in RPL Central the Full Court, having considered in some detail the decisions in Research Affiliates and Myriad, developed an approach to determining the issue of manner of manufacture for inventions implemented using computers. This approach of RPL Central was later approved in Encompass Corporation Pty Ltd v InfoTrack Pty Ltd [2019] FCAFC 161 (Encompass), which was a decision by an enlarged bench (consisting of five judges) of the Full Court. The approach was also relied on in subsequent Full Court decisions, including Commissioner of Patents v Rokt Pte Ltd [2020] FCAFC 86 (Rokt) and Repipe Pty Ltd v Commissioner of Patents [2021] FCAFC 223 (Repipe). The cases in Encompass, Rokt, and Repipe also involved inventions implemented using computer technology.
52. Aristocrat Technologies Australia Pty Ltd v Commissioner of Patents [2022] HCA 29 is the most recent High Court decision on manner of manufacture. Because, in that decision, the six judges were evenly divided as to the outcome, there was no majority and no usual binding precedent. Importantly however, the above mentioned decisions of the Full Court were not criticised and remain undisturbed. Also, as a result of the operation of s 23(2)(a) of the Judiciary Act 1903, the decision of the Full Court of the Federal Court in Commissioner of Patents v Aristocrat Technologies Australia Pty Ltd [2021] FCAFC 202 that the invention concerned was not for a manner of manufacture was affirmed.
53. For the purpose of deciding on manner of manufacture, I consider it helpful to provide a brief overview of some of the main guiding principles that could be extracted from the above Court decisions. Below, I will present those principles, in italic, as separate paragraphs supported by relevant quotations from the decisions. Where the breadth of some quotations makes them relevant to more than one principle, for brevity, I will not repeat those quotations in different paragraphs (underlining added in all quotations).
54. A determination on manner of manufacture must be done on a case by case basis, having regard to the substance of the invention not merely the form of the claims; there are no strict rules or a precise formula to be applied mechanistically:
“The purpose of s. 6, it must be remembered, was to allow the use of the prerogative to encourage national development in a field which already, in 1623, was seen to be excitingly unpredictable. To attempt to place upon the idea the fetters of an exact verbal formula could never have been sound. It would be unsound to the point of folly to attempt to do so now, when science has made such advances that the concrete applications of the notion which were familiar in 1623 can be seen to provide only the more obvious, not to say the more primitive, illustrations of the broad sweep of the concept.” (NRDC at [15]; at p 271)
“This Court in NRDCdid 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.” (Myriad at [23])
“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.” (Myriad at [144], reasons by Gageler and Nettle JJ)
“The approach to be taken to deciding whether a claimed method or product is properly the subject of letters patent must be flexible and must allow for new technologies presently unknown … There is no formula to be mechanically applied …
… in examining whether a claimed invention is properly the subject of letters patent, it is necessary to look not only at the integers of that claimed invention but also at the substance of that invention.” (Research Affiliates at [116]-[117])
“The determination … is made not by some mechanistic application of the criterion of artificiality or physical effect, but by an understanding of the claimed invention itself. The invention is to be understood as a matter of substance and not merely as a matter of form.” (Research Affiliates at [106])
55. The characterisation as “an artificially created state of affairs of economic significance” is useful, but not ultimately determinative for manner of manufacture; to be patentable, a process must belong to the useful arts:
“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.” (NRDC at [22]; at p 275)
“… the view which we think is correct in the present case is that the method the subject of the relevant claims has as its end result an artificial effect falling squarely within the true concept of what must be produced by a process if it is to be held patentable … The effect produced by the appellant’s method exhibits the two essential qualities upon which ‘product’ and ‘vendible’ seem designed to insist. It is a ‘product’ because it consists in an artificially created state of affairs, discernible by observing over a period the growth of weeds and crops respectively on sown land on which the method has been put into practice. And the significance of the product is economic; for it provides a remarkable advantage, indeed to the lay mind a sensational advantage, for one of the most elemental activities by which man has served his material needs, the cultivation of the soil for the production of its fruits … It achieves a separate result, and the result possesses its own economic utility consisting in an important improvement in the conditions in which the crop is to grow, whereby it is afforded a better opportunity to flourish and yield a good harvest.” (NRDC at [25]; at p 277)
“If a process is to be patentable, it must offer some advantage which is material, in the sense that the process belongs to a useful art. The characterisation of patentability by reference only to the description in NRDC of a product which consists of an artificially created state of affairs of economic significance was part of the High Court’s reasoning but did not represent a sufficient or exhaustive statement of the circumstances in which a claimed invention is patentable.” (Research Affiliates at [101])
“In this context, their Honours emphasised [in Myriad] (at [20]) that, while satisfaction of an ‘artificially created state of affairs of economic significance’ as stated in NRDC may ‘suffice for a large number of cases in which there are no countervailing considerations’, this terminology is not to be treated as a formula exhaustive of the concept of manner of manufacture, or a formula which alone captures the breadth of the ideas to which effect must be given. Similarly, Gageler and Nettle JJ noted (at [125]) that the holding in NRDCdoes not mean that an ‘artificial state of affairs’ and ‘economic utility’ are the only relevant considerations in this context. However, the majority and Gageler and Nettle JJ acknowledged the usefulness of such characterisation in appropriate circumstances.” (RPL Central at [116])
56. In deciding on manner of manufacture, it is important to identify where the inventor’s ingenuity lies:
“It is a question of understanding what has been the work of, the output of, and the result of, human ingenuity, and to apply the principles that have been developed and explained so well in NRDC.” (Research Affiliates at [116])
“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.” (RPL Central at [112])
57. Technological innovations are patentable, whereas business innovations are not; a business method implemented on computing devices could be patentable if it involves ingenuity in the computer implementation:
“Relevantly, the Full Court in Research Affiliates said (at [94]) that the distinction to be drawn was between the employment of an abstract idea or law of nature and the idea or law itself and that there is a distinction between a technological innovation which is patentable and a business innovation which is not. Their Honours repeated an observation from Grant (at [29]) ‘[a] product of a method is something in which a new and useful effect may be observed. For claimed computer programs, the courts looked to the application of the program to produce a practical and useful result, so that more than “intellectual information” was involved.’ A technological innovation is patentable; a business innovation is not, although a business method may be the subject of letters patent.” (RPL Central at [100])
“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. The basis for the analysis starts with the fact that a business method, or mere scheme, is not, per se, patentable. The fact that it is a scheme or business method does not exclude it from properly being the subject of letters patent, but it must be more than that. There must be more than an abstract idea; it must involve the creation of an artificial state of affairs where the computer is integral to the invention, rather than a mere tool in which the invention is performed. Where the claimed invention is to a computerised business method, the invention must lie in that computerisation. It is not a 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.” (RPL Central at [96])
“RPL Central does not claim any invention or ingenuity in any program or operation of a computer, or implementation by a computer to operate the method. Accordingly, the ingenuity of the inventors must be in the steps of the method itself. The method does utilise the speed and processing power and ability of a computer but there is no suggestion that this is other than a standard operation of generic computers with generic software to implement a business method …
The problem may be one of confronting the ‘maze’ of available information concerning the RPL of different Units of Competency in different institutions, but the solution to that problem, to be patentable, must involve more than the utilisation of the well-known search and processing functions of a computer, for example an invention in the way in which the computer is utilised.” (RPL Central at [110]-[111])
“There is no suggestion in the specification or the claims that any part of the inventive step lies in the computer implementation. Rather, it is apparent that the scheme is merely implemented in a computer and a standard computer at that. It is no part of the claimed method that there is an improvement in what might broadly be called ‘computer technology’.” (Research Affiliates at [118])
100. It follows that the Application should be refused.
Dr V. Z. Kolev
Delegate of the Commissioner of Patents
0