Collaborative change method and device for multiple passenger airline tickets, electronic equipment and program product

Abstract

The invention discloses a multi-passenger air ticket collaborative change method and device, electronic equipment and a program product, and relates to the technical field of air ticket management, and the collaborative change method comprises the steps: receiving a multi-passenger air ticket change request, binding all to-be-changed passenger seat reservation records as a virtual group based on a preset consistency condition, and storing the to-be-changed passenger seat reservation records in the virtual group; based on the original flight information and the target flight information corresponding to each to-be-changed passenger seat reservation record, generating a flight change candidate scheme set, and under the condition that a target flight change scheme selected by a passenger from the flight change candidate scheme set is received, changing the to-be-changed passenger seat reservation record based on the target flight change scheme. And flight change is carried out on all the to-be-changed passenger seat reservation records in the virtual group, and a multi-passenger air ticket change request is completed. According to the method and the device, the technical problem that multiple passenger airline tickets cannot be efficiently and collaboratively changed in the prior art is solved.

Description

Technical Field

[0001] This invention relates to the field of airline ticketing management technology, and more specifically, to a method and apparatus, electronic equipment and program product for the collaborative modification of multi-passenger tickets. Background Technology

[0002] In recent years, the digital transformation of the air transport industry has accelerated, and passengers' demand for service flexibility and collaborative operations has increased significantly. Group travel orders have continued to rise, with corporate travel, family trips, and tour groups showing particularly strong growth. However, current airline reservation systems still revolve around single passengers or single PNRs (Passenger Name Records), failing to effectively handle the complex rescheduling needs of multiple passengers, multiple itineraries, and across PNRs. This has led to a widening gap between airline service capabilities and market demand.

[0003] The current airline reservation system has the following problems:

[0004] (1) Operational fragmentation and efficiency bottleneck.

[0005] Current airline systems only support rescheduling for a single Product Name (PNR). For example, with a 10-person corporate team, if team members are scattered across multiple independent PNRs (e.g., purchased tickets in batches or issued through different channels), manual rescheduling requires querying, verifying, and modifying each PNR individually. This frequent switching between system interfaces leads to missed or incorrect changes, severely impacting customer satisfaction. Furthermore, the lack of a group collaboration entry point for self-service rescheduling on the passenger side means individual users must repeatedly fill in the same information, significantly increasing the complexity of the process.

[0006] (2) Lack of resource competition and conflict management.

[0007] The core challenge of multi-passenger collaborative rescheduling lies in resource contention under high concurrency. For example, in the rescheduling of popular flights, if multiple Passenger Nominees (PNRs) simultaneously request the same seat, the current system, lacking a distributed locking mechanism, may experience overbooking due to delayed inventory synchronization, leading to subsequent customer complaints and compensation costs. Furthermore, after PNRs separate (e.g., some members reschedule in advance), the system lacks historical records, making collaborative rescheduling impossible and requiring manual intervention.

[0008] (3) System functional limitations.

[0009] Current GDS (Global Distribution System) only provides basic rescheduling interfaces, but its design is intended for single PNR services and lacks multi-PNR transaction management capabilities, making it unable to batch verify the rescheduling availability of flights across multiple PNRs. In terms of cost calculation, it only supports single-passenger dimensions and cannot aggregate group discounts. In airline-built systems, it can only support rescheduling for multiple passengers within the same PNR, but cannot handle collaborative operations between unrelated PNRs or separated PNRs. Furthermore, existing rule engines are mostly used in ticket pricing scenarios and are not adapted to the rescheduling needs of multiple overlapping policies.

[0010] Therefore, the relevant technologies suffer from problems such as inefficient operation, frequent conflicts, and rigid rules in multi-PNR collaborative rescheduling scenarios.

[0011] There is currently no effective solution to the above problems. Summary of the Invention

[0012] This invention provides a method, apparatus, electronic device, and program product for collaborative modification of multi-passenger tickets, to at least solve the technical problem in the related art that it is impossible to efficiently and collaboratively modify multi-passenger tickets.

[0013] According to one aspect of the present invention, a method for collaboratively changing multiple passenger tickets is provided, comprising: receiving a multiple passenger ticket change request, wherein the multiple passenger ticket change request includes: multiple passenger reservation records to be changed, original flight information corresponding to each passenger reservation record to be changed, and target flight information; binding all passenger reservation records to be changed into a virtual group based on a preset consistency condition; generating a flight change candidate scheme set based on the original flight information corresponding to each passenger reservation record to be changed and the target flight information, wherein the flight change candidate scheme set includes: permutations and combinations of flight change candidate schemes in multiple dimensions; and, upon receiving a target flight change scheme selected by a passenger from the flight change candidate scheme set, changing the flight for all passenger reservation records to be changed in the virtual group based on the target flight change scheme, thereby completing the multiple passenger ticket change request.

[0014] Further, the step of binding all passenger reservation records to be modified into a virtual group based on a preset consistency condition includes: upon receiving a multi-passenger ticket change request, performing a consistency check on all passenger reservation records to be modified based on the preset consistency condition, wherein the passenger reservation records to be modified contain the original flight number, original date, original departure point, and original destination; if the preset consistency condition is a first type of consistency condition, determining whether the original flight number, original date, original departure point, and original destination contained in all passenger reservation records to be modified are completely consistent, and confirming that the original flight number, original date, original departure point, and original destination contained in all passenger reservation records to be modified are completely consistent. If the conditions are consistent, all passenger reservation records to be changed are bound into a virtual group. The first type of consistency condition means that the flight number, date, departure point, and destination of all passenger reservation records requesting changes are completely consistent. If the preset consistency condition is the second type of consistency condition, it is determined whether the original departure point and original destination of all passenger reservation records to be changed are completely consistent. If the original departure point and original destination of all passenger reservation records to be changed are completely consistent, all passenger reservation records to be changed are bound into a virtual group. The second type of consistency condition means that the departure point and destination of all passenger reservation records requesting changes are completely consistent.

[0015] Furthermore, the step of binding all passenger reservation records to be modified into a virtual group includes: querying whether there is a historical relationship between all passenger reservation records to be modified; if there is a historical relationship between all passenger reservation records to be modified, checking whether the itineraries indicated by all passenger reservation records to be modified are consistent; if the itineraries indicated by all passenger reservation records to be modified are consistent, aggregating all passenger reservation records to be modified to obtain an aggregated record, and configuring a virtual group identifier for the aggregated record to obtain a virtual group; if there is no historical relationship between all passenger reservation records to be modified, or if the itineraries indicated by all passenger reservation records to be modified are inconsistent, establishing a temporary relationship between all passenger reservation records to be modified, and configuring a virtual group identifier for all passenger reservation records to be modified based on the temporary relationship to obtain a virtual group.

[0016] Furthermore, before generating a set of candidate flight change schemes based on the original flight information and target flight information corresponding to each passenger reservation record to be changed, the process includes: determining a set of candidate flights and a set of candidate cabin classes based on the target flight information; grouping all passenger reservation records to be changed according to the flight and cabin class dimensions based on all original flight information to obtain multiple sets of change records, wherein each set of change records corresponds to a change fee strategy; and calculating the change fee for each candidate cabin class under each candidate flight based on the set of candidate flights and the set of candidate cabin classes, using the change fee strategy.

[0017] Furthermore, the step of generating a set of flight change candidate schemes based on the original flight information and target flight information corresponding to each passenger reservation record to be changed includes: calculating seat adjacency based on the number of seats in each candidate cabin class under each candidate flight; determining the departure time and transfer time of each candidate flight; arranging each candidate cabin class under each candidate flight using change cost, seat adjacency, departure time, and transfer time as dimensions to obtain a permutation and combination of flight change candidate schemes under each dimension; and generating a set of flight change candidate schemes based on the permutation and combination of flight change candidate schemes under all dimensions.

[0018] Furthermore, based on the target flight change scheme, the steps for changing the flight of all passenger reservation records to be changed in the virtual group include: configuring the lock duration based on the sales status of the target flight indicated by the target flight change scheme and the number of passenger reservation records to be changed, and generating a transaction log for the target flight; changing the flight of all passenger reservation records to be changed in the virtual group within the lock duration to obtain the change result; and recording the change completion in the transaction log and closing the virtual group when the change result indicates that all passenger reservation records to be changed have been changed.

[0019] Furthermore, after obtaining the change result, the process also includes: if the change result indicates that there are passenger reservation records to be changed that failed to change, obtaining the reason for the change failure; if the reason for the change failure indicates a network problem, retrying the change of the passenger reservation records to be changed that failed until the number of retries reaches a preset number or the change is successful; if the reason for the change failure indicates a business problem, rolling back all passenger reservation records to be changed that have been successfully changed based on the transaction log, and reselecting and determining the target flight change plan.

