Aviation freight rate management system and method, electronic equipment and storage medium

Abstract

The embodiment of the invention provides an aviation freight rate management system and method, electronic equipment and a storage medium, and relates to the technical field of network communication. The system comprises a data acquisition module used for acquiring external aviation business data; the strategy specifying module is used for receiving an aviation business management rule configured by a user; the task packaging module is used for packaging the acquired external aviation business data and the aviation business management rule into a business judgment task; the message processing module is used for issuing the service judgment task to a message queue; and the distributed computing cluster is used for obtaining the service judgment task from the message queue in parallel through the plurality of computing nodes, executing the service judgment task to generate an aviation service adjustment scheme, and pushing the aviation service adjustment scheme to a downstream aviation service execution system. The method can be used for an income management system of an airline company, and is used for realizing high-concurrency real-time freight rate and shipping space automatic adjustment.

Description

Technical Field

[0001] This application relates to the field of network communication technology, and in particular to an airfare management system, method, electronic device and storage medium. Background Technology

[0002] With the rapid development of the aviation market, competition in the air transport industry has become increasingly fierce, and airline sales models have exhibited significant characteristics of multi-channel and dynamic operation. Currently, airline fare and cabin sales cover direct sales through official websites, resales through third-party platforms, and sales through enterprise travel information systems. Simultaneous operation across multiple channels has become the industry norm, and the frequency of fare adjustments has increased significantly. Some popular routes even experience multiple price changes per day to cope with market supply and demand fluctuations and competitor strategy adjustments. Against this backdrop, the monolithic architecture or simple distributed design adopted by existing fare management systems is insufficient to handle dynamic market changes and high-concurrency access demands. Summary of the Invention

[0003] The purpose of this application is to provide an air fare management system, method, electronic device, and storage medium, which aims to help airlines make high-concurrency fare management decisions.

[0004] Firstly, this application provides an airfare management system, including a data acquisition module, a strategy specification module, a task encapsulation module, a message processing module, and a distributed computing cluster. The data acquisition module acquires external air traffic data; the strategy specification module receives user-configured air traffic management rules; the task encapsulation module, connecting the data acquisition module and the strategy specification module, encapsulates the acquired external air traffic data and air traffic management rules into business judgment tasks; the message processing module, connected to the task encapsulation module, publishes the business judgment tasks to a message queue; the message queue stores the business judgment tasks and distributes them to multiple computing nodes in the distributed computing cluster according to their business type; the distributed computing cluster, connected to the message processing module, retrieves business judgment tasks in parallel from the message queue through multiple computing nodes, executes the business judgment tasks to generate air traffic adjustment plans, and pushes the air traffic adjustment plans to the downstream air traffic execution system.

[0005] This application provides an airfare management system. Through a data acquisition module, it acquires external aviation business data in real time. Combined with user-configured management rules received by a strategy specification module, this ensures the system can make fare decisions based on the latest market information and flexible, customizable business strategies, thereby improving the timeliness and adaptability of management. Furthermore, a task encapsulation module encapsulates data and rules into business judgment tasks, laying the foundation for automated and large-scale processing. A message processing module publishes tasks to a message queue and, relying on the message queue's mechanism of distributing tasks to a distributed computing cluster according to business type, achieves asynchronous decoupling and load balancing of tasks, effectively avoiding system blocking in high-concurrency scenarios and enhancing the system's scalability and stability. The distributed computing cluster, through multiple computing nodes, retrieves and executes tasks in parallel from the message queue, efficiently and concurrently completing a large number of business judgments and quickly generating aviation business adjustment plans. Finally, the system automatically pushes the adjustment plans to downstream execution systems, forming a closed-loop automated process from data input to plan output. This reduces manual intervention while improving the overall efficiency and response speed of fare management, thereby supporting airlines in achieving accurate and agile fare adjustments in a dynamic market environment.

[0006] In conjunction with the first aspect mentioned above, in one possible implementation, external aviation business data includes airfare data and cabin availability data; the data acquisition module is specifically used to: acquire airfare data from a first type of external platform; the first type of external platform includes an online platform that provides ticket sales information; acquire cabin availability data from a second type of external platform; the second type of external platform includes an aviation information service platform that provides flight schedule and seat inventory management.

[0007] In conjunction with the first aspect above, in one possible implementation, the aviation business management rules include at least one of the following configured by the user for the target flight: price adjustment rules, cabin control rules, and flight screening conditions; wherein, the cabin control rules include cabin opening conditions, cabin closing conditions, and cabin quota adjustment conditions.

[0008] In conjunction with the first aspect mentioned above, in one possible implementation, the task encapsulation module is specifically used to: acquire external aviation business data and aviation business management rules; determine the target flight data to be processed from the external aviation business data based on flight screening conditions; associate the target flight data with the corresponding price adjustment rules or cabin control rules to generate a business judgment task.

[0009] In conjunction with the first aspect mentioned above, in one possible implementation, the message processing module is specifically used to: receive business determination tasks from the task encapsulation module; allocate a message topic to each business determination task to identify its business type; wherein the business type of the business determination task is determined based on the aviation business management rules adopted by the business determination task; convert the business determination task into an asynchronous message, and distribute the asynchronous message to the message queue according to the message topic.

[0010] In conjunction with the first aspect mentioned above, in one possible implementation, the distributed computing cluster is also used to: perform periodic health checks on the running status of each computing node; and when a failure is detected in the first computing node, reassign the tasks assigned to the first computing node to other healthy computing nodes.

[0011] In conjunction with the first aspect mentioned above, in one possible implementation, the business adjustment plan includes a fare adjustment plan or a cabin class adjustment plan, and the distributed computing cluster is also used to: push the fare adjustment plan to the airline's fare publication system; and push the cabin class adjustment plan to the airline's revenue management system.

[0012] Secondly, this application provides an airfare management method, which includes: acquiring external air business data and user-configured air business management rules; encapsulating the air business data and air business management rules into business judgment tasks; publishing the business judgment tasks to a message queue; the message queue is used to store the business judgment tasks and distribute the business judgment tasks to multiple computing nodes in a distributed computing cluster according to the business type of the business judgment tasks, so that each computing node executes the business judgment tasks to generate air business adjustment plans, and pushes the air business adjustment plans to the downstream air business execution system.

