WO2021129991A1 - Système et procédé d'optimisation de la transmission de demandes de contenu mis à jour à partir de sources de données externes - Google Patents

Système et procédé d'optimisation de la transmission de demandes de contenu mis à jour à partir de sources de données externes Download PDF

Info

Publication number
WO2021129991A1
WO2021129991A1 PCT/EP2020/083207 EP2020083207W WO2021129991A1 WO 2021129991 A1 WO2021129991 A1 WO 2021129991A1 EP 2020083207 W EP2020083207 W EP 2020083207W WO 2021129991 A1 WO2021129991 A1 WO 2021129991A1
Authority
WO
WIPO (PCT)
Prior art keywords
updated content
content
request
instruction
intermediation server
Prior art date
Application number
PCT/EP2020/083207
Other languages
English (en)
Inventor
Olivier Amadieu
Jean-Chafic Hays
Fadi AKRIMI
Aurelie Camberbec
Original Assignee
Amadeus S.A.S.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from FR1915430A external-priority patent/FR3105523B1/fr
Priority claimed from US16/724,542 external-priority patent/US11461308B2/en
Application filed by Amadeus S.A.S. filed Critical Amadeus S.A.S.
Priority to EP20808167.9A priority Critical patent/EP4081912A1/fr
Priority to CN202080089661.XA priority patent/CN114846460A/zh
Publication of WO2021129991A1 publication Critical patent/WO2021129991A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/25—Integrating or interfacing systems involving database management systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/95—Retrieval from the web
    • G06F16/957—Browsing optimisation, e.g. caching or content distillation
    • G06F16/9574—Browsing optimisation, e.g. caching or content distillation of access to content, e.g. by caching