[0020] According to another aspect of the present invention, a collaborative change device for multiple passenger tickets is also provided, comprising: a receiving unit for receiving multiple passenger ticket change requests, wherein the multiple passenger ticket change requests include: multiple passenger reservation records to be changed, original flight information corresponding to each passenger reservation record to be changed, and target flight information; a binding unit for binding all passenger reservation records to be changed into a virtual group based on a preset consistency condition; a generating unit for generating a flight change candidate scheme set based on the original flight information corresponding to each passenger reservation record to be changed and the target flight information, wherein the flight change candidate scheme set includes: permutations and combinations of flight change candidate schemes in multiple dimensions; and a change unit for, upon receiving a target flight change scheme selected by a passenger from the flight change candidate scheme set, changing the flight of all passenger reservation records to be changed in the virtual group based on the target flight change scheme, thereby completing the multiple passenger ticket change request.

[0021] Furthermore, the binding unit includes: a first checking module, used to perform a consistency check on all passenger booking records to be changed based on a preset consistency condition when receiving multiple passenger ticket change requests, wherein the passenger booking records to be changed contain the original flight number, original date, original departure point, and original destination; and a first determining module, used to determine whether the original flight number, original date, original departure point, and original destination contained in all passenger booking records to be changed are completely consistent when the preset consistency condition is a first type of consistency condition, and to bind the booking unit if the original flight number, original date, original departure point, and original destination contained in all passenger booking records to be changed are completely consistent. The passenger reservation records to be changed are virtual groups. The first consistency condition refers to the condition that the flight number, date, departure point, and destination of all passenger reservation records requesting changes are completely consistent. The second determination module is used to determine whether the original departure point and original destination of all passenger reservation records to be changed are completely consistent when the preset consistency condition is the second consistency condition. If the original departure point and original destination of all passenger reservation records to be changed are completely consistent, the module binds all passenger reservation records to be changed into a virtual group. The second consistency condition refers to the condition that the departure point and destination of all passenger reservation records requesting changes are completely consistent.

[0022] Furthermore, the binding unit also includes: a first query module, used to query whether there is a historical correlation between all passenger reservation records to be changed; a first detection module, used to detect whether the itineraries indicated by all passenger reservation records to be changed are consistent when there is a historical correlation between them; a first aggregation module, used to aggregate all passenger reservation records to be changed when the itineraries indicated by all passenger reservation records to be changed are consistent, to obtain aggregated records, and to configure virtual group identifiers for the aggregated records to obtain virtual groups; and a first establishment module, used to establish temporary associations for all passenger reservation records to be changed when there is no historical correlation between them, or when the itineraries indicated by all passenger reservation records to be changed are inconsistent, and to configure virtual group identifiers for all passenger reservation records to be changed based on the temporary associations to obtain virtual groups.

[0023] Furthermore, the collaborative change device also includes: a first determining module, used to determine a set of candidate flights and a set of candidate cabin classes based on the target flight information before generating a set of candidate flight change schemes based on the original flight information and target flight information corresponding to each passenger reservation record to be changed; a first grouping module, used to group all passenger reservation records to be changed according to the flight and cabin class dimensions based on all original flight information to obtain multiple sets of change records, wherein each set of change records corresponds to a change fee strategy; and a first calculation module, used to calculate the change fee for each candidate cabin class under each candidate flight based on the set of candidate flights and the set of candidate cabin classes, using the change fee strategy.

[0024] Furthermore, the generation unit includes: a second calculation module for calculating seat adjacency based on the number of seats in each candidate cabin class under each candidate flight; a second determination module for determining the departure time and transfer time of each candidate flight; a first arrangement module for arranging each candidate cabin class under each candidate flight using change cost, seat adjacency, departure time, and transfer time as dimensions, to obtain a permutation and combination of flight change candidate schemes under each dimension; and a first generation module for generating a set of flight change candidate schemes based on the permutation and combination of flight change candidate schemes under all dimensions.

[0025] Furthermore, the change unit includes: a first configuration module, used to configure the lock duration based on the sales status of the target flight indicated by the target flight change scheme and the number of passenger reservation records to be changed, and generate a transaction log for the target flight; a first change module, used to perform flight changes on all passenger reservation records to be changed in the virtual group within the lock duration, and obtain the change result; and a first close module, used to record the change completion in the transaction log and close the virtual group when the change result indicates that all passenger reservation records to be changed have been changed.

[0026] Furthermore, the collaborative change device also includes: after obtaining the change result, a first acquisition module, used to acquire the reason for the change failure if the change result indicates that there are passenger reservation records to be changed that failed to change; a first retry module, used to retry the change of the passenger reservation records to be changed that failed to change if the reason for the change failure indicates a network reason, until the number of retries reaches a preset number or the change is successful; and a first rollback module, used to roll back all passenger reservation records to be changed that have been changed successfully based on the transaction log if the reason for the change failure indicates a business reason, and reselect and determine the target flight change plan.

[0027] According to another aspect of the present invention, a computer program product is also provided, including a non-volatile computer-readable storage medium storing a computer program, wherein the computer program, when executed by a processor, implements the method for collaborative modification of multi-passenger tickets as described above.

[0028] According to another aspect of the present invention, an electronic device is also provided, including one or more processors and a memory, the memory being used to store one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors cause the one or more processors to implement any of the above-described methods for collaboratively changing multi-passenger tickets.

[0029] In this invention, a multi-passenger ticket change request is received. Based on a preset consistency condition, all passenger reservation records to be changed are bound into a virtual group. Based on the original flight information and target flight information corresponding to each passenger reservation record to be changed, a set of flight change candidate schemes is generated. When a passenger selects a target flight change scheme from the set of flight change candidate schemes, the flight change is performed on all passenger reservation records to be changed in the virtual group based on the target flight change scheme, thus completing the multi-passenger ticket change request. This solves the technical problem in related technologies that it is impossible to efficiently and collaboratively change multi-passenger tickets.

[0030] In this invention, a request comprising multiple passenger reservation records to be changed, along with their original and target flight information, is first received. These PNRs are then automatically aggregated into a virtual group based on preset consistency conditions. A set of flight change candidate schemes, encompassing multiple dimensions such as cost and seat adjacency, is generated for the passenger to choose the optimal scheme. If the passenger selects a target change scheme, a consistent flight change operation is executed on all PNRs within the virtual group based on distributed transaction control technology, ensuring the synergy of the rescheduling service and the atomicity of transactions. Thus, through dynamic binding and virtual group management, the goal of optimizing collaborative rescheduling operations across multiple PNRs is achieved, resulting in highly efficient and intelligent processing of multi-passenger ticket changes. Attached Figure Description

[0031] The accompanying drawings, which are included to provide a further understanding of the invention and form part of this invention, illustrate exemplary embodiments of the invention and are used to explain the invention, but do not constitute an undue limitation of the invention. In the drawings:

[0032] Figure 1 This is a flowchart of an optional method for collaborative modification of multi-passenger tickets according to an embodiment of the present invention;

[0033] Figure 2 This is a schematic diagram of an optional multi-PNR collaborative rescheduling system structure according to an embodiment of the present invention;

[0034] Figure 3 This is a schematic diagram of an optional virtual group creation process according to an embodiment of the present invention;

[0035] Figure 4 This is a schematic diagram of an optional multi-rule hierarchical calculation process according to an embodiment of the present invention;

[0036] Figure 5 This is a schematic diagram of an optional distributed transaction commit and rollback process according to an embodiment of the present invention;

[0037] Figure 6 This is a schematic diagram of an optional multi-passenger ticket collaborative change device according to an embodiment of the present invention;

[0038] Figure 7 This is a hardware structure block diagram of an electronic device (or mobile device) for a collaborative change method for multi-passenger tickets according to an embodiment of the present invention. Detailed Implementation

[0039] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0040] It should be noted that the terms "first," "second," etc., used in this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0041] To facilitate understanding of the present invention by those skilled in the art, some terms or nouns involved in the various embodiments of the present invention are explained below:

[0042] PNR (Passenger Name Record): This refers to passenger reservation records, which reflect the passenger's itinerary, the number of seats occupied on the flight, and passenger information.

[0043] Change: refers to modifying a ticket that has already been issued.

[0044] Voluntary change: refers to changes initiated by the passenger on their ticket.

[0045] Original ticket: refers to a ticket that needs to be changed.

[0046] New ticket: refers to the ticket after the change.

[0047] PSS (Passenger Service System): refers to an airline's passenger service system, which includes the reservation system and departure system.

[0048] It should be noted that all related information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, and displayed data) collected and involved in this invention are information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, storage, use, processing, transmission, provision, disclosure, and application of this data comply with the relevant laws, regulations, and standards of the relevant regions, necessary confidentiality measures have been taken, and it does not violate public order and good morals. Corresponding operation entry points are provided for users to choose to authorize or refuse. For example, this system has an interface with relevant users or organizations. Before obtaining relevant information, a request to obtain the information needs to be sent to the aforementioned user or organization through the interface, and the relevant information is obtained only after receiving consent from the aforementioned user or organization.

[0049] This invention proposes a multi-PNR passenger collaborative rescheduling service method based on virtual groups and rule engines. Through virtual group management, multi-rule engine integration and distributed transaction control, an aviation rescheduling service system (i.e., multi-PNR collaborative rescheduling system) is constructed, which solves the problems of inefficient operation, rigid rules and frequent conflicts in the current system.