[0013] This application provides an airfare management method that acquires external dynamic aviation business data and user-defined business management rules, and encapsulates them into a unified business judgment task, laying a reliable data and rule foundation for generating accurate business adjustment plans. The business judgment task is then published to a message queue for storage and orderly distribution, decoupling task submission from execution. The message queue acts as a buffer layer, smoothing out sudden high-traffic loads and evenly distributing tasks across multiple computing nodes in a distributed computing cluster based on task type, improving the system's ability to handle high-concurrency tasks and its overall scalability. Subsequently, each computing node executes the business judgment task in parallel, rapidly generating aviation business adjustment plans using distributed computing resources. This shortens the processing latency from data and rule changes to plan output, improving the response speed and efficiency of fare management. Finally, the generated plan is automatically pushed to the downstream aviation business execution system, forming a closed-loop automated process from decision calculation to business execution, thereby improving the overall processing capacity, real-time performance, and operational reliability of the airfare management system.

[0014] Thirdly, this application provides an electronic device comprising: a processor and a memory; the memory storing processor-executable instructions; when the processor is configured to execute the instructions, causing the electronic device to implement the method of the second aspect described above.

[0015] Fourthly, this application provides a computer-readable storage medium comprising: computer software instructions; when the computer software instructions are executed in an electronic device, they cause the electronic device to implement the method described in the second aspect.

[0016] Fifthly, this application provides a computer program product that, when run on a computer, causes the computer to perform the functions of the related system described in the first aspect above, so as to implement the method of the second aspect above.

[0017] The descriptions of the third to fifth aspects in this application can be referenced to the detailed descriptions of the first and second aspects; and the beneficial effects of the descriptions of the third to fifth aspects can be referenced to the analysis of the beneficial effects of the first and second aspects, which will not be repeated here. Attached Figure Description

[0018] To more clearly illustrate the technical solutions of the embodiments of this application, the drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1This application provides a schematic diagram of the structure of an airfare management system. Figure 2 A flowchart illustrating a data acquisition method provided in an embodiment of this application; Figure 3 A flowchart illustrating a task distribution method provided in an embodiment of this application; Figure 4 A flowchart illustrating a cluster fault tolerance mechanism provided in an embodiment of this application; Figure 5 A flowchart illustrating an airfare management method provided in this application embodiment; Figure 6 A detailed flowchart illustrating an airfare management method provided in this application embodiment; Figure 7 This is a schematic diagram of the structure of an airfare management system provided in an embodiment of this application. Detailed Implementation

[0020] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0021] It should be noted that in the embodiments of this application, the words "exemplarily" or "for example" are used to indicate examples, illustrations, or explanations. Any embodiment or design scheme described as "exemplarily" or "for example" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design schemes. Specifically, the use of the words "exemplarily" or "for example" is intended to present the relevant concepts in a specific manner.

[0022] In the embodiments of this application, the terms "first," "second," "third," "fourth," "fifth," and "sixth" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Thus, a feature defined with "first," "second," "third," "fourth," "fifth," and "sixth" may explicitly or implicitly include one or more of that feature.

[0023] In embodiments of this application, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0024] "A and / or B" includes the following three combinations: A only, B only, and a combination of A and B.

[0025] This application provides an airfare management system. Through a data acquisition module, it acquires external aviation business data in real time. Combined with user-configured management rules received by a strategy specification module, this ensures the system can make fare decisions based on the latest market information and flexible, customizable business strategies, thereby improving the timeliness and adaptability of management. Furthermore, a task encapsulation module encapsulates data and rules into business judgment tasks, laying the foundation for automated and large-scale processing. A message processing module publishes tasks to a message queue and, relying on the message queue's mechanism of distributing tasks to a distributed computing cluster according to business type, achieves asynchronous decoupling and load balancing of tasks, effectively avoiding system blocking in high-concurrency scenarios and enhancing the system's scalability and stability. The distributed computing cluster, through multiple computing nodes, retrieves and executes tasks in parallel from the message queue, efficiently and concurrently completing a large number of business judgments and quickly generating aviation business adjustment plans. Finally, the system automatically pushes the adjustment plans to downstream execution systems, forming a closed-loop automated process from data input to plan output. This reduces manual intervention while improving the overall efficiency and response speed of fare management, thereby supporting airlines in achieving accurate and agile fare adjustments in a dynamic market environment.

[0026] The airfare management system provided in this application can be applied to the revenue management and dynamic pricing scenarios of airlines. This application does not impose any restrictions on the airline scale, business model, operational characteristics, or business complexity of the specific application scenarios.

[0027] For example, embodiments of this application can be applied to scenarios where large airlines manage their popular routes. Faced with frequent fare changes and cabin allocation adjustments by major competitors, the system can quickly generate and execute differentiated fare and cabin allocation adjustment plans by collecting market data from multiple platforms in real time and combining them with preset competitive response strategies, thereby maintaining a revenue advantage in price competition.

[0028] For example, the embodiments of this application can be applied to low-cost airlines managing their high-frequency flights. Their route fares are frequently adjusted and decision windows are short. The system utilizes the high throughput and low latency characteristics of message queues and distributed computing clusters to support the analysis of massive amounts of flight data and the execution of strategies, ensuring the timeliness of price adjustments and maximizing flight revenue.

[0029] For example, the embodiments of this application can be applied to scenarios where airlines cope with sudden traffic peaks such as holidays and large-scale events. During these periods, market supply and demand change drastically, and traditional systems are prone to slow response or downtime due to excessive load. This system, through its distributed architecture and high availability design, can flexibly cope with traffic peaks, ensuring uninterrupted fare management services and stable execution of revenue strategies.

[0030] The following detailed description of an airfare management system provided in this application, with reference to specific embodiments and accompanying drawings, is provided in conjunction with these embodiments.