Definitions

  • the specification relates generally to computing systems, and specifically to a system and method for optimizing transmission of requests for updated content from external data sources.
  • Some computing systems generate data for provision to client subsystems according to complex and highly variable mechanisms. Examples are systems that generate data representing items such as travel products and services, each of which may have numerous attributes that can be selected dynamically at the time of generation according to a wide variety of conditions. Attributes of the above data, such as price and seat availability for a flight, may vary over relatively short periods of time (e.g. one day).
  • An aspect of the specification provides a method of optimizing transmission of requests for updated content from external data sources, comprising: storing, at an intermediation server, a data object containing initial content received from at least one of the external data sources and associated with an expiry time; storing, at the intermediation server, a set of optimization parameters; obtaining an instruction at the intermediation server to request updated content corresponding to the data object; in response to obtaining the instruction, determining, based on the optimization parameters and the expiry time, whether to request updated content from the external data sources; when the determination is affirmative, transmitting at least one update request to at least one of the external data sources based on the initial content and the optimization parameters; and in response to transmitting the at least one update request, receiving and storing respective sets of updated content from the external data sources.
  • the method can further comprise: in response to receiving and storing the sets of updated content, evaluating each set of updated content against the initial content; and determining, based on the evaluations, whether to replace the initial content with a selected set of the updated content.
  • Determining whether to replace the initial content with the selected set of the updated content can include sending a prompt containing at least one of the sets of updated content to a client subsystem for selection.
  • Determining whether to replace the initial content with the selected set of the updated content can include automatically replacing the initial content with the selected set of the updated content.
  • Obtaining the instruction can include receiving the instruction at the intermediation server from a client subsystem.
  • the method can further comprise storing, at the intermediation server, update scheduling configuration data; wherein obtaining the instruction includes generating the instruction at the intermediation server according to the scheduling configuration data.
  • the optimization parameters can include at least one of (i) an update request frequency threshold, and (ii) a time threshold; and determining whether to request updated content can include at least one of (i) determining whether the update request frequency threshold has been exceeded, and (ii) determining whether a difference between a current time and the expiry time is below the time threshold.
  • the optimization parameters can include historical trend data corresponding to the initial content; and determining whether to request updated content can include: identifying current trend data corresponding to the initial content; comparing the current trend data to the historical trend data; and when the current trend data and the historical trend data match, making the determination of whether to request updated content based on the historical trend data.
  • an intermediation server for optimizing transmission of requests for updated content from external data sources
  • the intermediation server comprising: a memory storing (i) a data object containing initial content received from at least one of the external data sources and associated with an expiry time, and (ii) a set of optimization parameters; a communications interface; and a processor connected with the communications interface and the memory, the processor configured to: obtain an instruction at the intermediation server to request updated content corresponding to the data object; in response to obtaining the instruction, determine, based on the optimization parameters and the expiry time, whether to request updated content from the external data sources; when the determination is affirmative, transmit at least one update request to at least one of the external data sources based on the initial content and the optimization parameters; and in response to transmitting the at least one update request, receive and store respective sets of updated content from the external data sources.
  • the processor can be further configured to: in response to receipt and storage of the sets of updated content, evaluate each set of updated content against the initial content; and determine, based on the evaluations, whether to replace the initial content with a selected set of the updated content.
  • the processor can be configured, in order to determine whether to replace the initial content with the selected set of the updated content, to send a prompt containing at least one of the sets of updated content to a client subsystem for selection.
  • the processor can be configured, in order to determine whether to replace the initial content with the selected set of the updated content, to automatically replace the initial content with the selected set of the updated content.
  • the processor can be configured, in order to obtain the instruction, to receive the instruction at the intermediation server from a client subsystem.
  • the processor can be configured, in order to obtain the instruction, to generate the instruction according to scheduling configuration data stored in the memory.
  • the optimization parameters can include at least one of (i) an update request frequency threshold, and (ii) a time threshold; and the processor can be configured, in order to determine whether to request updated content, to at least one of (i) determine whether the update request frequency threshold has been exceeded, and (ii) determine whether a difference between a current time and the expiry time is below the time threshold.
  • the optimization parameters include historical trend data corresponding to the initial content; and the processor can be configured, in order to determine whether to request updated content, to: identify current trend data corresponding to the initial content; compare the current trend data to the historical trend data; and when the current trend data and the historical trend data match, make the determination of whether to request updated content based on the historical trend data.
  • a further aspect of the specification provides a computer program product comprising program code instructions stored on a computer readable medium comprising: computer readable program means for storing (i) a data object containing initial content received from at least one of the external data sources and associated with an expiry time, and (ii) a set of optimization parameters; computer readable program means for obtaining an instruction at the intermediation server to request updated content corresponding to the data object; computer readable program means for, in response to obtaining the instruction, determining, based on the optimization parameters and the expiry time, whether to request updated content from the external data sources; computer readable program means for, when the determination is affirmative, transmitting at least one update request to at least one of the external data sources based on the initial content and the optimization parameters; and computer readable program means for, in response to transmitting the at least one update request, receiving and storing respective sets of updated content from the external data sources, when said program runs on an intermediation server.
  • FIG. 1 is a diagram illustrating a system for optimizing transmission of requests for updated content from external data sources
  • FIG. 2 is a diagram illustrating certain internal components of the intermediation server of FIG. 1 ;
  • FIG. 3 is a flowchart of a method for optimizing transmission of requests for updated content from external data sources
  • FIG. 4 is a diagram illustrating an example performance of block 305 of the method of FIG. 3;
  • FIG. 5 is a flowchart of a method for performing block 315 of the method of FIG. 3;
  • FIG. 6 is a flowchart of another method for performing block 315 of the method of FIG. 3.
  • FIG. 7 is a diagram illustrating trend data employed in the performance of the method of FIG. 6.
  • FIG. 1 illustrates a system 100 for optimizing the transmission of requests for updated content from external data sources.
  • various computing subsystems interact to generate and process data relating to any of a wide variety of activities.
  • the subsystems of the system 100 interact to generate and process data relating to the delivery of items to customers.
  • the items, in the examples, below, are travel-related products and services, such as flight tickets, hotel reservations, vehicle rental reservations, and the like.
  • a wide variety of other activities can be enabled by the exchange of data between the subsystems shown in FIG. 1 , and the specific nature of the data processed within the system 100 is not particularly limited. More generally, the generation of data processed in the system 100 imposes non-trivial computational load on the component(s) that generate the data. The data is not merely retrieved from repositories for transmission in response to requests, but is instead dynamically generated in response to each request from a variety of input data, generation rules, and the like. Further, the volume of requests and associated data in the system 100 can be significant (e.g. on the order of millions of requests per day). As will be seen below, at least some components of the system 100 are configured to optimize the transmission of requests for data to reduce the above-mentioned demands on the system 100 under certain conditions.
  • the system 100 includes at least one client subsystem 104, of which two examples 104-1 and 104-2 are shown in FIG. 1 (referred to collectively as the client subsystems 104 and generically as a client subsystem 104).
  • Each client subsystem 104 is operated by a client entity that may also be referred to as a seller.
  • the seller can be, for example, a travel agency.
  • the client subsystems 104 generate requests, e.g. on behalf of customers, for travel items.
  • the requests specify various attributes of the travel items, such as origin and destination locations, times and dates of travel, and the like.
  • Responses to requests from the client subsystems 104 are generated by, or on behalf of, entities that provide the items, referred to herein as providers.
  • the providers are entities such as airlines, hotel operators or the like that deliver the items to the customer, or to other such entities for eventual delivery to the customer, following purchase of the items (such purchase being effected, for example, via a client subsystem 104).
  • Providers may also be referred to interchangeably as suppliers, reflecting the fact that in some instances an item such as a flight may be booked through a first airline (e.g. the supplier) and operated by another airline (e.g. the provider).
  • Each provider entity operates a provider subsystem 108 (which may also be referred to as a supplier subsystem), of which two example provider subsystems 108-1 and 108-2 are shown in FIG. 1.
  • Each of the client subsystems 104 and the provider subsystems 108 are implemented as at least one computing device with input and output assemblies and communications devices for exchanging data via a network 112.
  • the network 112 can include any suitable combination of local-area and wide-area networks, including the Internet.
  • the system 100 can include a greater or smaller number of client subsystems 104 and provider subsystems 108 in other examples.
  • each provider subsystem 108 includes an offer generation module (e.g. computer readable instructions and corresponding execution hardware, along with various stored data for use in generating responses) that enables the provider subsystems 108 to generate response data based on the attributes specified in the request originated by a client subsystem 104.
  • the response data may also be referred to as “offer data”, and defines one or more items that match or partially match the requested attributes.
  • a distribution channel encompasses a set of entities within the system 100, as well as message syntax, message sequencing and the like.
  • the provider subsystems 108 implement the New Distribution Capability (NDC) distribution channel.
  • NDC New Distribution Capability
  • the NDC standard defines an extensible Markup Language (XML) based data format, as well as message syntax,
  • Requests for content conveyed to the provider subsystems 108 can therefore include AirShopping messages, OfferPrice messages and the like, according to the NDC standard.
  • AirShopping messages can therefore include AirShopping messages, OfferPrice messages and the like, according to the NDC standard.
  • OfferPrice messages can also occur to those skilled in the art, further examples of which will also be mentioned below.
  • Data generated within the system 100 such as data representing travel items generated by the provider subsystems 108, is also referred to herein as content.
  • the generation of content is not only computationally complex, but can also be highly variable according to a wide variety of conditions. For example, a request defining specific flight parameters (e.g. a non-stop flight from Barcelona to Montreal on February 16) may return content defining a flight with a first price. The same request made the following day may return content defining a flight with a second price that is different from the first price. The distinct prices may even correspond to the same flight, operated by the same airline.
  • Other item attributes defined in content generated by the provider subsystems 108 can be subject to similar variations, such as ancillary services included with a flight and the like.
  • Variations in content such as those mentioned above may be partially or entirely opaque to an operator of a client subsystem 104.
  • a given set of content defining one or more items that may be purchased by or on behalf of a customer, may include a validity time.
  • the content mentioned above defines an offer, which can be booked by or on behalf of a customer (thereby leading to generation of an order).
  • the validity time is set by the provider subsystem 108, and indicates a period of time (beginning from the generation of the content) for which the offer is valid.
  • a provider subsystem 108 may transmit content for delivery to a client subsystem 104 defining the above-mentioned flight from Barcelona to Montreal, along with a validity time indicating that the offer is valid for three days. If the client subsystem 104 attempts to book (i.e. convert to an order) the offer four days later, the request may be denied and the client subsystem 104 may be required to obtain new offers.
  • the relevant provider subsystem 108 may also provide the client subsystem 104 that initiated the booking with an expiry time.
  • the expiry time indicates a time period in which a condition must be satisfied for the booking to remain active.
  • the condition can be, for example, the provision of payment for the corresponding item(s) to the provider subsystem 108. That is, in some implementations an offer can be booked without immediate payment being made.
  • a client subsystem 104 can book an offer, securing the relevant item on behalf of a customer, but may be permitted 24 hours to provide payment.
  • the 24-hour period is the expiry time, and if payment is not provided within the expiry time, the booking is revoked. In other examples, rather than the booking being revoked after the expiry time, the price of the item may be subject to change.
  • the opacity of variations in content, as well as the availability of the above- mentioned expiry time, may lead the control of client subsystems 104 (e.g. by operators thereof) to request updated content from at least some of the provider subsystems 108.
  • the updated content can be evaluated to determine whether it is more desirable than the currently booked content (i.e. “better” than the currently booked order).
  • the mechanisms employed to perform such an evaluation are beyond the scope of this discussion.
  • Examples of content that is more desirable than initial (booked) content can include content defining the same item at a lower price, including additional (or more relevant to the customer) ancillary services, and the like.
  • the initial content may be replaced with the updated content.
  • Various mechanisms may be employed for such replacement, depending in part on the provider subsystem ⁇ ) 108 from which the initial content and the updated content originated.
  • requests for updated content generated by client subsystems 104 following bookings can lead to significant additional computational load on components of the system 100 such as the provider subsystems 108, as well as increased traffic in the network 112.
  • the system 100 is therefore also configured to optimize the generation and transmission of such requests for updated content.
  • the optimization enabled by the system 100 can enable client subsystems 104 to continue determining whether better offers are available than an initial order, while mitigating the impact of such determinations on computational resources within the system 100.
  • the system 100 includes an intermediation server 116 (also referred to herein simply as the server 116) connected with the network 112. Requests generated by the client subsystems 104 are transmitted via the network 112 to the intermediation server 116.
  • the intermediation server 116 receives requests from the client subsystems 104, and passes such requests to the provider subsystems 108.
  • the intermediation server 116 also receives responses from the provider subsystems 108, for return to the client subsystems 104.
  • the server 116 can also relay messages between the client subsystems 104 and the provider subsystems 108 to book offers (i.e. to generate orders), and to modify such orders.
  • the server 116 also obtains instructions, e.g. directly from the client subsystems 104 or based on stored configuration settings, to check for updated content corresponding to previously booked content. Responsive to such instructions, the server 116 performs various actions to determine whether to check for updated content, and selects a mechanism for performing such a check when the determination is affirmative.
  • the above-mentioned configuration settings, as well as other configuration data to be discussed below in greater detail, are stored at the server 116 in a configuration repository 120.
  • the server 116 can also store the content itself (e.g. any booked orders) in a content repository 124.
  • the intermediation server 116 includes at least one processor 200, such as a central processing unit (CPU) or the like.
  • the processor 200 is interconnected with a memory 204, implemented as a suitable non-transitory computer-readable medium (e.g. a suitable combination of non-volatile and volatile memory subsystems including any one or more of Random Access Memory (RAM), read only memory (ROM), Electrically Erasable Programmable Read Only Memory (EEPROM), flash memory, magnetic computer storage, and the like).
  • RAM Random Access Memory
  • ROM read only memory
  • EEPROM Electrically Erasable Programmable Read Only Memory
  • flash memory magnetic computer storage, and the like.
  • the processor 200 and the memory 204 are generally comprised of one or more integrated circuits (ICs).
  • the processor 200 is also interconnected with a communication interface 208, which enables the server 116 to communicate with the other computing devices of the system 100 via the network 112.
  • the communication interface 208 therefore includes any necessary components (e.g. network interface controllers (NICs), radio units, and the like) to communicate via the network 112.
  • NICs network interface controllers
  • the specific components of the communication interface 208 are selected based on the nature of the network 112.
  • the server 116 can also include input and output devices connected to the processor 200, such as keyboards, mice, displays, and the like (not shown).
  • the components of the server 116 mentioned above can be deployed in a single enclosure, or in a distributed format.
  • the server 116 includes a plurality of processors, either sharing the memory 204 and communication interface 208, or each having distinct associated memories and communication interfaces.
  • the memory 204 stores the repositories 120 and 124, as well as computer-readable instructions executable by the processor 200 to implement various functionality.
  • the computer-readable instructions may also be referred to as appli- cations, and in the illustrated example the memory 204 stores a content handling application 212 (also referred to herein simply as the application 212).
  • the processor 200 and more generally the server 116, are said to perform, or to be configured to perform, those actions. It will be understood that they are so configured via the execution (by the processor 200) of the instructions of the applications stored in memory 204, including the application 212.
  • Execution of the application 212 by the processor 200 configures the server 116 to obtain instructions to request updated content corresponding to content stored in the repository 124, and to process such requests as described in detail below.
  • FIG. 3 illustrates a method 300 of optimizing transmission of requests for updated content from external data sources.
  • the performance of the method 300 will be discussed in conjunction with its performance within the system 100, and specifically by the intermediation server 116 via execution of the integration application 212.
  • the server 116 receives content for storage in the repository 124.
  • the receipt of content can be preceded by a variety of other actions that are outside the scope of the present discussion.
  • those actions include receiving a request for offers at the server 116 from a client subsystem 104 (e.g. the client subsystem 104-1), and the transmission of requests to at least one of the provider subsystems 108 based on the request for offers.
  • the actions further include receiving offers from the provider subsystems 108, the transmission of the offers to the client subsystem 104-1, and the receipt of a selection of a subset of the offers for booking from the client subsystem 104-1.
  • the content received at block 305 corresponds to a booked offer, also referred to as an order.
  • FIG. 4 an example performance of block 305 is shown.
  • the provider subsystem 108-1 is shown transmitting content in the form of a data object 400 to the server 116 via the network 112.
  • the legacy data object 400 can be, for example, an Order record resulting from an earlier request by the client subsystem 104-1 to book an offer.
  • the data object 400 is stored in the repository 124.
  • the contents of the data object 400 are also shown in FIG. 4.
  • the data object 400 includes a record identifier field 404 (e.g. a booking reference), a name field 408, and an item definition field 412.
  • the item definition field 412 includes various attributes of the item defined by the data object 400, such as a flight identifier (“6X 001”), an origin identifier (corresponding to Barcelona in this example), a destination identifier (corresponding to Montreal in this example), and a price.
  • the data object 400 also defines an expiry time of 48 hours from generation of the order (which may also be indicated in the data object 400).
  • the expiry time can be defined in other ways as well; for example, the expiry may be defined as a time and date rather than a duration.
  • a wide variety of additional attributes can be included in the field 412, and various other fields can also be included in the data object 400.
  • the server 116 obtains an instruction to request updated content.
  • the instruction is to request updated content corresponding to the data object 400 shown in FIG. 4.
  • the server 116 can perform multiple instances of the method 300 in parallel, each corresponding to a different data object.
  • the server 116 obtains such an instruction by receiving the instruction from the client subsystem 104 associated with the relevant data object.
  • the client subsystem 104-1 with which the data object 400 is stored can transmit an instruction to check for updated content to the server 116 via the network 112.
  • the server 116 automatically generates the request internally, for example at a configurable frequency.
  • the mechanism by which the server 116 obtains the instruction at block 310 can be defined in update scheduling configuration data stored in the repository 120.
  • Example update scheduling configuration data is shown below in Table 1.
  • Update Scheduling Configuration [Table 1]
  • Table 1 indicates that automatic generation of instructions to request updated content is enabled for the client subsystem 104-1, but disabled for the client subsystem 104- 2. Therefore, the performance of block 310 for data objects associated with the client subsystem 104-2 involves receiving an explicit instruction from the client subsystem 104-2.
  • the performance of block 310 for data objects associated with the client subsystem 104-1 includes automatic generation, by the server 116 itself, of such requests according to the settings shown in Table 1.
  • the server 116 is configured to generate an instruction at block 310 corresponding to the data object 400 once per day at 12pm.
  • the enabling of automatic request generation can disable the receipt of explicit instructions. In other examples, however, enabling automatic request generation still permits the receipt of explicit instructions to request updated content.
  • Other mechanisms can be employed for automatically generated requests than the scheduled implementation shown in Table 1.
  • the server 116 can be configured to automatically generate an instruction at block 310 within a predetermined time period of the expiry time specific to the relevant data object. That is, the “frequency” setting above can specify “1 hour before expiry”, for example.
  • the update scheduling configuration data enables the server 116 to operate in either of a passive mode and an active mode.
  • a client subsystem 104 need not explicitly send an instruction to the server 116 via the network 112 (thus causing additional network load).
  • the client subsystem 104 In the active mode, in contrast, the client subsystem 104 actively requests update checks.
  • Table 1 A wide variety of other settings can also be stored in Table 1, For example, configurations can be specific not only to a client subsystem 104, but to a pairing of client subsystem 104 and customer, a pairing of client subsystem 104 and provider subsystem 108, and the like.
  • the server 116 determines whether to initiate a check for updated content related to the data object 400. For example, any instruction obtained at block 310 can be placed in an instruction queue in the memory 204, and at block 315 the server 116 determines whether to retrieve an instruction from the queue and generate update request(s) according to the instruction. The determination at block 315 is based on any of a variety of optimization parameters.
  • the optimization parameters can include update request frequency thresholds, time thresholds, and historical trend data corresponding to the data object 400.
  • the determination at block 315 can be based on various factors. In some examples, turning to FIG. 5, the determination at block 315 can be performed according to a method 500, in which at least one threshold is evaluated at the server 116. In particular, at block 505 the server 116 is configured to determine a remaining time between the current time and the expiry time defined in the data object 400. The server 116 is further configured to determine whether the remaining time is below a time threshold.
  • the repository 120 can store time thresholds for each provider subsystem 108, for each pairing of provider subsystem 108 and client subsystem 104, a single system- wide threshold, or the like.
  • the server 116 When the remaining time before expiry is below the above-mentioned threshold, the server 116 returns to block 310. In returning to block 310, the server 116 can simply discard the instruction generated at the previous performance of block 310, or can retain the instruction in the above-mentioned queue for re- evaluation at a subsequent performance of block 315. In other words, when the remaining time is sufficiently low, further update requests may be suppressed by the server 116.
  • the server 116 proceeds to block 510.
  • the server 116 is configured to select one of a set of provider subsystems 108 to which update requests may be sent. That is, the actions performed in the remainder of the method 500 are not necessarily restricted to the provider subsystem 108 that originated the data object 400, but can be repeated for other provider subsystems 108.
  • Which provider subsystems 108 are selected amongst in a given performance of the method 500 can be determined according to configuration parameters in the repository 120. For example, such parameters can specify which provider subsystems 108 to select from at block 510 for each client subsystem 104.
  • the provider subsystem 108-1 is selected.
  • the server 116 determines, for the selected provider subsystem 108, whether an update request frequency threshold has been exceeded.
  • update request frequency thresholds are contemplated. Examples of such thresholds, which can be stored in the repository 120, are shown below in Table 2.
  • Frequency Thresholds [Table 2] thresholds for different types of requests.
  • the above example specifies different thresholds for “OrderReshop” requests, which are NDC- based requests specifically for updating existing bookings, and for AirShopping requests, which include a variety of NDC-based requests for obtaining new offers (i.e. not connected with an existing booking / order).
  • Other types of update requests are also contemplated in the context of NDC-based systems, including OfferPrice requests, SeatAvailability requests, and ServiceList requests.
  • the thresholds specified in Table 2 may be populated at deployment of the system 100, for example according to business or technical requirements communicated to the server 116 by the provider subsystems 108. In other examples, the thresholds may be determined by the server 116 dynamically. Specifically, exceeding the above thresholds for a given provider subsystem 108 may result in subsequent update requests being rejected by the provider subsystem 108. The server 116 can determine a threshold based on how many requests of a given type were sent to that provider subsystem 108 over a time period (e.g. one day). [0066] At block 515, therefore, the server 116 determines whether any of the above thresholds have been exceeded for the selected provider subsystem 108. When the determination at block 515 is negative, the server 116 includes the selected provider subsystem 108 in the update request generation process to be discussed below. The server 116 then determines whether any provider subsystems 108 remain to be processed at block 525.
  • the server 116 proceeds directly to block 525. In other words, block 520 is bypassed, and no update requests will be transmitted to the selected provider subsystem 108. In some examples, some request type thresholds may have been exceeded for a given provider subsystem 108, while other thresholds may not have been exceeded. In such examples, the determination at block 515 can be negative, and at block 520 the server 116 marks the relevant provider subsystem 108 as a candidate for an update request, and also stores the type(s) of request for which thresholds have not been exceeded, for later use.
  • the server 116 proceeds from block 525 to block 510 to select the next provider subsystem 108.
  • the determination at block 525 is negative, and the server 116 proceeds to block 320 for generation of update requests.
  • FIG. 6 illustrates further functionality according to which the server 116 can perform the determination at block 315.
  • FIG. 6 illustrates a method 600 according to which the server 116 can determine whether to proceed with at least one update request at block 315.
  • the method 600 is illustrated as having been integrated with the functionality of the method 500 discussed above. In other examples, however, the method 600 can be performed independently of the method 500 to implement block 315.
  • the server 116 is configured to retrieve trend data for a given attribute specified in the data object 400. For example, at block 605 the server 116 can retrieve the trend data for the price of flights between Barcelona and Montreal. The trend data can be retrieved from another repository at the server 116, or by requesting the data from another component (not shown) of the system 100.
  • the trend data retrieved at block 605 includes current trend data, defining variations in the relevant attribute (e.g. price) extending from the current time and date back in time by a configurable interval.
  • the trend data retrieved at block 605 also includes historical trend data, defining variations in the same attribute over a corresponding period beginning earlier in time. For example, if the current trend data indicates price variations from three months ago to the current time, the historical trend data may indicate price variations from one year and three months ago to nine months ago. That is, the current trend data represents a period of three months, and the historical trend data represents the same three-month period from one year earlier, as well as the next three months of the previous year.
  • example trend data is shown, including current trend data 700 and historical trend data 704.
  • the current trend data may extend from a current time 708 back by a predefined period of time, e.g. 5 months.
  • the historical trend data 704 extends from one year and 5 months in the past (i.e. one year before the beginning of the current trend data) to three months before the beginning of the current trend data 700.
  • a wide variety of other time periods may also be employed.
  • a current time 708 is also shown, as is a time 712 at which the data object 400 was generated (i.e. a booking time).
  • the trend data 700 and 704 are overlaid, ignoring the year and aligning the trends by month and day.
  • the server 116 is configured to determine whether the current trend data matches the historical trend data. That is, the server 116 is configured to determine, in the present example, whether recent variations in pricing for flights from Barcelona to Montreal are similar to variations in pricing for the same flights over the same period of the previous year. Various techniques can be applied by the server 116 to make the determination at block 610, and the match need not be exact.
  • the current trend data 700 follows a similar path as the historical trend data 704.
  • the determination at block 610 is therefore affirmative.
  • the server 116 therefore proceeds to block 615.
  • the server 116 instead proceeds to block 510 and the trend data is not used in making the determination at block 315.
  • the server 116 determines whether the historical trend data indicates a non-advantageous trend.
  • the server 116 can determine whether the historical trend data 704 indicates that the price is likely to increase in the near future (e.g. before the expiry of the data object 400).
  • the server 116 is configured to predict future changes in the relevant attribute using the historical trend data.
  • further evaluation of thresholds can continue at block 510.
  • the historical trend data 704 indicates a continued rise in prices beyond the current time 708.
  • the determination at block 615 is therefore affirmative, and the server 116 proceeds directly to block 310.
  • the server 116 can suppress update requests, relieving the system 100 of the additional network and computational load imposed by such requests, when historical data indicates that such requests are unlikely to lead to better offers.
  • the server 116 can also generate an alert, warning message or the like for transmission to the relevant client subsystem 104, indicating that if payment is not provided before the expiry time, historical data indicates a likely increase in price.
  • the definition of “non- advantageous” at block 615 can vary widely, depending on the configuration of the server 116, and need not be limited to price data (or specifically to increasing prices).
  • the server 116 suppresses the sending of update requests, and returns to block 310.
  • the determination at block 315 can be performed multiple times for distinct provider subsystems 108, and multiple instances of subsequent blocks of the method 300 can therefore also be performed. In other words, a negative determination at block 315 indicates that for a given provider subsystem 108, no update request will be sent. Update requests may still be sent to other provider subsystems 108, however.
  • the server 116 Following an affirmative determination at block 315, at block 320 the server 116 generates and sends an update request to at least one provider subsystem 108. In particular, an update request is sent to each provider subsystem 108 for which an affirmative determination was made at block 315.
  • the generation and transmission of update requests at block 320 is based on the data object 400 itself, and on further optimization parameters in the repository 120.
  • the repository 120 can specify which types of requests to employ for each provider subsystem 108.
  • the selection of request type can also be informed by the determination at block 515 (e.g. the server 116 can select a request type for which the determination at block 515 was negative).
  • the update requests in general, can be explicit update requests directed to the provider subsystem 108 that originated the data object 400, or new offer requests directed to other provider subsystems 108.
  • the new offer requests e.g. NDC AirShopping requests
  • NDC AirShopping requests can be populated based on the content of the data object 400.
  • an AirShopping request may be transmitted to the provider subsystem 108-2 for flights from Barcelona to Montreal.
  • Other attributes e.g. dates, ancillary services and the like
  • An update request (e.g. an NDC OrderReshop request) may be sent to the provider subsystem 108-1
  • the server 116 is configured to receive updated sets of content from each provider subsystem 108 to which a request was sent at block 320.
  • the server 116 is configured to automatically evaluate the updated content sets received at block 325.
  • the processes by which the server 116 evaluates the updated content sets relative to the initial content are beyond the scope of this discussion.
  • the repository 120 can contain scoring algorithms and the like for execution by the server 116 to determine whether a given update content set represents a “better” offer than the initial content of the data object 400, as well as than the other updated content sets.
  • the updated content sets can be discarded and the server 116 can return to block 310.
  • the server 116 can automatically initiate one or more actions to replace the initial content, or can prompt the relevant client subsystem 104 for further instruction.
  • the repository 120 can store (e.g. in association with the update scheduling configuration data mentioned above) an indication for each client subsystem 104 of whether content replacement is to be performed automatically.
  • the server 116 When the server 116 is configured (e.g. for the client subsystem 104 associated with the data object 400) to perform content replacement automatically, at block 335 the server 116 selects the best offer from the updated content sets received at block 325, and generates at least one replacement request to book the updated content.
  • the server 116 is configured to prompt the client subsystem 104 associated with the data object 400 before proceeding to block 335. That is, the performance of block 330 includes both the identification of a better offer, and the determination of whether the relevant client subsystem 104 has instructed the server 116 to replace the data object 400 with that better offer.
  • the server 116 can therefore complete the performance of block 330 by sending a message to the client subsystem 104 indicating the contents of the selected updated content, and awaiting a selection or dismissal of the updated content from the client subsystem 104. When a selection is received, the server 116 proceeds to block 335. Otherwise, the server 116 returns to block 310.
  • the nature of the replacement request(s) sent at block 335 varies according to the provider subsystem 108 associated with the initial content of the data object 400, and the provider subsystem 108 associated with the selected updated content.
  • the replacement requests can include a cancellation request to the provider subsystem 108 associated with the data object 400 and a booking request corresponding to the selected updated content.
  • a single replacement request in the form of an update request e.g. Or- derReshop
  • the server 116 can send a single booking request at block 335, and take no specific action in relation to the initial content. Instead, the initial content can simply be allowed to expire.
  • the functionality of the application 212 may be implemented using pre-programmed hardware or firmware elements (e.g., application specific integrated circuits (ASICs), electrically erasable programmable read-only memories (EEPROMs), etc.), or other related components.
  • ASICs application specific integrated circuits
  • EEPROMs electrically erasable programmable read-only memories