[0050] The multi-PNR collaborative rescheduling system proposed in this invention can dynamically bind multiple PNRs through a virtual group management module, supporting non-associated PNR matching and separation of PNR history tracing, supporting strong / weak consistency configuration, and flexibly adapting to different rescheduling scenarios. Through a multi-rule engine module, it can process basic policy verification, cost calculation, and intelligent recommendation in a layered manner to ensure the efficient execution of complex business rules. Through a distributed transaction module, it can guarantee the atomicity of cross-PNR operations based on the Saga pattern (i.e., a method for coordinating long transactions or a series of sub-transactions in a distributed system), and provide a highly reliable transaction commit and rollback mechanism.

[0051] The present invention will now be described in detail with reference to various embodiments.

[0052] Example 1

[0053] According to an embodiment of the present invention, an embodiment of a collaborative change method for multi-passenger tickets is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0054] Figure 1 This is a flowchart of an optional collaborative change method for multi-passenger tickets according to an embodiment of the present invention, such as... Figure 1 As shown, the method includes the following steps:

[0055] Step S101: Receive multiple passenger ticket change requests, wherein the multiple passenger ticket change requests include: multiple passenger reservation records to be changed, the original flight information corresponding to each passenger reservation record to be changed, and the target flight information.

[0056] In this embodiment of the invention, a multi-PNR collaborative rescheduling system can be used to perform a collaborative change method for multi-passenger tickets.

[0057] Figure 2 This is a schematic diagram of an optional multi-PNR cooperative rescheduling system structure according to an embodiment of the present invention, such as... Figure 2 As shown, the multi-PNR collaborative rescheduling system includes: a virtual group management module, a rule engine module (i.e., a multi-rule engine module), and a transaction coordinator (i.e., a distributed transaction module). Users can initiate multi-passenger ticket change requests to the multi-PNR collaborative rescheduling system, and process these requests through interaction with the PSS system (including: the civil aviation reservation system and the fare inquiry system) to fulfill the user's multi-PNR collaborative rescheduling needs.

[0058] In this embodiment of the invention, the multi-PNR collaborative rescheduling system can receive multiple passenger ticket change requests from users (such as families, groups, etc.), requesting simultaneous changes to the itineraries of multiple passengers. The request includes information such as "multiple passenger booking records to be changed" (i.e., multiple PNRs), "original flight information" (flight details at the time of booking for each PNR, including flight number, date, departure point, and destination), and "target flight information" (details of the new flight the passenger wishes to change to).

[0059] Step S102: Based on the preset consistency condition, bind all passenger reservation records to be changed into a virtual group.

[0060] In this embodiment of the invention, the preset consistency condition refers to the rules set by the system administrator or airline to determine whether multiple PNRs can be bound into a virtual group for collaborative rescheduling. The condition may include "strong consistency" (the original flight number, date, departure point, and destination are completely consistent) or "weak consistency" (the original departure point and destination are consistent, but different flight numbers / dates are allowed).

[0061] In this embodiment of the invention, if multiple PNRs submitted by the user pass the check according to preset consistency conditions, the multiple PNRs can be bound into a virtual group. Here, the establishment of a virtual group means allowing the system to treat multiple PNRs as a whole, thereby enabling unified processing in subsequent rescheduling operations, which can improve operational efficiency and coordination. For example, the system can automatically identify and combine related PNRs according to consistency conditions through logical judgment and aggregation mechanisms to generate a virtual group ID (identifier).

[0062] Step S103: Based on the original flight information and target flight information corresponding to each passenger reservation record to be changed, generate a set of flight change candidate schemes, wherein the set of flight change candidate schemes includes: permutations and combinations of flight change candidate schemes in multiple dimensions.

[0063] In this embodiment of the invention, the "set of flight change candidate schemes" is a collection of multiple potential rescheduling options calculated and generated by the system based on information about the original flight and the target flight, combined with factors such as airline rescheduling policies, flight inventory, and prices. Each scheme may consider multiple dimensions such as cost, seat adjacency, and transfer time to provide passengers with the optimal choice. For example, through a rules engine and data processing, the system can quickly process a large number of PNR rescheduling requests, perform cabin class compatibility checks, group pricing, and fee calculations, while providing intelligent recommendation strategies to automatically generate multiple rescheduling combination schemes.

[0064] Step S104: Upon receiving the target flight change plan selected by the passenger from the flight change candidate plan set, the flight change is performed on all passenger reservation records to be changed in the virtual group based on the target flight change plan, thus completing the multi-passenger ticket change request.

[0065] In this embodiment of the invention, after a passenger selects from the recommended candidate options, the system will execute the specific flight change operation. The system must ensure that all PNRs bound to the virtual group are changed synchronously according to the selected option, that is, to perform "all-success" or "all-failure" distributed transaction processing to avoid situations where some PNRs are changed successfully while others fail, thus maintaining data consistency. For example, the system adopts a distributed transaction control mechanism (such as the Saga pattern) to perform operations such as pre-reservation of seats, submission of rescheduling requests, intelligent retries, and failure rollback to ensure the consistency and atomicity of cross-PNR changes.

[0066] Through the above steps, the embodiments of the present invention can effectively coordinate and handle complex multi-PNR rescheduling requests, improve the rescheduling experience for passengers, and reduce the risk of airline operational errors and resource conflicts, thus realizing intelligent, efficient and collaborative rescheduling services.

[0067] In summary, the system first receives requests containing multiple passenger reservation records to be changed, along with their original and target flight information. Based on preset consistency conditions, these PNRs are automatically aggregated into virtual groups. Then, a set of flight change candidate solutions, encompassing multiple dimensions such as cost and seat adjacency, is generated for passengers to choose the optimal solution. If a passenger selects a target change solution, a consistent flight change operation is executed on all PNRs within the virtual group using distributed transaction control technology, ensuring the coordination and atomicity of the rescheduling service. Thus, through dynamic binding and virtual group management, the system optimizes collaborative rescheduling operations for multiple PNRs, achieving highly efficient and intelligent processing of multi-passenger ticket changes. This solves the technical problem of inefficient collaborative changes for multiple passenger tickets in related technologies.

[0068] To improve the accuracy of binding all passenger reservation records to be modified into virtual groups, in the collaborative modification method for multi-passenger tickets provided in Embodiment 1 of this application, upon receiving a multi-passenger ticket modification request, a consistency check is performed on all passenger reservation records to be modified based on a preset consistency condition. The passenger reservation records to be modified include the original flight number, original date, original departure point, and original destination. If the preset consistency condition is a first-type consistency condition, it is determined whether the original flight number, original date, original departure point, and original destination contained in all passenger reservation records to be modified are completely consistent. If all destinations are completely identical, bind all passenger reservation records to be changed into a virtual group. The first type of consistency condition means that the flight number, date, departure point, and destination of all passenger reservation records requesting changes are completely identical. If the preset consistency condition is the second type of consistency condition, determine whether the original departure point and original destination of all passenger reservation records to be changed are completely identical. If the original departure point and original destination of all passenger reservation records to be changed are completely identical, bind all passenger reservation records to be changed into a virtual group. The second type of consistency condition means that the departure point and destination of all passenger reservation records requesting changes are completely identical.

[0069] In this embodiment of the invention, when the system receives a multi-passenger ticket change request, it immediately activates the virtual group management module to perform a consistency check on all passenger reservation records to be changed in the request. Here, "passenger reservation records to be changed" refers to all PNRs submitted by the user for which flight changes are desired. Each PNR stores key information such as the passenger's original flight number, original date, original departure point, and original destination.

[0070] In this embodiment of the invention, if the preset consistency condition is the first type of consistency condition (i.e., strong consistency), the system can call the PSS system API (Application Programming Interface) to read the original flight details of each PNR one by one, and then compare whether the original flight number, original date, original departure point, and original destination recorded in all PNRs are completely consistent. If all the information of all PNRs is completely identical, it indicates that the passengers originally planned to take the same flight and travel from the same departure point to the same destination on the same day, which meets the strong consistency requirement. At this time, the system will automatically bind these PNRs into a virtual group and mark it as a "strong consistency virtual group" to prepare for the next step of unified rescheduling operation.

[0071] In this embodiment of the invention, if the preset consistency condition is the second type of consistency condition (i.e., weak consistency), the system can read the original flight information of each PNR, but only compares whether the original departure point and the original destination are consistent. If all PNRs have the same departure point and destination, but the flight number or date may be different, then the system considers these PNRs to meet the weak consistency condition and can be bound into a virtual group, marked as a "weak consistency virtual group". In this case, the system will allow passengers to perform cross-flight and cross-date rescheduling operations within the same route to accommodate more diverse rescheduling needs.

[0072] In this embodiment, consistency checks can intelligently identify passenger demand scenarios and adopt corresponding strategies to dynamically bind PNRs. This effectively aggregates relevant PNRs to form virtual groups, providing a unified entry point for subsequent rescheduling operations. This avoids the inefficiency and risks associated with operating each PNR individually, while also taking into account the overall needs of group travel and the flexibility of individual needs, thus achieving efficient, collaborative, and intelligent rescheduling services.