[0031] Figure 1 This is a schematic diagram of the structure of an airfare management system provided in an embodiment of this application. Figure 1 As shown, the airfare management system 100 includes a data acquisition module 101, a strategy specification module 102, a task encapsulation module 103, a message processing module 104, and a distributed computing cluster 105. The task encapsulation module 103 is connected to both the data acquisition module 101 and the strategy specification module 102. The message processing module 104 is connected to the task encapsulation module 103, and the distributed computing cluster 105 is connected to the message processing module 104. The functions of each module are as follows: The data acquisition module 101 is used to acquire external aviation business data.

[0032] In this application embodiment, external aviation business data refers to various structured information related to air transport business operations and sales, which comes from the airline's external service platform or system. Its core function is to provide basic data support for the automated management of airfares and cabin space, and it is the core basis for subsequent formulation of management rules and generation of adjustment plans.

[0033] In some embodiments, external aviation business data includes airfare data and cabin availability data. Airfare data encompasses real-time fares, discount rates, surcharge rules, promotional prices, and effective periods published by various sales channels (such as online travel platforms, aviation information service systems, and airline partner agent platforms). Cabin availability data includes the number of remaining seats for each flight, cabin class configuration (such as economy, business, and first class), cabin availability status, overbooking thresholds, and seat lock-in information. Furthermore, external aviation business data also includes basic flight-related data, such as route information, departure and arrival times, flight numbers, aircraft parameters, and market competitor data, such as real-time fares, cabin availability, and passenger booking trends of other airlines on the same route.

[0034] In some embodiments, the airfare management system 100 can establish a communication connection with an external platform through a preset interface protocol to acquire external aviation business data in real time or at regular intervals throughout the airline's daily operations. For example, the data acquisition module 101 can acquire airfare data and competitor price comparison information from an online service platform through its open application programming interface (API). It can also acquire flight cabin inventory data and flight dynamic correlation data through the dedicated interface of an aviation information service platform (such as the TravelSky system), and supplement this with multi-dimensional external aviation business data by connecting with interfaces from other cooperative channels, ensuring the comprehensiveness of the data sources.

[0035] In some embodiments, after the data acquisition module 101 acquires external aviation business data, the data acquisition module 101 can also perform preliminary format verification and integrity checks on the acquired external aviation business data to determine whether the data conforms to preset data specifications (such as JSON format, CSV format syntax integrity), identify and remove invalid data with missing fields, data format errors, or logical contradictions (such as negative ticket prices, or the number of remaining seats exceeding the total number of seats of the aircraft type), and add metadata such as source channel identifiers and data acquisition timestamps to valid data to form a data acquisition log, providing support for subsequent data traceability, anomaly investigation, and source priority determination.

[0036] In one possible implementation, the data acquisition module 101 can be configured with an independent data acquisition service process. This process pre-stores the interface call parameters of each external platform (such as API keys, request addresses, and data request frequency thresholds). It then sequentially sends data acquisition requests to each external platform according to a preset acquisition cycle (e.g., initiating a real-time acquisition request every 30 seconds). After receiving the response data returned by the external platform, it automatically identifies the data format type using its built-in format parsing function, converting heterogeneous data such as JSON and CSV formats into a unified structured data format. The parsed valid data is then temporarily stored in a local cache queue. Once the amount of data in the cache queue reaches a preset threshold (e.g., 1000 records) or the current acquisition cycle ends, it is batch-synchronized to the distributed storage cluster, completing the data acquisition and initial storage.

[0037] For example, Figure 2 This is a flowchart illustrating a data acquisition method provided in an embodiment of this application. Figure 2 As shown, the data acquisition module 101 can obtain JSON format data information through the online service platform API and CSV format data information through the aviation information interface. Both types of information are transmitted to the data acquisition service, which then performs data cleaning, format conversion, and data verification operations on the received information. After completing the above operations, the data information is finally stored in the Elasticsearch cluster.

[0038] In this embodiment, by acquiring external aviation business data through the data acquisition module 101, airlines can break through the information barriers of a single data source and comprehensively and timely grasp data related to fares, cabin capacity, and market competitors from multiple channels. This provides complete and reliable basic data support for the subsequent strategy formulation module to receive user-configured management rules and the task encapsulation module to generate business judgment tasks. At the same time, by performing data format verification and invalid data removal in advance, redundant operations in subsequent data processing links are reduced, thereby improving the data processing efficiency and accuracy of the airfare management system 100.

[0039] The policy specification module 102 is used to receive user-configured aviation business management rules.

[0040] In this application embodiment, aviation business management rules refer to a set of structured rules formulated by users based on the competitive landscape of the aviation market, their own revenue goals and operational needs, to guide airfare adjustments, cabin control and related business decisions. They are the core basis for subsequent business judgment task generation and adjustment plan output, and directly determine the direction and effect of automated management.

[0041] In some embodiments, aviation business management rules may include: price adjustment rules, cabin control rules, flight screening conditions, and market analysis conditions. Price adjustment rules cover thresholds for competitor fare linkage on the same route (e.g., triggering price matching when a competitor's fare is 5% lower than the company's current fare), fare fluctuation ranges for different time periods (e.g., holidays, peak weekday hours), promotional fare activation conditions and recovery rules, and minimum revenue guarantee fare floor. Cabin control rules include opening or closing trigger conditions for each cabin class (e.g., closing the overbooking channel when the remaining seats are less than 10%), cabin quota adjustment ratios (e.g., increasing economy class quotas by 20% on peak routes), cabin reservation rules for special passengers (e.g., business travelers, group travelers), and overbooking ratio limits. Flight screening conditions involve screening dimensions such as target routes (e.g., popular business routes, tourist routes), flight times (e.g., morning peak 7-9 am, evening peak 18-20 pm), and aircraft type. Market analysis criteria include route popularity thresholds (e.g., a booking growth rate of over 30% in the past 7 days is considered a high-popularity route), passenger flow forecast indicators (e.g., predicting passenger flow growth trends for the next 15 days based on historical data), competitor market share thresholds, and other related rules.