Landscapes

  • Engineering & Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Data Mining & Analysis (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computing Systems (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

Un procédé d'optimisation de la transmission de demandes de contenu mis à jour à partir de sources de données externes consiste : à stocker un objet de données contenant un contenu initial reçu en provenance d'au moins l'une des sources de données externes et associé à un temps d'expiration ; à stocker un ensemble de paramètres d'optimisation ; à obtenir une instruction de demande de contenu mis à jour correspondant à l'objet de données ; en réponse à l'obtention de l'instruction, à déterminer, sur la base des paramètres d'optimisation et du temps d'expiration, s'il faut demander un contenu mis à jour à partir des sources de données externes ; lorsque la détermination est affirmative, à transmettre au moins une demande de mise à jour à au moins l'une des sources de données externes sur la base du contenu initial et des paramètres d'optimisation ; et en réponse à la transmission de la ou des demandes de mise à jour, à recevoir et à stocker des ensembles respectifs de contenu mis à jour à partir des sources de données externes.
PCT/EP2020/083207 2019-12-23 2020-11-24 Système et procédé d'optimisation de la transmission de demandes de contenu mis à jour à partir de sources de données externes WO2021129991A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
EP20808167.9A EP4081912A1 (fr) 2019-12-23 2020-11-24 Système et procédé d'optimisation de la transmission de demandes de contenu mis à jour à partir de sources de données externes
CN202080089661.XA CN114846460A (zh) 2019-12-23 2020-11-24 用于优化对外部数据源的更新内容的请求的发送的系统和方法

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
FRFR1915430 2019-12-23
FR1915430A FR3105523B1 (fr) 2019-12-23 2019-12-23 Système et procédé pour optimiser la transmission des demandes de contenu mis à jour provenant de sources de données externes
US16/724,542 2019-12-23
US16/724,542 US11461308B2 (en) 2019-12-23 2019-12-23 System and method for optimizing transmission of requests for updated content from external data sources

Publications (1)

Publication Number Publication Date
WO2021129991A1 true WO2021129991A1 (fr) 2021-07-01

Family

ID=73455749

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2020/083207 WO2021129991A1 (fr) 2019-12-23 2020-11-24 Système et procédé d'optimisation de la transmission de demandes de contenu mis à jour à partir de sources de données externes

Country Status (3)

Country Link
EP (1) EP4081912A1 (fr)
CN (1) CN114846460A (fr)
WO (1) WO2021129991A1 (fr)

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080235292A1 (en) * 2005-10-03 2008-09-25 Amadeus S.A.S. System and Method to Maintain Coherence of Cache Contents in a Multi-Tier System Aimed at Interfacing Large Databases

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1330328A (zh) * 2000-06-16 2002-01-09 东芝株式会社 信息中继装置和存储介质
JP2004528631A (ja) * 2001-02-28 2004-09-16 ミュージックレベリオン．コム・インコーポレーテッド デジタルオンライン交換
US20100017259A1 (en) * 2008-07-15 2010-01-21 Publiso, Inc. Method and system of automatically setting and changing price for online content selling
US10827037B2 (en) * 2017-09-30 2020-11-03 Microsoft Technology Licensing, Llc Server to server interaction in content item selection events
CN109959465A (zh) * 2017-12-22 2019-07-02 中冶京诚工程技术有限公司 电机温度预警保护方法、计算机设备及可读存储介质
CN110134797A (zh) * 2019-04-29 2019-08-16 贳巽(北京)国际商业数据技术股份公司 一种基于事理图谱和多因子模型研判金融市场变化的方法
CN110489631A (zh) * 2019-07-10 2019-11-22 平安科技（深圳）有限公司 股市趋势预测方法、装置、计算机设备和存储介质

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080235292A1 (en) * 2005-10-03 2008-09-25 Amadeus S.A.S. System and Method to Maintain Coherence of Cache Contents in a Multi-Tier System Aimed at Interfacing Large Databases

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
"LECTURE NOTES IN COMPUTER SCIENCE", vol. 1795, 1 January 2000, SPRINGER BERLIN HEIDELBERG, Berlin, Heidelberg, ISBN: 978-3-54-045234-8, ISSN: 0302-9743, article LOUIS DEGENARO ET AL: "A Middleware System Which Intelligently Caches Query Results", pages: 24 - 44, XP055212060, DOI: 10.1007/3-540-45559-0_2 *
MOKRANE BOUZEGHOUB: "A framework for analysis of data freshness", INFORMATION QUALITY IN INFORMATION SYSTEMS, ACM, 2 PENN PLAZA, SUITE 701 NEW YORK NY 10121-0701 USA, 18 June 2004 (2004-06-18), pages 59 - 67, XP058153817, ISBN: 978-1-58113-902-0, DOI: 10.1145/1012453.1012464 *

Also Published As

Publication number Publication date
EP4081912A1 (fr) 2022-11-02
CN114846460A (zh) 2022-08-02

Similar Documents

Publication Publication Date Title
US11789932B2 (en) System and method for optimizing transmission of requests for updated content from external data sources
EP3745277A1 (fr) Agrégation et mise à jour d'objets de données hétérogènes
US11907323B2 (en) System and method for legacy-based access to non-legacy data
US11164268B2 (en) System, method and apparatus for responding differentially to data requests
EP3828728A1 (fr) Système et procédé de contrôle d'accès différentiel de données partagées
US11586978B2 (en) Device, system and method for providing provider objects from a cache
US11176599B2 (en) System and method of auxiliary data access
WO2021129991A1 (fr) Système et procédé d'optimisation de la transmission de demandes de contenu mis à jour à partir de sources de données externes
EP3842959A1 (fr) Système et procédé d'accès patrimonial à des données non-patrimoniales
CN114385655A (zh) 提供航班查询服务的方法及航班查询系统
US11709952B2 (en) System and method of differential access control of shared data
EP3828727A1 (fr) Système et procédé d'accès de données auxiliaires
EP3809284B1 (fr) Système et procédé de réduction de charge dans le traitement de requêtes
US11140237B2 (en) System and method for load mitigation in request handling
US20210375442A1 (en) Patient care exchange portal with market analysis
US20240135264A1 (en) Device, system and method for generating trained models to generate provider objects
US20240232728A9 (en) Device, system and method for generating trained models to generate provider objects
US20240184776A1 (en) Device, system and method for reducing bandwidth usage by performing provider object adjustments at an intermediation server based on historical data
US20240054448A1 (en) Device, system and method for managing inventory of provider objects
EP3809276A1 (fr) Dispositif, système et procédé de fourniture d'objets de fournisseurs à partir d'une mémoire cache
US20240232735A9 (en) Device, system and method for distributing and locally persisting provider objects
US20240135272A1 (en) Device, system and method for distributing and locally persisting provider objects
FR3098943A1 (fr) Système, procédé et dispositif pour répondre de manière différentielle aux requêtes de données
KR20040104013A (ko) 배송일 안내 시스템 및 방법
FR3102261A1 (fr) Système et procédé pour mitiger la charge lors de la gestion de requête

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 20808167

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2020808167

Country of ref document: EP

Effective date: 20220725