[0073] To further improve the accuracy of binding all passenger reservation records to be modified into virtual groups, the collaborative modification method for multi-passenger tickets provided in Embodiment 1 of this application queries whether there is a historical correlation between all passenger reservation records to be modified; if there is a historical correlation between all passenger reservation records to be modified, it checks whether the itineraries indicated by all passenger reservation records to be modified are consistent; if the itineraries indicated by all passenger reservation records to be modified are consistent, all passenger reservation records to be modified are aggregated to obtain aggregated records, and a virtual group identifier is configured for the aggregated records to obtain virtual groups; if there is no historical correlation between all passenger reservation records to be modified, or if the itineraries indicated by all passenger reservation records to be modified are inconsistent, a temporary association is established for all passenger reservation records to be modified, and a virtual group identifier is configured for all passenger reservation records to be modified based on the temporary association to obtain virtual groups.

[0074] In this embodiment of the invention, when the system receives multiple passenger ticket change requests, it can activate the virtual group management module to query whether there is a historical correlation between all passenger booking records to be changed. Here, the historical correlation check mainly identifies whether these PNRs originated from the same original PNR, i.e., whether they were once part of the same order and were later separated into independent sub-PNRs (e.g., the original PNR was split into sub-PNR1 and sub-PNR2) due to certain reasons (such as some members changing their dates or itineraries in advance). This check can be performed by calling the PSS system's API to obtain the ticketing history information of each PNR, including but not limited to the original PNR identifier, purchase time, and purchase channel, to determine whether there is a direct or indirect correlation between the PNRs.

[0075] In this embodiment of the invention, when there is a historical correlation among all passenger reservation records to be changed, the system will further check whether the itineraries indicated by all passenger reservation records to be changed are consistent. Itinerary consistency checks include comparing the original flight numbers, dates, departure points, and destinations of all sub-PNRs to ensure that passengers on all PNRs plan to travel on the same flight along the same route. If the itineraries are consistent, the system will perform an aggregation operation on all passenger reservation records to be changed, marking them as a "reverse rescheduling coordination group," treating these PNRs as a whole and generating a unified aggregated record. Subsequently, a virtual group identifier is configured for this aggregated record, forming a virtual group to support subsequent unified rescheduling operations. In this way, even if a passenger's PNR was previously separate, it can be re-aggregated to achieve seamless group rescheduling services. If there is an itinerary deviation (such as inconsistent flight dates), it is marked as "non-associated pending processing."

[0076] In this embodiment of the invention, if there is no historical correlation between all the passenger reservation records to be changed, or if the itineraries indicated by all the passenger reservation records to be changed are inconsistent, this means that these PNRs are either originally unrelated or belong to different itinerary plans. In this case, the system will adopt another strategy: establish a temporary association for each individual PNR. By comparing key itinerary information (such as departure and destination), even if the flight number or date differs, as long as the final destination is the same, these PNRs can be considered to have potential for collaborative rescheduling. Subsequently, the system will configure virtual group identifiers for these PNRs and generate virtual groups, but these virtual groups are marked as "non-associated temporary groups". This processing method allows the system to attempt to aggregate PNRs with similar itinerary needs even in the absence of direct historical correlation, providing a unified rescheduling service entry point.

[0077] Figure 3 This is a schematic diagram of an optional virtual group creation process according to an embodiment of the present invention, such as... Figure 3As shown, the process for creating a virtual group is as follows:

[0078] Step 1: Virtual Group Condition Configuration and Verification: The airline / system administrator presets strong and weak consistency configurations. The virtual group service module (virtual group management module) can save the preset strong and weak consistency configurations. After the user submits the PNR list, the virtual group service module calls the rule engine module to perform rule parameter verification based on the strong and weak consistency configurations (to determine whether they conform to the consistency rules). The rule engine module returns the rule verification result. After the rule verification result indicates that it conforms to the consistency rules, proceed to Step 2.

[0079] Step 2: Unified PNR Entry Management: The Virtual Group Service Module calls the PSS system to query historical records. The PSS system returns the historical PNR links. If a historical association exists, the Virtual Group Service Module requests a trip consistency check from the Rule Engine Module. The Rule Engine Module calls the PSS system to verify the flight status. The PSS system returns the verification result to the Rule Engine Module, which in turn returns the rule verification result to the Virtual Group Service Module. If the trips are consistent, the sub-PNRs are re-aggregated. If the trips deviate, they are marked as "non-associated and pending processing." If no historical association exists, non-associated aggregation is performed to generate a Virtual Group ID. If the consistency rules are not met, the Virtual Group Service Module prompts the user that rescheduling cannot be performed simultaneously, initiating exception handling. Specifically, the Virtual Group Service Module records the operation log and asynchronously releases pre-allocated resources.

[0080] In this embodiment, regardless of whether a passenger's PNR has historical correlation or whether their itineraries are completely identical, the system can provide a unified service process and optimization solution for multi-PNR rescheduling requests in different scenarios through flexible aggregation strategies. This improves the efficiency of rescheduling group travel, reduces repetitive operations on the passenger's end, and also lowers the error rate and resource conflict risk in airline operations, achieving intelligent and collaborative services. Through the aggregated virtual groups, the system can perform batch cabin class compatibility checks, cost calculations, and transactional rescheduling operations, providing users with a highly customized and optimized rescheduling service experience.

[0081] To improve the accuracy of calculating change fees, in the collaborative change method for multi-passenger tickets provided in Embodiment 1 of this application, before generating a set of candidate flight change schemes based on the original flight information and target flight information corresponding to each passenger reservation record to be changed, a set of candidate flights and a set of candidate cabin classes are determined based on the target flight information; based on all original flight information, all passenger reservation records to be changed are grouped according to the flight and cabin class dimensions to obtain multiple sets of change records, wherein each set of change records corresponds to a change fee strategy; based on the set of candidate flights and the set of candidate cabin classes, the change fee strategy is used to calculate the change fee for each candidate cabin class under each candidate flight.

[0082] In this embodiment of the invention, a set of candidate flights and a set of candidate cabin classes can be determined first based on the target flight information. For example, the system can query available flight information from the original departure point to the destination by calling the API of the airline or GDS, and filter out the set of candidate flights that meet the conditions such as target date, route, and time preference. Simultaneously, for each candidate flight, the system will further obtain different bookable cabin class types to form a set of candidate cabin classes. Then, based on all the original flight information, the system can group all passenger reservation records to be changed according to the flight and cabin class dimensions, so that different change fee strategies can be applied in a targeted manner later. This grouping logic takes into account the particularity of each PNR, such as the differences in corporate agreement rates, group discounts, and other policies that may apply to different PNRs, grouping PNRs with the same policies together to obtain multiple groups of change records. The system then calculates the change fee for each candidate flight and each candidate cabin class based on the candidate flight set and candidate cabin class set, using a change fee strategy. For example, the system can iterate through the candidate flight set, and for each candidate flight, iterate through its candidate cabin class set, applying the predefined change fee strategy to calculate the cost for each passenger to change from their original cabin class to a different candidate cabin class. During the calculation process, the system considers factors such as cabin class differences, rescheduling fees, and group discounts to ensure the accuracy and fairness of the fees. In this way, the system can generate a detailed fee list, allowing users to clearly understand the cost of different change options.

[0083] Figure 4 This is a schematic diagram of an optional multi-rule hierarchical calculation process according to an embodiment of the present invention, such as... Figure 4 As shown, the multi-rule hierarchical calculation process is as follows:

[0084] Step 1: Cabin Class Compatibility Verification: The Virtual Group Service Module sends a cabin class verification request to the Rule Engine Module. The Rule Engine Module calls the PSS system to query the original cabin class. The PSS system returns Economy / Business / First Class. The Rule Engine Module calls the PSS system to obtain the target cabin class status. The PSS system returns a list of open cabin classes. If rescheduling is allowed, the Rule Engine Module sends a request to the Virtual Group Service Module to pay the price difference. If rescheduling is restricted, the Rule Engine Module sends an interception prompt to the user (cabin cannot be rescheduled).

[0085] Step 2: Grouping and Fee Calculation: The Virtual Group Service Module initiates grouping by [Flight + Cabin Class] to the Rule Engine Module. The Rule Engine Module returns the grouped dataset. The Virtual Group Service Module then initiates calculation of the tiered discount to the Rule Engine Module. The calculation formula is: Σ(Single PNR Fee × Tiered Discount). The Rule Engine Module returns a total fee list.

[0086] Step 3: Group discount and negotiated price combined: If a negotiated price exists, it will be applied first, and the remaining cost will be covered by the group discount. Final cost = negotiated price + group discount; if there is no negotiated price, the final cost = pure group discount.

[0087] Step 4: Multi-dimensional Recommendation Generation: Preset weighting rules: cost / seat adjacency / transfer time. The rule engine module calls the PSS system to obtain real-time inventory. The PSS system returns a seat availability distribution map. If there are enough seats for a flight, a plan + total price is generated. If there are insufficient seats for a flight, alternative rescheduling options such as cross-cabin flights are calculated. The rule engine module calls the PSS system to query the available seats for adjacent flights. The PSS system returns a list of flights and inventory. The rule engine module generates other plans + total prices and returns a summary recommended plan + price to the virtual group service module. After the user selects the weighting mode, the virtual group service module returns the recommended plans to the user in weighted order.