[0042] In some embodiments, the strategy specification module 102 of the airfare management system 100 can obtain user-configured air business management rules through a preset visual front-end interactive interface, an open API interface, or by importing rule templates. For example, airline managers can log in to the web or client interface provided by the airfare management system 100 from their office terminals to manually input, select, or modify various rule parameters. For scenarios requiring batch configuration or rule updates, the strategy specification module 102 can receive rule configuration files exported by users from third-party systems via an API interface, or support users uploading rule templates in preset formats (such as Excel or JSON), automatically parsing and obtaining the air business management rules within them. Simultaneously, during the system's daily operation, the strategy specification module 102 can also receive the latest configuration information in real time when users adjust rules according to market dynamics.

[0043] In some embodiments, during the process of acquiring user-configured aviation business management rules, the policy specification module 102 can also perform legality verification and logical conflict detection on the user-configured aviation business management rules. Legality verification includes checking whether the rule parameters are within a reasonable range (e.g., the overbooking ratio must not exceed 5%, and the ticket price fluctuation range must not be lower than the cost price) and whether the parameter format conforms to preset specifications (e.g., date format, percentage value format). Logical conflict detection determines whether there are contradictions between different rules (e.g., simultaneously setting "the minimum ticket price must not be lower than 1000 yuan" and "the promotional ticket price is 800 yuan"). If an illegal or conflicting rule is detected, the policy specification module 102 will return a prompt message to the user in real time, explaining the problem type and modification suggestions. The acquisition and storage of the rule will be completed after the user corrects it.

[0044] In one possible implementation, the airfare management system 100 can provide a hierarchical, visual configuration interface. The interface is divided into four functional modules based on rule type: price adjustment, cabin control, flight filtering, and market analysis. Each module provides clearly defined parameter input boxes, drop-down selections, and range sliders, among other interactive components. Users can configure the rule parameters for each module sequentially according to their business needs. During configuration, the system displays a real-time preview of the rule's effect and its potential impact. After the user completes the configuration and submits it, the policy specification module 102 converts the rule parameters into structured data, associates it with metadata such as user identifier, configuration timestamp, and rule effective period (e.g., immediate effect, effective on a specified date), and stores it in the database. Simultaneously, it is synchronized to a distributed storage cluster for persistent backup, ensuring the security and traceability of the rule data. Furthermore, the airfare management system 100 also supports version management of configured rules, recording the content and author of each modification for easy rule rollback and recovery.

[0045] In this embodiment, the policy specification module 102 receives user-configured aviation business management rules, enabling airlines to flexibly define automated management logic based on their own operational goals and market changes. This avoids the limitations of traditional fixed rules that are difficult to adapt to dynamic markets. At the same time, through legality verification and logic conflict detection during the configuration process, the rationality and feasibility of the rules are ensured. This provides reliable rule support for the subsequent task encapsulation module 103 to generate accurate business judgment tasks and for the distributed computing cluster 105 to output effective adjustment schemes, thereby improving the targeting and flexibility of airfare and cabin management.

[0046] The task encapsulation module 103, connected to the data acquisition module 101 and the strategy specification module 102, is used to encapsulate the acquired external aviation business data and aviation business management rules into a business judgment task.

[0047] In this embodiment of the application, the business determination task refers to the structured task carrier that integrates preprocessed external aviation business data with legal and valid aviation business management rules, forming a clear execution objective, data support and rule basis. Its core function is to provide a unified format execution object for the distributed computing cluster 105, ensuring that the subsequent adjustment plan generation process has a clear data foundation and rule guidance.

[0048] In some embodiments, a business judgment task may include: a basic data section, a rule basis section, a task attribute section, and an execution requirement section. The basic data section covers cleaned and transformed airfare data, cabin class data, basic flight information (such as flight number, route, and takeoff and landing times), and market competitor data. The rule basis section contains a complete set of rules configured by the user, including price adjustment rules, cabin class control rules, flight filtering conditions, and market analysis conditions, and clearly indicates the rule version number and effective period. The task attribute section includes a unique task ID, business type tags (such as "fare adjustment" and "cabin class control"), task priority, task generation timestamp, and data source identifier. The execution requirement section specifies the task processing time limit, output result format (such as field specifications for the adjustment scheme), and exception handling mechanism (such as the number of retries after execution failure).

[0049] In some embodiments, the task encapsulation module 103 can establish connections with the distributed storage cluster of the data acquisition module 101 and the rule storage database of the policy specification module 102 through a preset data interface. When the airfare management system 100 triggers the task encapsulation process (such as when the timed encapsulation period arrives, the external data update volume reaches a threshold, or the user manually initiates an encapsulation command), it obtains the corresponding external air business data and air business management rules. For example, the task encapsulation module 103 retrieves external data that has been standardized by the data acquisition module 101 from the Elasticsearch distributed storage cluster, and retrieves valid management rules that have passed legality verification and logical conflict detection by the policy specification module 102 from the database or distributed storage cluster, ensuring that the obtained data and rules have integrity and availability.

[0050] In some embodiments, after acquiring external aviation business data and aviation business management rules but before task encapsulation, the task encapsulation module 103 can also perform a secondary verification of the correlation between the data and the rules, determining whether flight information, route information, etc., in the external data match the flight screening conditions and market analysis conditions in the rules, thus avoiding misalignment between data and rules for different target objects. Simultaneously, tasks are prioritized based on business urgency and impact scope. For example, fare adjustment tasks for popular routes during peak hours are given the highest priority, while cabin control tasks for less popular routes during off-peak hours are given a lower priority. Furthermore, intermediate logs of the task encapsulation process can be recorded, including data retrieval paths, rule version information, correlation verification results, and priority allocation criteria, providing support for subsequent task tracing and problem investigation.

[0051] In one possible implementation, the task encapsulation module 103 incorporates a data association algorithm and a structured encapsulation template. For example, the task encapsulation module 103 first pulls external aviation business data processed by the data acquisition module 101 from the Elasticsearch distributed storage cluster via an interface, and reads the valid aviation business management rules collected and stored in the database by the strategy specification module 102. Then, it initiates the data association algorithm, filtering the dataset corresponding to the target flight from the external data based on flight filtering conditions (such as route and flight time slot) in the rules, and binds the target dataset with the corresponding price adjustment rules, cabin control rules, and market analysis conditions. Next, it calls the structured encapsulation template to organize the bound data and rules into JSON-formatted task data according to a preset field order (task ID, business type, basic data, rule basis, priority, execution requirements), and automatically generates a unique task ID (composed of a date stamp, a random string, and a business type code) and a business type label. Finally, it stores the encapsulated business judgment task in a local buffer pool.