[0088] This embodiment provides a comprehensive and detailed method for evaluating and calculating various costs associated with collaborative rescheduling for multiple PNR passengers, ensuring transparency and accuracy in cost calculation. By applying change fee strategies in groups, the system can effectively handle complex business scenarios, such as corporate agreement applications and group tiered discount stacking, presenting passengers with customized rescheduling solutions. This not only improves the efficiency of rescheduling services and enhances the passenger experience, but also helps airlines optimize resource allocation, avoid unnecessary cost expenditures, and achieve a win-win situation of service intelligence and efficiency.

[0089] To improve the accuracy of generating a set of flight change candidate solutions, in the collaborative change method for multi-passenger tickets provided in Embodiment 1 of this application, the seat adjacency is calculated based on the number of seats in each candidate cabin class under each candidate flight; the departure time and transfer time of each candidate flight are determined; the change cost, seat adjacency, departure time, and transfer time are used as dimensions to arrange each candidate cabin class under each candidate flight, resulting in a permutation and combination of flight change candidate solutions under each dimension; and a set of flight change candidate solutions is generated based on the permutation and combination of flight change candidate solutions under all dimensions.

[0090] In this embodiment of the invention, the system can obtain real-time seat information for each candidate cabin class on each candidate flight through API calls, including the number of remaining seats and the seat layout. Then, based on the seat layout information, the system calculates the probability of seat adjacency for different passengers on the target flight. The calculation of seat adjacency involves a deep understanding of the seat layout and matching the number of passengers in the passenger's PNR (Personal Nomenclature) to maximize the chances that team members can sit in the same or adjacent rows, improving the comfort and convenience of team travel. Furthermore, the system automatically retrieves the detailed timetable for each candidate flight, extracting the departure time and, if a transfer is required, the transfer time. Determining the departure time and transfer time helps the system comprehensively consider passengers' time costs and provide them with the most suitable flight options.

[0091] In this embodiment of the invention, the system can use change cost, seat adjacency, departure time, and transfer time as dimensions to arrange each candidate cabin class for each candidate flight, resulting in a permutation and combination of flight change candidate schemes under each dimension. Specifically, based on the information collected above, the system generates permutations and combinations for each cabin class of each candidate flight according to four dimensions: lowest change cost, highest seat adjacency, earliest (or latest) departure time (depending on passenger preference), and shortest (or longest) transfer time (considering rest time). Through this multi-dimensional cross-combination, the system can provide passengers with diverse rescheduling options to meet the specific needs of different passenger groups. Then, the system will integrate the candidate schemes under all dimensions according to the passenger's preference priority or selected ranking criteria to form a comprehensive set of flight change candidate schemes. This set not only includes key indicators such as cost, time, and seat adjacency, but also provides a wealth of candidate flights and cabin class options, allowing passengers to choose the most suitable rescheduling scheme based on their actual situation.

[0092] In this embodiment, through comprehensive evaluation and intelligent recommendation of candidate flights and cabin classes, the system can provide passengers with more personalized and comprehensive rescheduling suggestions in multi-PNR passenger collaborative rescheduling services. This not only considers cost minimization but also addresses seat proximity among team members and overall travel time costs, improving satisfaction with the rescheduling service. Simultaneously, by leveraging multi-dimensional considerations, the system can avoid resource competition issues under a single standard, effectively manage airline seat inventory, promote the rational allocation of flight resources, and thereby improve airline operational efficiency and passenger service levels.

[0093] To accurately modify flight records for all passenger reservations in a virtual group, the collaborative modification method for multi-passenger tickets provided in Embodiment 1 of this application configures a lock duration based on the sales status of the target flight indicated by the target flight modification scheme and the number of passenger reservation records to be modified, and generates a transaction log for the target flight. Within the lock duration, flight modifications are performed on all passenger reservation records in the virtual group to obtain modification results. When the modification results indicate that all passenger reservation records to be modified have been modified, the modification is recorded as complete in the transaction log, and the virtual group is closed.

[0094] In this embodiment of the invention, in the multi-PNR passenger collaborative rescheduling service, when a user selects a target flight rescheduling option, the system immediately checks the sales status of the target flight, analyzing its seat inventory, flight popularity, and booking trends. Based on the flight's sales status and the number of passenger booking records to be changed (i.e., the total number of passenger PNRs in the virtual group), the system dynamically configures a reasonable lock-in duration. The lock-in duration setting must consider two factors: ensuring sufficient time to complete the rescheduling operations for all PNRs to avoid transaction failures due to insufficient operation time, and avoiding excessively long lock-in times that prevent other passengers from booking the flight, thereby causing resource waste or customer complaints. After the lock-in duration is determined, the system generates a transaction log, recording key information such as the target flight, the number of PNRs to be changed, and the lock-in duration, providing a basis for the management and monitoring of distributed transactions.

[0095] In this embodiment of the invention, after locking the target flight seats, the system will initiate a flight change operation, rescheduling all passenger reservation records awaiting change in the virtual group within the lock duration. For example, the system can call the PSS system's API to submit a rescheduling request while monitoring the transaction execution status. When the system detects that all PNRs have been successfully rescheduled, indicating that all passenger reservation records awaiting change have been completed, the completion status can be recorded in the transaction log. Then, the virtual group is closed, signifying that all passenger PNRs within the virtual group have been successfully rescheduled, and the virtual group's mission is complete. After closing the virtual group, the system will release all system resources associated with that virtual group, including but not limited to reserved seat locks and temporary associations, ensuring effective resource recovery and continuous optimization of system performance.

[0096] In this embodiment, by introducing a distributed transaction management mechanism, resource contention and data consistency issues in multi-PNR rescheduling operations are effectively controlled. Dynamic configuration of lock duration and generation of transaction logs provide a time window and operation trajectory record for rescheduling operations, ensuring fairness in seat allocation and integrity of rescheduling operations in high-concurrency scenarios. Furthermore, the virtual group closure mechanism achieves closed-loop management of rescheduling transactions, guaranteeing efficient utilization of system resources and providing passengers with a unified, convenient, and controllable rescheduling service process, thus improving the overall experience and satisfaction of rescheduling services. This multi-PNR rescheduling service design based on a rule engine and distributed transaction management provides strong technical support for intelligent services in the aviation industry.

[0097] To ensure the atomicity of cross-PNR operations, in the collaborative change method for multi-passenger tickets provided in Embodiment 1 of this application, after obtaining the change result, if the change result indicates that there are passenger reservation records to be changed that failed to change, the reason for the change failure is obtained; if the reason for the change failure indicates a network reason, the passenger reservation records to be changed that failed to change are retried until the number of retries reaches a preset number or the change is successful; if the reason for the change failure indicates a business reason, based on the transaction log, all passenger reservation records to be changed that have been successfully changed are rolled back, and the target flight change plan is reselected and determined.

[0098] In this embodiment of the invention, when the system encounters a failure to change the reservation record of one or more passengers during the process of rescheduling flights for multiple PNR passengers, it immediately triggers a process to obtain the reason for the failure. This process, through communication with the PSS system or other relevant external services, parses out the exact reason for the failure, which typically falls into two main categories: network reasons and business reasons. Among them, network reasons may involve network connection timeouts, slow server response, etc., while business reasons may involve insufficient inventory, or problems at the airline or GDS level.

[0099] If the failure is confirmed to be due to network issues, the system will initiate an intelligent retry mechanism to retry the PNR changes for those passengers. There is a preset upper limit to the number of retries to prevent infinite loops that could impact system stability and efficiency. For example, the retry strategy uses an exponential backoff algorithm, where the retry interval gradually increases and random jitter is added to avoid initiating a large number of concurrent requests at the same time, thus reducing network load. If the date change is successful within the retry limit, the system will continue with subsequent operations; conversely, if the retry limit is reached and the change is still unsuccessful, the system will determine that the change operation cannot be completed at the network level and will then handle other types of failures.

[0100] If the failure is determined to be due to business reasons, it means the system cannot immediately resolve the issue, for example, the target flight's seat inventory has been exhausted. In this case, the system will perform a rollback operation based on previously generated transaction logs, undoing all successfully changed PNR rescheduling actions and releasing the corresponding seat resources. To avoid data inconsistency and resource waste, the rollback operation will be placed in a separate message queue to ensure it is executed at least once, and will be verified using the transaction ID to prevent duplicate rollbacks. After the rollback is complete, the system will notify the user of the change failure, explain the reason for the failure, and provide the option to reselect a change plan for the target flight, guiding the user to reselect a flight or cabin class, or even providing alternative flight combinations to achieve the final goal of collaborative rescheduling.

[0101] Figure 5 This is a schematic diagram of an optional distributed transaction commit and rollback process according to an embodiment of the present invention, as shown below. Figure 5 As shown, the distributed transaction commit and rollback process is as follows:

[0102] Step 1: Reservation and Lock Management: The user initiates a collaborative rescheduling request to the transaction coordinator. The transaction coordinator dynamically sets the reservation time (based on popularity / complexity). The transaction coordinator calls the PSS system to reserve seats on the target flight. The PSS system returns the reservation result. The transaction coordinator calls the log system to generate a transaction log (status: reservation in progress, number of locked seats, duration).

[0103] Step 2: Commit Reschedule Requests: The transaction coordinator submits reschedule requests to the PSS system one by one. Upon successful submission, a success message is returned, and the transaction coordinator updates the status to "Completed" in the log system. If the submission fails, an error code is returned, generating a unique error ID.

[0104] Step 3: Failure Handling: If the error is network-related, a retry mechanism is initiated (maximum 3 times), performing exponential backoff retries. The transaction coordinator submits a retry request to the PSS system, and the PSS system returns the result. If the error is business-related (insufficient inventory), a reverse rollback operation is triggered. The transaction coordinator checks the message queue to see if the instruction ID has been executed. If not, the transaction coordinator initiates a rollback operation to the PSS system, releasing the occupied inventory. After successful execution, the PSS system updates its status to "Rollback Completed" and records the reason for failure. The transaction coordinator generates an alternative solution. If the instruction has already been executed, duplicate instructions are discarded.

[0105] Step 4: Final Transaction Commit: If all PNR reschedulings are successful, the transaction coordinator updates the status to "Closed" in the log system and sends a confirmation notification to the client. If the rescheduling operation fails and rolls back, the user is informed of the reason for the failure and an alternative solution is provided.

[0106] In this embodiment, a complete, intelligent, and highly reliable failure handling and system recovery mechanism was constructed to ensure the robustness and user experience of the multi-PNR passenger collaborative rescheduling service. Intelligent retries handle failures caused by network issues, minimizing operational interruptions and delays and improving service success rates. When facing failures due to business reasons, a rollback mechanism based on transaction logs and alternative solution recommendations not only protect the integrity of system data and the rational use of resources but also provide users with timely feedback and solutions, enhancing service resilience and passenger satisfaction.

[0107] The following section provides a detailed explanation of another optional implementation scenario.

[0108] Example Scenario 1: A family of 6 originally booked flight PNR-A on May 1, 2025, MU505. Due to itinerary adjustments, they rescheduled their flights as follows: PNR-B (grandparents): May 3, 2025, MU505; PNR-C (father + children A / B): May 3, 2025, MU505; PNR-D (mother): May 3, 2025, MU505. Now, the entire family needs to reschedule to May 2, 2025, MU707.

[0109] The specific steps for rescheduling are as follows:

[0110] Step 1: Consistency Condition Configuration: The airline administrator configures the virtual group binding rule as a weak consistency rule according to business needs: requiring the original departure point and destination to be completely consistent.

[0111] Step 2: Historical Association Tracing and Dynamic Binding: When the system scanned PNR-B, PNR-C, and PNR-D, it found historical associations: all three were split from the original PNR-A. Although they were rescheduled individually, the rescheduled itineraries were completely identical, meeting the conditions for re-aggregation. PNR-B, PNR-C, and PNR-D were bound to the virtual group VG-001.

[0112] Step 3: Cabin class compatibility verification: The system checks the original PNR cabin class (economy class) and the availability of cabins for the target date flight, and returns information on all reschedulable flights and cabin classes.

[0113] Step 4: Grouped Pricing and Fee Calculation: The fee rules, based on different PNR rescheduling policies, are shown in Table 1.

[0114] Table 1

[0115] PNR cabin Ticket price (RMB / person) Rescheduling fee PNR-B, PNR-C M (Original Cabin) 800 20％ PNR-D Y (original cabin) 900 10％ - Y (Target) 900

[0116] Step 5: Combine the negotiated price with the group discount: For non-corporate negotiated prices, directly calculate the rescheduling discount for families or groups of 5 or more: 70% off, i.e., {[800 yuan × 20% + (900 - 800)] × 5 people + 900 × 10% × 1 person} × 0.7 = 973 yuan, total: 973 yuan (saving 417 yuan compared to rescheduling alone).

[0117] Step 6: Multi-dimensional Recommendation Generation: The system combines the day's flight inventory to generate a recommendation scheme.

[0118] Option 1: Flight MU707 (Economy Class, 20 seats remaining), total cost 973 yuan, departure time 10:00 AM.

[0119] Option 2: Flight MU505 (economy class, 15 seats remaining), total cost 950 yuan, but departure time is 17:00.

[0120] After the user selects Option 1, 6 seats will be reserved for the user.

[0121] Step 7: Reservation and Lock Management: The system reserves 6 seats on flight MU707 for virtual group VG-001, with a lock duration of 10 minutes, and generates a transaction log (Transaction ID: TX-001, Status: Reserved).

[0122] Step 8: Submit the rescheduled request: Since it is a re-aggregation of historical PNRs, the PSS system is called to directly initiate a rescheduled request for the aggregated PNRs: The rescheduled request is submitted successfully, and the log is updated to "Completed".

[0123] Step 9: Failure Rollback and Intelligent Retry: Skip this step if no exception occurs.

[0124] Step 10: Final Transaction Commit: After all PNRs are successfully rescheduled, all scattered PNRs are re-aggregated into one PNR. The system sends a confirmation notification to the client and updates the virtual group status to "closed".

[0125] Example Scenario 2: Consider a team of 20 people from a company traveling together. Due to members purchasing tickets in batches or through different channels, their itinerary is scattered across 5 independent PNRs. The original flight CA123 (economy class) from Beijing (PEK) to Shanghai (PVG) on October 1, 2025, needs to be rescheduled to flight CA456 (economy class Y) on the same route on October 2.

[0126] The specific steps for rescheduling are as follows:

[0127] Step 1: Consistency Condition Configuration: The airline administrator configures the virtual group binding rule as a strong consistency rule according to business needs: requiring the original flight number, date, departure point, and destination to be completely consistent.

[0128] Step 2: PNR Historical Relationship Tracing: The system automatically scanned the 5 PNRs submitted by the user and found that 3 of them (PNR-E, PNR-F, PNR-G) were orders under the same enterprise agreement number, while the remaining 2 PNRs (PNR-H, PNR-I) were purchased through personal channels. Although the purchase channels were different, the original flight number, date, departure point, and destination of the 5 PNRs were completely consistent, which met the strong consistency rule. The 5 PNRs had no historical relationship and were marked as "non-related and pending processing".

[0129] Step 3: Non-associated PNR aggregation: The system automatically generates a unique virtual group ID (VG-002) and dynamically binds 5 PNRs.

[0130] Step 4: Cabin Class Compatibility Verification: The system checks the original PNR cabin class (economy class) and the availability of cabins for the target date flight, and returns information on all reschedulable flights and cabin classes.

[0131] Step 5: Grouping and Fee Calculation: Calculate the PNR rescheduling fee by grouping the passengers into the original flight (CA123) and cabin class. For example, PNR-E (2 people), PNR-F (5 people), and PNR-G (5 people) are the corporate agreement price for the same cabin class (H class), PNR-H (5 people) is the private fare for H class, and PNR-I (8 people) is the private fare for Q class.

[0132] The virtual group has a total of 20 members, with 12 members included in the corporate agreement price. Group pricing offers a tiered discount: 20% off for groups of 10 or more. Therefore, PNR-E, PNR-F, and PNR-G form one group using the corporate agreement's rescheduling policy, while PNR-H and PNR-I form another group. The group discount is triggered once the required number of participants is reached.

[0133] Step 6: The negotiated price and group discount are combined, and the fee rules are shown in Table 2:

[0134] Table 2

[0135]

[0136] The corporate agreement price will be applied first, and the remaining fee will be subject to a group discount.

[0137] Total cost calculation (it is known that airlines typically charge a rescheduling fee that includes a rescheduling handling fee plus the fare difference):

[0138] The enterprise's agreed price was rescheduled [800 yuan × 20% + (1000 - 800)] × 12 people = 4320 yuan;

[0139] The group discount price rescheduled is {[1100×25%+(1300-1100)]×5 people+[1000×40%+(1300-1100)]×8 people}×0.8=6380 yuan.

[0140] Total cost: 4320 + 6380 = 10700 yuan.

[0141] Step 7: Multi-dimensional Recommendation Generation: Based on the user's selected "cost-first" mode, the system recommends the following options:

[0142] Option 1: Flight CA456 (Economy Class, 20 seats remaining), total cost 10,700 yuan.

[0143] Option 2: Flight CA567 (15 seats remaining in economy class, 8 seats remaining in business class), total cost between 12,000 and 15,000 yuan, with a note that "some seats can be upgraded to business class, and the fare difference will need to be paid".

[0144] Option 3: Flight CA567 (economy class, 15 seats remaining) and Flight CA789 (economy class, 10 seats remaining), total cost 11,000-12,000 yuan, with a note that "some passengers may need to choose different flights to arrive".

[0145] After the user selects Option 1, the system locks 20 seats on flight CA456 and generates a rescheduling confirmation.

[0146] Step 8: Reservation and Lock Management: The system reserves 20 seats for flight CA456 for virtual group VG-002, locks them for 15 minutes, and generates a transaction log (Transaction ID: TX-002, Status: Reserved).