[0052] In this embodiment, the task encapsulation module 103 encapsulates external aviation business data and aviation business management rules into a business judgment task, realizing the organic integration of data and rules. This provides the distributed computing cluster 105 with a uniformly formatted and logically coherent execution object, avoiding execution deviations caused by the separation of data and rules during subsequent execution.

[0053] The message processing module 104 is connected to the task encapsulation module 103 and is used to publish business judgment tasks to the message queue.

[0054] The message queue is used to store business judgment tasks and distribute them to multiple computing nodes in the distributed computing cluster according to the business type of the business judgment task.

[0055] In this embodiment, the message queue refers to a highly reliable task storage and distribution middleware built on a distributed architecture. Its core function is to decouple the task encapsulation module from the distributed computing cluster. By storing tasks in an orderly manner and routing them according to rules, it avoids system blocking caused by direct interaction between upstream and downstream modules, while ensuring that tasks are not lost or duplicated in high-concurrency scenarios. The business type refers to the classification identifier of the functional attributes of the task determined by the business, used to clarify the execution goal of the task, and is the core basis for the message queue to achieve accurate distribution.

[0056] In some embodiments, the business types may include: fare adjustment and cabin control. The fare adjustment business type corresponds to tasks with the core objective of optimizing airfares, encompassing tasks such as competitor pricing on the same route, time-based fare fluctuations, promotional fare allocation, and setting minimum revenue guarantee fares. The cabin control business type corresponds to tasks with the core objective of rationally allocating cabin resources, including tasks such as opening / closing cabin classes, adjusting cabin quota ratios, controlling overbooking ratios, and reserving cabins for special passengers (business travelers, group travelers).

[0057] In one possible implementation, the business type could also include comprehensive adjustment. Comprehensive adjustment business types correspond to complex tasks that require simultaneous linkage of fare and cabin allocation optimization. For example, tasks that link fare increases and cabin allocation adjustments during peak hours on popular routes, or tasks that coordinate fare reductions and overbooking limits on off-season routes.

[0058] In some embodiments, the message processing module 104 can establish a long connection with the local buffer pool of the task encapsulation module 103 through a preset internal communication interface. When the number of business judgment tasks in the buffer pool reaches a preset threshold (e.g., 500) or the time since the last task retrieval exceeds 30 seconds, the message processing module 104 retrieves the business judgment tasks that have been structurally encapsulated by the task encapsulation module 103. For example, the message processing module 104 sends a task retrieval request to the task encapsulation module 103, carrying the buffer pool identifier and task format verification standard. After responding to the request, the task encapsulation module 103 returns business judgment tasks that conform to the standard in batches, ensuring that the retrieved tasks have complete field information and a unified structured format.

[0059] In some embodiments, after acquiring the business judgment task and before publishing it to the message queue, the message processing module 104 can also verify the business type identifier of the task to confirm whether the identifier matches one of the three preset business types, thus avoiding misallocation due to incorrect identifiers. Simultaneously, based on the priority field in the task, a corresponding quality of service (QoS) level is set for the message. High-priority tasks (such as peak-hour popular route adjustment tasks) are set to QoS level 1 to ensure that the message is consumed at least once and is not duplicated, while ordinary-priority tasks are set to QoS level 2 to ensure efficient transmission. Furthermore, the task data can be compressed using the GZIP compression algorithm to reduce the task data size, thereby reducing the storage pressure on the message queue and network transmission overhead. Metadata such as the task size and compression ratio before and after compression are also recorded to facilitate subsequent data integrity verification.

[0060] In one possible implementation, the message processing module 104 can use RocketMQ as the core message queue middleware. It pre-creates dedicated tags corresponding to the two business types in the RocketMQ cluster: "fare adjustment tag" and "cabin control tag." Each tag is configured with a queue matching the number of nodes in the distributed computing cluster (e.g., 8 nodes) to support parallel distribution. The message processing module 104 establishes a connection with the message queue through a RocketMQ producer. The client pre-configures message persistence parameters, sending timeout (e.g., 5 seconds), and retry mechanism (maximum 3 retries). After obtaining the business judgment task, it parses the business type tag in the task, delivering fare adjustment tasks to the "fare adjustment tag" and cabin control tasks to the "cabin control tag."

[0061] For example, Figure 3 This is a flowchart illustrating a task distribution method provided in an embodiment of this application. Figure 3 As shown, after obtaining the business judgment task, the message processing module 104 passes the task to the RocketMQ producer. The RocketMQ producer performs message production operations based on the business judgment task, generating the corresponding production message. The generated production message is then sent to the RocketMQ cluster. Finally, the RocketMQ cluster distributes the production message to the processing link corresponding to fare adjustment and the processing link corresponding to cabin class adjustment, respectively, according to the type of the business judgment task, achieving targeted distribution of tasks of different business types.

[0062] In this embodiment, the message processing module 104 publishes the business judgment task to the message queue and distributes it according to the business type, which effectively decouples the task encapsulation and task execution stages, avoids the task accumulation caused by the processing delay of the computing node from affecting the upstream encapsulation process, and improves the task processing efficiency and resource utilization of the computing cluster.

[0063] The distributed computing cluster 105 is connected to the message processing module 104. It is used to obtain business judgment tasks in parallel from the message queue through multiple computing nodes, execute the business judgment tasks to generate aviation business adjustment plans, and push the aviation business adjustment plans to the downstream aviation business execution system.

[0064] In this embodiment, the distributed computing cluster refers to a distributed processing architecture composed of multiple independent computing nodes. Its core function is to efficiently handle business judgment tasks distributed by message queues through parallel collaboration between nodes, perform business analysis and decision-making based on preset algorithm logic, and generate accurate aviation business adjustment plans. The aviation business adjustment plan refers to a set of specific execution instructions that can be directly used to guide aviation business operations, formed after analysis and computation by computing nodes based on data support and rule basis from the business judgment task. The aviation business execution system refers to the downstream business system that receives and implements the aviation business adjustment plan, and is a key carrier connecting technical decisions and actual operations.