[0147] Step 9: Submit rescheduled requests: Call the PSS system to submit rescheduled requests for 5 PNRs in batches: PNR-A, PNR-B, and PNR-C were successfully submitted and the log was updated to "Completed", while PNR-D failed to submit for the first time due to network timeout.

[0148] Step 10: Failure Rollback and Intelligent Retry: The system generates a failure error ID (ID: ER-001). PNR-D fails its first commit due to network timeout and initiates intelligent retries (intervals of 2s, 4s, and 8s). The third retry succeeds, and the transaction log is updated to "Completed". The system continues processing the PNR-E failure, which is due to insufficient inventory. A failure error ID (ID: ER-002) is generated, and a rollback operation is immediately executed, releasing 20 seats. The rollback is successful, and the log is updated to "Rollback Completed".

[0149] Step 11: Final Transaction Commit: If the rescheduling operation fails and rolls back, inform the user of the reason for the failure and generate an alternative solution.

[0150] In this embodiment of the invention, the virtual group management module can dynamically bind multiple Passenger Names (PNRs), supporting one-stop collaborative rescheduling for passengers across PNRs and channels, thus improving the operational efficiency of group travel. The multi-rule hierarchical calculation module supports complex business scenarios, including cabin class compatibility verification, group pricing, and the superposition of negotiated prices and group discounts, achieving both accuracy and flexibility in cost calculation. The distributed transaction module ensures "full success" or "full rollback" for cross-PNR operations through pre-reservation of seats, intelligent retries (for network errors), and message queue rollback (for business errors), guaranteeing the atomicity of cross-PNR operations and avoiding overbooking or data inconsistency issues even in high-concurrency scenarios. Furthermore, the dynamic seat-locking strategy based on flight popularity and intelligent recommendations (alternative flights, upgrade options) effectively address inventory shortages, improving resource utilization while ensuring a good user experience. Furthermore, this embodiment supports various scenarios such as family travel, corporate teams, and tour groups, and is compatible with complex needs such as strong / weak consistency rules and personalized restrictions, meeting the differentiated service needs of airlines. It realizes intelligent, collaborative, and highly reliable flight rescheduling services, significantly improving airline service capabilities and passenger satisfaction.

[0151] The following is a detailed description with reference to another embodiment.

[0152] Example 2

[0153] The multi-passenger ticket collaborative change device provided in this embodiment includes multiple implementation units, each of which corresponds to a specific implementation step in Embodiment 1 above.

[0154] Figure 6 This is a schematic diagram of an optional multi-passenger ticket collaborative change device according to an embodiment of the present invention, such as... Figure 6 As shown, the collaborative change device may include: a receiving unit 60, a binding unit 61, a generating unit 62, and a change unit 63.

[0155] The receiving unit 60 is used to receive multiple passenger ticket change requests, wherein the multiple passenger ticket change requests include: multiple passenger reservation records to be changed, the original flight information corresponding to each passenger reservation record to be changed, and the target flight information;

[0156] Binding unit 61 is used to bind all passenger reservation records to be changed into a virtual group based on preset consistency conditions;

[0157] The generation unit 62 is used to generate a set of flight change candidate schemes based on the original flight information and target flight information corresponding to each passenger reservation record to be changed. The set of flight change candidate schemes includes: permutations and combinations of flight change candidate schemes in multiple dimensions.

[0158] The modification unit 63 is used to modify the flight reservation records of all passengers in the virtual group based on the target flight modification scheme selected by the passenger from the flight modification candidate scheme set, and complete the multi-passenger ticket modification request.

[0159] The aforementioned collaborative rescheduling device can receive requests including multiple passenger reservation records to be changed, along with their original and target flight information. Based on preset consistency conditions, it automatically aggregates these PNRs into virtual groups, then generates a set of flight change candidate schemes covering multiple dimensions such as cost and seat adjacency, allowing passengers to choose the optimal solution. If a passenger selects a target change scheme, a consistent flight change operation can be executed on all PNRs within the virtual group based on distributed transaction control technology, ensuring the synergy of the rescheduling service and the atomicity of transactions. Thus, through dynamic binding and virtual group management, the device optimizes collaborative rescheduling operations for multiple PNRs, achieving highly efficient and intelligent processing of multi-passenger ticket changes. This solves the technical problem of inefficient collaborative rescheduling of multi-passenger tickets in related technologies.

[0160] Optionally, the binding unit includes: a first checking module, used to perform a consistency check on all passenger reservation records to be changed based on a preset consistency condition when receiving multiple passenger ticket change requests, wherein the passenger reservation records to be changed contain the original flight number, original date, original departure point, and original destination; and a first determining module, used to determine whether the original flight number, original date, original departure point, and original destination contained in all passenger reservation records to be changed are completely consistent when the preset consistency condition is a first type of consistency condition, and to bind the reservation records if the original flight number, original date, original departure point, and original destination contained in all passenger reservation records to be changed are completely consistent. The passenger reservation records to be changed are virtual groups. The first consistency condition refers to the condition that the flight number, date, departure point, and destination of all passenger reservation records requesting changes are completely consistent. The second determination module is used to determine whether the original departure point and original destination of all passenger reservation records to be changed are completely consistent when the preset consistency condition is the second consistency condition. If the original departure point and original destination of all passenger reservation records to be changed are completely consistent, the module binds all passenger reservation records to be changed into a virtual group. The second consistency condition refers to the condition that the departure point and destination of all passenger reservation records requesting changes are completely consistent.

[0161] Optionally, the binding unit further includes: a first query module, used to query whether there is a historical correlation between all passenger reservation records to be changed; a first detection module, used to detect whether the itineraries indicated by all passenger reservation records to be changed are consistent when there is a historical correlation between them; a first aggregation module, used to aggregate all passenger reservation records to be changed to obtain aggregated records when the itineraries indicated by all passenger reservation records to be changed are consistent, and to configure virtual group identifiers for the aggregated records to obtain virtual groups; and a first establishment module, used to establish temporary associations for all passenger reservation records to be changed when there is no historical correlation between them, or when the itineraries indicated by all passenger reservation records to be changed are inconsistent, and to configure virtual group identifiers for all passenger reservation records to be changed based on the temporary associations to obtain virtual groups.

[0162] Optionally, the collaborative change device further includes: a first determining module, used to determine a set of candidate flights and a set of candidate cabin classes based on the target flight information before generating a set of candidate flight change schemes based on the original flight information and target flight information corresponding to each passenger reservation record to be changed; a first grouping module, used to group all passenger reservation records to be changed according to the flight and cabin class dimensions based on all original flight information to obtain multiple sets of change records, wherein each set of change records corresponds to a change fee strategy; and a first calculation module, used to calculate the change fee for each candidate cabin class under each candidate flight based on the set of candidate flights and the set of candidate cabin classes, using the change fee strategy.

[0163] Optionally, the generation unit includes: a second calculation module for calculating seat adjacency based on the number of seats in each candidate cabin class under each candidate flight; a second determination module for determining the departure time and transfer time of each candidate flight; a first arrangement module for arranging each candidate cabin class under each candidate flight using change cost, seat adjacency, departure time, and transfer time as dimensions, to obtain a permutation and combination of flight change candidate schemes under each dimension; and a first generation module for generating a set of flight change candidate schemes based on the permutation and combination of flight change candidate schemes under all dimensions.

[0164] Optionally, the change unit includes: a first configuration module, configured to configure a lock duration based on the sales status of the target flight indicated by the target flight change scheme and the number of passenger reservation records to be changed, and generate a transaction log for the target flight; a first change module, configured to perform flight changes on all passenger reservation records to be changed in the virtual group within the lock duration, and obtain the change result; and a first close module, configured to record the change completion in the transaction log and close the virtual group when the change result indicates that all passenger reservation records to be changed have been changed.

[0165] Optionally, the collaborative change device further includes: after obtaining the change result, a first acquisition module, used to acquire the reason for the change failure if the change result indicates that there are passenger reservation records to be changed that failed to change; a first retry module, used to retry the change of the passenger reservation records to be changed that failed to change if the reason for the change failure indicates a network reason, until the number of retries reaches a preset number or the change is successful; and a first rollback module, used to roll back all passenger reservation records to be changed that have been changed successfully based on the transaction log if the reason for the change failure indicates a business reason, and reselect and determine the target flight change plan.

[0166] The aforementioned collaborative modification device may also include a processor and a memory. The receiving unit 60, binding unit 61, generating unit 62, modification unit 63, etc., are all stored in the memory as program units, and the processor executes the aforementioned program units stored in the memory to realize the corresponding functions.

[0167] The aforementioned processor contains a kernel, which retrieves the corresponding program units from memory. One or more kernels can be configured. By adjusting kernel parameters, upon receiving a target flight change option selected by a passenger from the flight change candidate set, the kernel will, based on the target flight change option, modify the flight booking records of all passengers in the virtual group to complete the multi-passenger ticket change request.

[0168] The aforementioned memory may include non-permanent memory in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM, and the memory includes at least one memory chip.

[0169] The present invention also provides a computer program product, which, when executed on a data processing device, is suitable for executing a program with the following initialization steps: receiving multiple passenger ticket change requests; binding all passenger reservation records to be changed into a virtual group based on a preset consistency condition; generating a set of flight change candidate schemes based on the original flight information and target flight information corresponding to each passenger reservation record to be changed; and, upon receiving a target flight change scheme selected by a passenger from the set of flight change candidate schemes, performing flight changes on all passenger reservation records to be changed in the virtual group based on the target flight change scheme, thereby completing the multiple passenger ticket change request.

[0170] According to another aspect of the present invention, a computer program product is also provided, including a non-volatile computer-readable storage medium storing a computer program, wherein the computer program, when executed by a processor, implements the method for collaborative modification of multi-passenger tickets as described above.

[0171] According to another aspect of the present invention, an electronic device is also provided, including one or more processors and a memory, the memory being used to store one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors cause the one or more processors to implement the above-described collaborative change method for multi-passenger tickets.

[0172] Figure 7 This is a hardware structure block diagram of an electronic device (or mobile device) for a collaborative change method for multi-passenger tickets according to an embodiment of the present invention. Figure 7 As shown, an electronic device may include one or more processors (e.g., Figure 7 The processors 702a, 702b, ..., 702n, etc., may include, but are not limited to, processing devices such as microprocessors (MCUs) or programmable logic devices (FPGAs), and a memory 704 for storing data. In addition, it may include: a display, an input / output interface (I / O interface), a universal serial bus (USB) port (which may be included as one of the ports of the I / O interface), a network interface, a keyboard, a power supply, and / or a camera. Those skilled in the art will understand that... Figure 7 The structure shown is for illustrative purposes only and does not limit the structure of the electronic device described above. For example, the electronic device may also include components that are more... Figure 7 The more or fewer components shown, or having the same Figure 7 The different configurations shown.

[0173] The sequence numbers of the above embodiments of the present invention are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0174] The embodiments or examples disclosed herein are not exhaustive, but merely illustrative of some embodiments or examples, and are not intended to limit the scope of protection of this disclosure. Unless otherwise specified, each step in a particular embodiment or example can be implemented as an independent embodiment, and the steps can be arbitrarily combined. For example, a solution after removing some steps in a particular embodiment or example can also be implemented as an independent embodiment, and the order of the steps in a particular embodiment or example can be arbitrarily interchanged. Furthermore, optional methods or examples in a particular embodiment or example can be arbitrarily combined; moreover, embodiments or examples can be arbitrarily combined. For example, some or all steps of different embodiments or examples can be arbitrarily combined, and a particular embodiment or example can be arbitrarily combined with optional methods or examples of other embodiments or examples.

[0175] In the above embodiments of the present invention, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0176] In the several embodiments provided by this invention, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units can be a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual coupling, direct coupling, or communication connection can be through some interfaces; the indirect coupling or communication connection of units or modules can be electrical or other forms.

[0177] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0178] Furthermore, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0179] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.

[0180] The above description is only a preferred embodiment of the present invention. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A method for collaboratively changing multi-passenger tickets, characterized in that, include: Receive multiple passenger ticket change requests, wherein the multiple passenger ticket change requests include: multiple passenger reservation records to be changed, the original flight information corresponding to each passenger reservation record to be changed, and the target flight information; Based on the preset consistency condition, all the passenger reservation records to be changed are bound into a virtual group; Based on the original flight information and the target flight information corresponding to each passenger reservation record to be changed, a set of flight change candidate schemes is generated, wherein the set of flight change candidate schemes includes: permutations and combinations of flight change candidate schemes from multiple dimensions; Upon receiving a target flight change plan selected by a passenger from the set of flight change candidate plans, the flight change is performed on all the passenger reservation records to be changed in the virtual group based on the target flight change plan, thus completing the multi-passenger ticket change request.

2. The collaborative change method according to claim 1, characterized in that, The step of binding all the passenger reservation records to be changed into a virtual group based on preset consistency conditions includes: Upon receiving the multi-passenger ticket change request, based on the preset consistency condition, a consistency check is performed on all the passenger reservation records to be changed, wherein the passenger reservation records to be changed include the original flight number, original date, original departure point, and original destination. When the preset consistency condition is the first type of consistency condition, it is determined whether the original flight number, original date, original departure point, and original destination contained in all the passenger reservation records to be changed are completely consistent. If the original flight number, original date, original departure point, and original destination contained in all the passenger reservation records to be changed are completely consistent, all the passenger reservation records to be changed are bound into the virtual group. The first type of consistency condition refers to the condition that the flight number, date, departure point, and destination contained in all the passenger reservation records requesting change are completely consistent. When the preset consistency condition is the second type of consistency condition, it is determined whether the original departure point and the original destination contained in all the passenger reservation records to be changed are completely consistent. If the original departure point and the original destination contained in all the passenger reservation records to be changed are completely consistent, all the passenger reservation records to be changed are bound to the virtual group. The second type of consistency condition refers to the condition that the departure point and the destination contained in all the passenger reservation records requesting change are completely consistent.

3. The collaborative change method according to claim 1, characterized in that, The steps of binding all the aforementioned passenger reservation records to be modified into a virtual group include: Check if there is any historical correlation between all the passenger reservation records to be changed; If the historical correlation exists among all the passenger reservation records to be changed, check whether the itineraries indicated by all the passenger reservation records to be changed are consistent; If all the passenger reservation records to be changed indicate the same itinerary, all the passenger reservation records to be changed are aggregated to obtain an aggregated record, and a virtual group identifier is configured for the aggregated record to obtain the virtual group; If there is no historical association among all the passenger reservation records to be changed, or if the itineraries indicated by all the passenger reservation records to be changed are inconsistent, a temporary association is established for all the passenger reservation records to be changed, and a virtual group identifier is configured for all the passenger reservation records to be changed based on the temporary association to obtain the virtual group.

4. The collaborative change method according to claim 1, characterized in that, Before generating a set of flight change candidate schemes based on the original flight information and the target flight information corresponding to each passenger reservation record to be changed, the process also includes: Based on the target flight information, a set of candidate flights and a set of candidate cabin classes are determined; Based on all the original flight information, according to the flight and cabin class dimensions, all the passenger reservation records to be changed are grouped to obtain multiple groups of change records, wherein each group of change records corresponds to a change fee policy. Based on the candidate flight set and the candidate cabin class set, the change fee strategy is used to calculate the change fee for each candidate cabin class under each candidate flight.

5. The collaborative change method according to claim 4, characterized in that, The step of generating a set of flight change candidate schemes based on the original flight information and the target flight information corresponding to each passenger reservation record to be changed includes: Calculate seat adjacency based on the number of seats in each of the candidate cabin classes for each of the candidate flights; Determine the departure time and transfer time for each of the candidate flights; Using the change fee, seat adjacency, departure time, and transfer time as dimensions, each candidate cabin class under each candidate flight is arranged to obtain the permutation and combination of the flight change candidate schemes under each dimension; Based on the permutations and combinations of the flight change candidate schemes under all dimensions, the flight change candidate scheme set is generated.

6. The collaborative change method according to claim 1, characterized in that, Based on the target flight change plan, the steps for changing flight reservations for all passengers in the virtual group include: Based on the sales status of the target flight indicated by the target flight change plan and the number of passenger reservation records to be changed, configure the lock duration and generate the transaction log of the target flight. During the lockout period, flight changes are performed on all passenger reservation records to be changed in the virtual group to obtain the change results; If the change result indicates that all the passenger reservation records to be changed have been changed, record the change as complete in the transaction log and close the virtual group.

7. The collaborative change method according to claim 6, characterized in that, After obtaining the change results, it also includes: If the change result indicates that there is a passenger reservation record to be changed that failed to change, obtain the reason for the change failure; If the reason for the change failure indicates a network problem, the passenger reservation record to be changed that failed will be retried until the number of retries reaches the preset number or the change is successful. If the reason for the change failure indicates a business-related reason, based on the transaction log, roll back all passenger reservation records that were successfully changed and reselect the target flight change plan.

8. A device for collaboratively changing multi-passenger tickets, characterized in that, include: The receiving unit is used to receive multiple passenger ticket change requests, wherein the multiple passenger ticket change requests include: multiple passenger reservation records to be changed, the original flight information corresponding to each passenger reservation record to be changed, and the target flight information; A binding unit is used to bind all the passenger reservation records to be changed into a virtual group based on a preset consistency condition; The generation unit is used to generate a set of flight change candidate schemes based on the original flight information and the target flight information corresponding to each passenger reservation record to be changed, wherein the set of flight change candidate schemes includes: permutations and combinations of flight change candidate schemes in multiple dimensions; The change unit is used to, upon receiving a target flight change plan selected by a passenger from the set of flight change candidate plans, change the flight booking records of all passengers to be changed in the virtual group based on the target flight change plan, thereby completing the multi-passenger ticket change request.

9. A computer program product, characterized in that, The method includes a non-volatile computer-readable storage medium storing a computer program that, when executed by a processor, implements the collaborative change method for multi-passenger tickets as described in any one of claims 1 to 7.

10. An electronic device, characterized in that, It includes one or more processors and a memory, the memory being used to store one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors cause the one or more processors to implement the collaborative change method for multi-passenger tickets as described in any one of claims 1 to 7.

Images