[0065] In some embodiments, the air traffic control adjustment plan may include: a fare adjustment plan and a cabin control plan. The fare adjustment plan includes the specific fare adjustment range for the target flight (e.g., an 8% increase or a 12% decrease), the effective period after the adjustment, the applicable sales channels (e.g., applicable to all channels or exclusive to the official website), the minimum revenue guarantee threshold, and an explanation of the adjustment basis (e.g., based on the average price of three competing airlines on the same route being 6% lower than the company's current fare). The cabin control plan includes the opening / closing status instructions for each cabin class (e.g., economy class Y remains open, business class C is closed), cabin quota adjustment values ​​(e.g., economy class quota increases by 30 seats, overbooking ratio adjusted to 2%), the number of special passenger cabins reserved, and the effective conditions (e.g., reserving 5 adjacent seats when a group of 10 or more passengers).

[0066] In one possible implementation, the aviation business adjustment plan may also include a comprehensive adjustment plan, namely a combined instruction that links fares and cabin capacity. For example, the fares for the popular "Beijing-Shanghai" route during the morning peak season may be increased by 10% and the economy class quota may be increased by 15%, while the fares for the off-season "Guangzhou-Kunming" route may be reduced by 15% and the overbooking limit may be relaxed to 4%.

[0067] In some embodiments, the airfare management system 100 can establish a long-lived connection with the RocketMQ cluster corresponding to the message processing module 104 through message queue consumer clients (such as RocketMQ consumer clients) deployed on each computing node of the distributed computing cluster 105. When there are pending business judgment tasks in the message queue, the system can obtain these tasks in real time or in batches by subscribing to the corresponding tags. For example, each computing node is pre-bound to a tag subscription relationship for a specific business type. For instance, some nodes focus on subscribing to the "fare adjustment tag," while others focus on subscribing to the "cabin class control tag." Simultaneously, the distributed computing cluster 105 also supports dynamic adjustment of subscription permissions between nodes. When the volume of a certain type of task suddenly increases, other nodes can be temporarily allocated to participate in the task acquisition for that tag, ensuring the flexibility and efficiency of task acquisition.

[0068] In some embodiments, after the computing node obtains the business judgment task but before executing it, the distributed computing cluster 105 can also perform a final verification of the task's completeness and validity. This involves checking whether fields such as basic data, rule basis, and execution requirements in the task are missing or abnormal. If a problem is found, the task is marked as invalid and returned to the dead-letter queue of the message queue, while an exception log is recorded for easy troubleshooting. After generating the aviation business adjustment plan but before pushing it to downstream systems, the distributed computing cluster 105 can also perform a compliance verification of the plan. This involves determining whether the plan complies with relevant fare control regulations and airline internal operating standards (such as ticket prices not being lower than cost prices and overbooking not exceeding 5%). Only after passing the verification can the push operation be executed; otherwise, the process is returned to the computing node for recalculation.

[0069] In one possible implementation, the distributed computing cluster 105 can be configured with 16 independent servers. Each server acts as a computing node, deploying a task processing engine, an algorithm library (including a revenue maximization model, a competitor analysis model, and a passenger flow prediction model), and a message queue consumer client. Each computing node subscribes to the corresponding tag in the RocketMQ cluster through the consumer client, adopting a pull-based consumption model. It retrieves business judgment tasks from the message queue at a preset frequency (e.g., every 100 milliseconds) and temporarily stores the task data locally. Subsequently, the task processing engine calls the corresponding algorithm library. For example, when processing fare adjustment tasks, it calls the competitor analysis model, combining competitor fare data, its own cost data, and price adjustment rules in the task to calculate the specific fare adjustment range. When processing cabin control tasks, it calls the passenger flow prediction model, generating cabin quota adjustment instructions based on historical booking data, remaining seat data, and cabin control rules. After generating the adjustment plan, it pushes the plan to the corresponding downstream aviation business execution system via network protocol. The fare adjustment plan is pushed to the airline's fare release system, and the cabin control plan is pushed to the revenue management system.

[0070] In this embodiment, multiple computing nodes of the distributed computing cluster 105 acquire and execute business judgment tasks in parallel, improving task processing efficiency in high-concurrency scenarios and avoiding processing bottlenecks in traditional monolithic architectures. Targeted push to downstream business systems enables seamless integration from technical decisions to business implementation, allowing fare and cabin class adjustments to quickly respond to market changes, providing core technical support for airlines to improve revenue management efficiency and optimize resource allocation.

[0071] In this embodiment, the distributed computing cluster 105 can also be used to perform periodic health checks on the operating status of each computing node. And when a failure is detected in the first computing node, the tasks assigned to the first computing node are reassigned to other healthy computing nodes.

[0072] In this embodiment, periodic health checks refer to an automated mechanism in the distributed computing cluster 105 where a pre-defined scheduling and management node continuously monitors, collects data, and assesses the operational status of all computing nodes within the cluster at fixed time intervals or dynamically adjusted detection cycles. The core purpose is to monitor node availability in real time and promptly identify potential faults. The first computing node refers to any computing node determined to have operational anomalies or functional failures during the health check process; its failure status triggers the cluster's automatic fault-tolerance process. Task reallocation refers to the operation where, after the first computing node fails, the scheduling and management node transfers any unfinished business judgment tasks or ongoing interrupted tasks from that node to other normally operating computing nodes within the cluster for continued processing, ensuring uninterrupted task execution.

[0073] In some embodiments, the operational status may include: the hardware resource utilization status of the computing node, the software service operational status, the network connectivity status, and the task processing status. The hardware resource utilization status encompasses core hardware metrics such as CPU utilization, memory utilization, remaining disk storage space, disk I / O read / write speed, and server temperature. The software service operational status includes the process liveness, service response time, and error log generation frequency of key services such as the task processing engine, message queue consumer client, and algorithm library. The network connectivity status involves the stability of network connections between the computing node and the message queue cluster, downstream aviation business execution system, and scheduling management node, as well as data transmission latency and packet loss rate. The task processing status includes information such as the number of tasks currently being executed by the node, task processing progress, success rate of completed tasks, and queue length of incomplete tasks.

[0074] In some embodiments, a scheduling management node is deployed within the distributed computing cluster 105. This node establishes communication connections with each computing node using a heartbeat detection protocol and acquires the operational status data of each computing node within a preset detection period (e.g., every 5 seconds). For example, each computing node has a built-in monitoring agent that collects its own hardware resources, software services, network connectivity, and task processing-related data in real time, encapsulates this data into a heartbeat packet in a unified format, and actively reports it to the scheduling management node when the detection period is triggered. Simultaneously, the scheduling management node can proactively send probe requests to each computing node to query its status and receive the response data returned by the nodes. By combining the data from proactive probes and passive reporting, the node ensures that the acquired operational status data is comprehensive and accurate.

[0075] In one possible implementation, the airfare management system 100 can set up a dedicated server as a scheduling management node in the distributed computing cluster 105. This node is pre-configured with a health check rule base (including normal threshold ranges for various operational status indicators) and a task allocation algorithm (such as a weighted round-robin algorithm). The scheduling management node establishes communication with the monitoring agent program of each computing node through a TCP long connection, receives heartbeat packet data reported by each node every 5 seconds, and sends an active probe request to each node every 10 seconds for bidirectional verification. The scheduling management node analyzes the collected status data. If a computing node reports a CPU utilization rate exceeding 95% for three consecutive times, fails to respond to an active probe request for two consecutive times, or has a task processing success rate below 80%, then the node is determined to be the first computing node (faulty node), its status is immediately marked as faulty, and the distribution of new tasks to it is suspended. Subsequently, the scheduling management node queries the task execution records of the failed node to obtain a list of incomplete tasks and their processing progress data. Based on a weighted round-robin algorithm, it evenly distributes the incomplete tasks to healthy nodes according to their current load (lower load, higher weight). Upon receiving the assigned tasks, healthy nodes read the task processing progress data and resume execution from where it left off until an aviation business adjustment plan is generated and pushed to the downstream system. Simultaneously, the scheduling management node continuously monitors the status of the failed node. When the failed node is repaired, reconnects to the cluster, and passes the health check, its status is automatically updated to normal, and new tasks are gradually assigned to it, restoring the cluster's full processing capacity.

[0076] For example, Figure 4 This is a flowchart illustrating a cluster fault tolerance mechanism provided in an embodiment of this application. Figure 4 As shown, after receiving external business requests, the distributed computing cluster 105 uses a round-robin strategy to evenly distribute requests in a round-robin manner to avoid overloading a single node. It then enters a health check phase, pre-checking the operating status of each node in the cluster (such as hardware resource usage and service process status) and distributing requests to nodes in normal status. After the requests are distributed to the server cluster for task execution, the distributed computing cluster 105 performs heartbeat checks to periodically probe the status of each node. If a node failure is detected (such as no response or excessive resource usage), automatic repair is triggered. If immediate recovery is not possible, a failover operation is initiated, reassigning the unfinished tasks of the failed node to other healthy nodes in the cluster to ensure continuous task execution. Furthermore, these cluster statuses and fault handling information are synchronized to the monitoring component and the warning rule component. The monitoring component pushes the operating status and fault information to a visualization tool, presenting it to administrators in an intuitive way. The warning rule component analyzes the cluster's operating logs, matches preset alarm conditions (such as more than two failed nodes or task failover), and triggers corresponding alarm information to assist administrators in quickly handling problems.

[0077] In this embodiment, periodic health checks are performed by the distributed computing cluster 105 to monitor the operating status of each computing node in real time, promptly detect node failures, and trigger automatic fault tolerance processes, preventing long-term operation of faulty nodes from affecting the overall stability of the cluster. The task reallocation mechanism ensures that business decision-making tasks on faulty nodes are not lost or interrupted, guaranteeing the efficiency of generating aviation business adjustment plans and avoiding market response delays caused by node failures.

[0078] The airfare management system provided in this application acquires external aviation business data in real time through a data acquisition module and combines it with user configuration management rules received by a strategy specification module. This ensures that the system can make fare decisions based on the latest market information and flexible, customizable business strategies, thereby improving the timeliness and adaptability of management. Furthermore, the task encapsulation module encapsulates data and rules into business judgment tasks, laying the foundation for automated and large-scale processing. The message processing module publishes tasks to a message queue and, relying on the message queue's mechanism of distributing tasks to a distributed computing cluster according to business type, achieves asynchronous decoupling and load balancing of tasks, effectively avoiding system blocking in high-concurrency scenarios and enhancing the system's scalability and stability. The distributed computing cluster, through multiple computing nodes, retrieves and executes tasks in parallel from the message queue, enabling efficient and concurrent completion of a large number of business judgments and rapid generation of aviation business adjustment plans. Finally, the system automatically pushes the adjustment plan to the downstream execution system, forming a closed-loop automated process from data input to plan output. This reduces manual intervention while improving the overall efficiency and response speed of fare management, thereby supporting airlines to achieve accurate and agile fare adjustments in a dynamic market environment.

[0079] In an exemplary embodiment, Figure 5 This is a flowchart illustrating an airfare management method provided in an embodiment of this application. For example, as shown... Figure 5 As shown, it includes the following: S501, Obtain external aviation business data and user-configured aviation business management rules.

[0080] S502, Encapsulate aviation business data and aviation business management rules into business judgment tasks.

[0081] S503. Publish the business judgment task to the message queue.

[0082] The message queue is used to store business judgment tasks and distribute them to multiple computing nodes in the distributed computing cluster according to the business type of the business judgment tasks. This enables each computing node to execute the business judgment tasks to generate aviation business adjustment plans and push the aviation business adjustment plans to the downstream aviation business execution system.

[0083] The description of the above method corresponds to the functional description of each module in the airfare management system 100 provided in the embodiments of this application.

[0084] In the embodiments of this application, Figure 6 This is a detailed flowchart illustrating an airfare management method provided in an embodiment of this application. For example, as shown... Figure 6 As shown, the method is based on multi-source data and guided by user policies. It uses message queues to distribute tasks and execute them in a cluster, ultimately implementing the business solution. The specific process is as follows: First, two types of core data are acquired: one is ticket sales and competitor fares information provided by the online service platform; the other is flight cabin inventory and basic flight information provided by the travel information channel. Next, combined with the user's pre-configured user policies, i.e., aviation business management rules (such as price adjustment thresholds and cabin control conditions), the above two types of data are correlated and matched with the user policies to generate a business judgment task containing data support and rule basis. Then, this business judgment task is encapsulated as an asynchronous message and published to a message queue. Afterwards, for the generated business judgment task, the corresponding RocketMQ asynchronous message production operation is completed. Subsequently, the server cluster subscribes to the corresponding asynchronous messages and then obtains the business judgment task through RocketMQ consumption. Finally, the obtained business judgment task is executed. After the task is completed, the results are pushed separately: the generated fare adjustment plan is pushed to the fare system to automate the update of the target flight's ticket price; the generated cabin adjustment plan is pushed to the revenue system to achieve dynamic allocation of cabin resources. This forms a complete aviation fare and cabin management process from data acquisition and policy integration to task execution and plan implementation.

[0085] In an exemplary embodiment, this application also provides an electronic device, which may be the airfare management system described in the above method embodiments. Figure 7 This is a schematic diagram of the structure of an airfare management system provided in an embodiment of this application. Figure 7 As shown, the airfare management device may include a processor 701 and a memory 702; the memory 702 stores instructions executable by the processor 701; when the processor 701 is configured to execute instructions, it causes an electronic device or network device or manager to perform the system functions described in the foregoing method embodiments.

[0086] Through the above description of the embodiments, those skilled in the art can clearly understand that, for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.

[0087] In the embodiments provided in this application, it should be understood that the disclosed systems and methods can be implemented in other ways. For example, the system embodiments described above are merely illustrative. For instance, the division of modules or units is only 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 device, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be an indirect coupling or communication connection between devices or units through some interfaces, and may be electrical, mechanical, or other forms.

[0088] The units described as separate components may or may not be physically separate. A component shown as a unit can be one or more physical units; that is, it can be located in one place or distributed in multiple different locations. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0089] Furthermore, the functional units in the various embodiments of this application 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.

[0090] 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 readable storage medium. Based on this understanding, the technical solutions of the embodiments of this application, essentially, or the parts that contribute to the prior art, or all or part of the technical solutions, can be embodied in the form of a software product. This software product is stored in a storage medium and includes several instructions to cause a device (which may be a microcontroller, chip, etc.) or processor to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, ROM, RAM, magnetic disks, or optical disks.

[0091] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any changes or substitutions within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. An airfare management system, characterized in that, The system includes: The data acquisition module is used to acquire external aviation business data; The policy specification module is used to receive user-configured aviation business management rules; The task encapsulation module, which connects the data acquisition module and the strategy specification module, is used to encapsulate the acquired external aviation business data and the aviation business management rules into a business judgment task. The message processing module, connected to the task encapsulation module, is used to publish the business judgment task to the message queue; the message queue is used to store the business judgment task and distribute the business judgment task to multiple computing nodes of the distributed computing cluster according to the business type of the business judgment task. A distributed computing cluster, connected to the message processing module, is used to retrieve the business judgment task in parallel from the message queue through multiple computing nodes, execute the business judgment task to generate an aviation business adjustment plan, and push the aviation business adjustment plan to the downstream aviation business execution system.

2. The system according to claim 1, characterized in that, The external aviation business data includes airfare data and airline cabin space data; The data acquisition module is specifically used for: Airfare data is obtained from a first type of external platform; the first type of external platform includes online platforms that provide ticketing sales information. Airline cabin availability data is obtained from a second type of external platform; the second type of external platform includes aviation information service platforms that provide flight schedule and seat inventory management.

3. The system according to claim 1, characterized in that, The aviation business management rules include at least one of the following configured by the user for the target flight: price adjustment rules, cabin control rules, and flight screening conditions; The cabin control rules include cabin opening conditions, cabin closing conditions, and cabin quota adjustment conditions.

4. The system according to claim 3, characterized in that, The task encapsulation module is specifically used for: Obtain the external aviation business data and the aviation business management rules; Based on the flight screening criteria, target flight data to be processed is determined from the external aviation business data; The target flight data is associated with the corresponding price adjustment rule or cabin control rule to generate a business judgment task.

5. The system according to claim 1, characterized in that, The message processing module is specifically used for: Receive a service determination task from the task encapsulation module; Each business determination task is assigned a message topic to identify its business type; wherein, the business type of the business determination task is determined based on the aviation business management rules adopted by the business determination task. The business decision task is converted into an asynchronous message, and the asynchronous message is distributed to a message queue according to the message topic.

6. The system according to claim 1, characterized in that, The distributed computing cluster is also used for: Perform periodic health checks on the operating status of each computing node; When a failure is detected in the first compute node, the tasks assigned to the first compute node are reassigned to other healthy compute nodes.

7. The system according to claim 1, characterized in that, The business adjustment plan includes a fare adjustment plan or a cabin space adjustment plan, and the distributed computing cluster is also used for: The proposed fare adjustment plan will be pushed to the airline's fare publication system; The cabin adjustment plan will be pushed to the airline's revenue management system.

8. A method for managing airfares, characterized in that, The method includes: Acquire external aviation business data and user-configured aviation business management rules; The aviation business data and the aviation business management rules are encapsulated into a business judgment task; The business determination task is published to a message queue; the message queue is used to store the business determination task and distribute the business determination task to multiple computing nodes of the distributed computing cluster according to the business type of the business determination task, so that each computing node executes the business determination task to generate an aviation business adjustment plan and pushes the aviation business adjustment plan to the downstream aviation business execution system.

9. An electronic device, characterized in that, The electronic device includes: a processor and a memory; The memory stores instructions that the processor can execute; When the processor is configured to execute the instructions, the electronic device performs the method as described in claim 8.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes: computer software instructions; When the computer software instructions are executed in an electronic device, the electronic device causes the electronic device to perform the method as described in claim 8.

Images