Patent Application
20240281728
The deployment of resources such as vehicles (e.g., aircraft and the like) to provide services may be impacted by a wide variety of events external to the entity deploying such resources. The breadth and unpredictability of such events renders automated detection of the events and adaptation of resource deployment technically difficult, such that such detection and adaption is performed manually, and thus often inefficiently or not at all.
An aspect of the specification provides a method in a computing device of adjustment of operational resources based on external events, the method comprising: retrieving input data from at least one data source external to the computing device; extracting, from the input data, an event detection record including a time period associated with an event, a location associated with the event, and an impact direction associated with the event; retrieving, based on the time period and the location, a set of operational resource data; generating, based on the event detection record and the set of operational resource data, an impact magnitude associated with the event; selecting, based on the impact direction and the impact magnitude, a supplier of the operational resources; and transmitting a notification to a computing device associated with the selected supplier, the notification including the event detection record.
Another aspect of the specification provides a computing device, comprising: a communications interface; and a processor configured to: retrieve input data from at least one data source external to the computing device; extract, from the input data, an event detection record including a time period associated with an event, a location associated with the event, and an impact direction associated with the event; retrieve, based on the time period and the location, a set of operational resource data; generate, based on the event detection record and the set of operational resource data, an impact magnitude associated with the event; select, based on the impact direction and the impact magnitude, a supplier of the operational resources; and transmit a notification to a computing device associated with the selected supplier, the notification including the event detection record.
Embodiments are described with reference to the following figures, in which:
The system 100 includes a supplier subsystem 108-1 e.g., operated by or on behalf of the above-mentioned supplier. The supplier subsystem 108-1 includes various computing components enabling the deployment of operational resources such as the aircraft 104, as well as enabling the sale of tickets granting access to the aircraft 104. For example, the subsystem 108-1 can maintain a repository 112-1 containing operational resource data defining flight dates and times, prices, inventory (e.g., available seats on the aircraft 104). The repository 112-1 can also include purchase records defining any issued tickets for a given flight operated using the aircraft 104. A purchase record, i.e., a ticket, includes or is otherwise associated with identifying information for the holder of that ticket. The identifying information can be stored, for example, in a passenger name record (PNR) or the like, as will be apparent to those skilled in the art.
As will be apparent, the operational resource data mentioned above can also be maintained in various distinct repositories and managed via the actions of multiple computing modules implemented within the subsystem 108-1. The repository 112-1 is shown as a single element merely for simplicity of illustration.
The system 108 can include a plurality of distinct supplier subsystems, such as a supplier subsystem 108-2 maintaining a repository 112-2, and a supplier subsystem 108-3 maintaining a repository 112-3, as shown in
The system 100 also includes client subsystems 116-1 and 116-2. As noted in connection with the supplier subsystems 108, the system 100 can include smaller or greater numbers of client subsystems 116 than shown in
In general, the client subsystems 116 can interact with the supplier subsystems 108, e.g., via a network 120 (which may be any suitable combination of local and wide-area networks), to view available flights in what may be referred to as shopping process, and optionally to purchase access to the aircraft 104 (or other aircrafts operated by the suppliers) for particular origin and destination locations, at particular dates and times.
The actual deployment of operational resources to provide previously purchased flight services, however, may be complicated by a wide variety of external events (i.e., events that are outside the control of any given supplier). Such external events can be disruptive, in that they interfere with the delivery of flights or other services. Examples of disruptive external events include extreme weather, volcanic eruptions, border restrictions implemented by regional and/or national governments, strikes or other labour-related disruptions, and the like. As will be apparent, those events may prevent aircraft from taking off or landing, prevent travelers from reaching airports and therefore cause travelers to miss flights, and the like.
Other external events may, rather than disrupting the delivery of planned flights or other deployments of operational resources, lead to increased demand for future flights or other services. Examples of such non-disruptive events include the removal or relaxation or border restrictions between jurisdictions, the announcement of a major sporting event in a particular location (which may spur demand for travel to that location), or the like.
Certain events, particularly the disruptive events noted above, may impose operational adjustments on suppliers (e.g., because aircraft at a given airport may be grounded by extreme weather). Other events, such as the non-disruptive examples mentioned above, may not impose operational adjustments, but operational adjustments such as modified ticket pricing, bundled services, or the like, may enable a supplier to increase the number of tickets sold, the price of such tickets, or the like. More broadly, it may be advantageous or even required for a supplier to adapt the deployment of operational resources to both types of event (disruptive/negative, and non-disruptive/positive).
Certain of the above-mentioned events are difficult or impossible to predict. That is, it may be difficult to anticipate an event prior to the actual occurrence of the event. Further, whether or not an event can be predicted prior to its occurrence, discovery of the event by a supplier subsystem 108 can be complicated by the breadth of possible events, and the wide variety of information sources from which such events may be discovered. As a result of the above difficulties, adjustments made in existing systems in response to such events (e.g., rescheduling or cancelling flights, creating promotional ticket sales, and the like) are performed manually by staff at the suppliers. Adjustments depend, in other words, on individual staff members discovering the existence of an event, and arbitrarily selecting an operational response (if any) to the event. Operational adjustments may therefore not occur until the impact of a given event is felt within the elements of the system 100 under a supplier's control, by which time the effectiveness of adjustments to mitigate the impact may be limited. In other cases, a supplier may not make any adjustments to an event, e.g., because the event was simply not discovered by the supplier.
Although the automation of event discovery and/or operational adjustment generation may be appealing to address the above challenges, various technical barriers complicate such automation. For example, external events may be detected from a wide variety of event data sources 122-1, 122-2, and so on, of greatly varying reliability. The sources 122 are external to the supplier subsystems 108, and may be operated by governmental authorities, news organizations, individuals, or other entities. The sources 122 may also publish or otherwise disseminate information corresponding to an event in widely varying formats, many of which are unstructured (e.g., using natural language, rather than defined name-value pairs that are readily consumable by software processes). For example, some event data sources 122 may publish event data in a predefined structured format to which entities such as the supplier subsystems 108 may subscribe, while event data sources 122 can include microblogging services operated by large numbers of individuals and used to publish natural language information, only a portion of which may define events.
In addition, the significant breadth of possible events and sources may lead to the collection of data defining large volumes of events with little or no operational impact on a given supplier subsystem 108. Due to the variable nature of the data defining events, however, assessing the potential impact of an event is also difficult. The volume of events that may result from an automated discovery system may be sufficiently large as to overwhelm staff of software processes tasked with devising operational adjustments in response to relevant events.
To resolve at least some of the above technical challenges, the system 100 further includes an event handling server 124 that performs various functions to discover events, assess the potential impact of such events (e.g., before that impact is felt by a supplier, in some examples, even for an event that has already occurred), and notify either or both of affected supplier subsystems 108 and client subsystems 116 of such events. In some examples, the server 124 can also generate data defining adjustments to operational resources, e.g., to mitigate the impact of disruptive events and/or take advantage of non-disruptive events to drive ticket sales or the like, e.g., more rapidly and consistently than in existing systems.
Although the examples described herein are in the context or air travel, it will be apparent to those skilled in the art from this discussion may also be applied to a variety of other systems and associated operational resources, including other travel-related services (e.g., ground-based travel such as trains or buses, hotels, and the like).
The processor 200 is also interconnected with a communications interface 208, which enables the server 124 to communicate with the other computing devices of the system 100 via the network 120, including the supplier subsystems 108, client subsystems 116, and event data sources 122. The communications interface 208 therefore includes any necessary components (e.g., network interface controllers (NICs), and the like) to communicate via the network 120. The specific components of the communications interface 208 are selected based on upon the nature of the network 120. The server 124 can also include input and output devices connected to the processor 200, such as keyboards, mice, displays, and the like (not shown). Such input and output devices may be deployed remotely from the server 124, e.g., at a distinct computing device operated as an administrative terminal for the server 124 and connected to the server 124 via the network 120.
The components of the server 124 mentioned above can be deployed in a single enclosure, or in a distributed format. In some examples, therefore, the server 124 includes a plurality of processors, either sharing the memory 204 and communications interface 208, or each having distinct associated memories and communications interfaces.
The memory 204 stores a plurality of computer-readable programming instructions, executable by the processor 200. The instructions stored in the memory 204 include an event handling application 212, execution of which by the processor 200 configures the server 124 to retrieve raw input data from the event data sources 122, process the input data to detect events therein and generate structured representations of the detected events. Execution of the application 212 can also configure the processor 200 to generate notifications regarding detected events, for transmission to supplier subsystems 108 and/or client subsystems 116. In some examples, execution of the application 212 can also configure the processor 200 to automatically generate adjustments to operational data at one or more supplier subsystems 108 in response to event detections.
The memory 204 also stores various data processed during the execution of the application 212. In the illustrated example, the data stored in the memory 204 includes a source definition repository 216 containing configuration data corresponding to the event data sources 122. As discussed further below, the repository 216 includes, for each event data source 122, configuration data defining how the server 124 interacts with that source 122 to retrieve input data potentially defining an event. The configuration data may also include data defining processing stages for input data from the corresponding source.
The memory 204 also stores an input data repository 220, configured to store raw input data obtained from the event data sources 122, e.g., according to the configuration data in the repository 216. The memory 204 further stores an event detection record repository 224. As discussed below, the raw input data from the repository 220 is processed (e.g., according to configuration settings specified in the repository 216) to detect events therein and define the detected events in a predefined, structured format that is consumable by downstream processes implemented by the server 124.
The memory 204 can also store a repository 228 defining notification and/or recommendation rules, resources (e.g., graphics, text, and other data) and the like for each supplier subsystem 108. The data in the repository 228, in other words, can represent supplier profiles, e.g., defining which events a given supplier wishes to be notified of, and/or which adjustments the supplier wishes implemented or suggested in response to various events.
The repositories 216, 220, 224, and 228 can be implemented in various other arrangements in other examples. For example, the data contained in the repositories mentioned above can be stored in a smaller or larger set of repositories. Further, the functionality implemented by the application 212 can be implemented by a suite of distinct applications executed by the server 124 and/or associated computing devices, in other examples.
Turning to
At block 305, the server 124 is configured to retrieve input data from at least one of the event data sources 122. Retrieval of input data is performed according to the source definitions in the repository 216. Turning to
The source definitions 400 can also include other configuration data controlling how and when the server 124 requests input data from the corresponding source 122. For example, the source definitions 400 include a query period (e.g., one hour for the source definition 400-1, and six hours for the source definition 400-2). The query period defines a frequency with which the server 124 queries each source 122 (e.g., every hour for the source 122-1, and every six hours for the source 122-2). A wide variety of other query periods can also be specified, and the definitions 400 can include further configuration data determining query timing, in some examples. For instance, a definition 400 can include specific times of day to query the corresponding source 122. In other examples, the server 124 can receive input data from one or more sources 122 without explicit queries, e.g., via a subscription mechanism by which the source 122 pushes notification(s) containing input data to the server 124. The server 124 can therefore implement block 305 without transmitting requests to the data sources 122, and can proceed to block 310, for example, upon receiving each event notification from a data source 122.
Certain source definitions 400 can also include configuration data defining search terms. For example, while the definition 400-1 does not include search terms (e.g., indicating that the server 124 retrieves any available input data from the source 122), the definition 400-2 includes the search keywords “delay” and “traffic”. As will be apparent, a wide variety of other search terms can also be employed. The search terms can be selected according to the nature of the corresponding source 122. For example, the source 122-1 may be a governmental agency tasked with publishing data defining disruptions to transit infrastructure in a given region. The source 122-2, in contrast, may be an individual microblogging account, and is therefore expected to include various content that is not relevant to event detection.
The definitions 400 can also include configuration data defining application programming interfaces (APIs) used to interact with the sources 122 (e.g., an API provided by the source 122 for retrieving input data, a website scraping process, or the like). The definitions 400 can further include authentication credentials, and/or input data schemas defining the expected format of input data from a given source. For example, the source 122-1 may produce input data describing events in a predefined structured format, with name-value pairs for event start date and time, end date and time, type, location, and the like. The source 122-2, on the other hand, may produce input data with structured metadata (such as the time and date a microblog post was generated), and an unstructured body (e.g., written in natural language).
Each definition 400 can also include a reliability score for the corresponding source 122. The reliability score, e.g., on a scale of zero to one hundred (although a wide variety of other scoring mechanisms can be employed), indicates how likely input data from the corresponding source 122 is to be accurate, and can be used by the server 124 in subsequent processing of the input data, as described below. In general, input data from a source 122 with a low reliability score is less likely to result in notifications and/or adjustments to operational resource data.
At block 305, therefore, the server 124 is configured to transmit requests to one or more of the event data sources 122 according to the definitions 400 corresponding to those sources 122. In response to such requests, the server 124 can receive input data from the sources 122, e.g., in the form of raw input records 404-1, 404-2, 404-3 as shown in
As will be apparent, the use of source definitions 400 in the repository 216 enables the server 124 to retrieve input data from a readily scalable set of sources with widely varying characteristics. Subsequent processing of the input data by the server 124 then enables the server 124 to normalize the input data to a common, structured format for further action.
Example content for the input records 404-1 and 404-2 are shown in
The record 404-2 includes metadata such as a date on which the record 404-2 was generated at the source 122-2, and a body containing unstructured content (e.g., text, images, and the like presented in natural language rather than readily machine-consumable name-value pairs). The content defined in the record 404-2, therefore, may provide a more detailed description of an event than the record 404-1, but the unstructured nature of the record 404-2 complicates the automated processing of the record 404-2.
Referring again to
To extract event detection records at block 310, each input record 404 is processed, for example according to mechanisms specified in the source definitions 400. For example, the source definition 400-1 can include a mapping between the structured schema of records from the source 122-1 (such as the input record 404-1) and a predefined event detection record schema. The source definition 400-2, in contrast, can include an identifier of one or more natural language processing (NLP) mechanisms to be executed using the content of input records 404 from the source 122-2 as input. NLP mechanisms can, as will be apparent to those skilled in the art, tokenize and process the content of the record to perform sentiment analysis, extract keywords, and the like. For example, one or more NLP models may be generated (e.g., via training data sets prior to performance of the method 300) to extract event keywords likely to indicate the type or category of an event, as well as to extract a time period associated with an event, and an impact direction associated with the event.
The impact direction provides a qualitative indication of the event's impact. Specifically, the impact direction indicates whether the event is likely to be a disruption (that is, a negative event) that may prevent the planned fulfillment of some flights or other travel services. A disruptive event may prevent services from being delivered as previously planned by directly impacting the operational resources involved in providing those services, as in the case of a volcanic eruption preventing take-off and landing of aircraft. In other examples, a disruptive event may prevent services from being delivered as planned by impacting the passengers of one or more flights, as in the case of a railway strike or the like preventing passengers from travelling to an airport. A non-disruptive (that is, a positive event) does not impede delivery of planned services, but instead may increase consumer demand for future services. For example, the announcement of an upcoming major sporting event in a given city may spur demand for travel to that city.
Each record 408 is stored in the repository 224 for further processing. In some cases, the performance of block 310 can lead to the discarding of an input record 404, e.g., if sentiment analysis or other extraction processing yields an indetermined impact direction (e.g., indicating a neutral event, with little or no expected impact, whether positive or negative). A record 404 may also be discarded if keywords extracted from the record 404 do not match any of a predefined set of keywords of interest.
Returning to
The server 124 can retrieve operational resource data at block 315 by querying one or more of the supplier subsystems 108, and/or by querying locally stored data at the server 124. The operational resource data retrieved at block 315 defines, for example, suppliers that operate flights departing and/or arriving at the location(s) defined in the record 408. The operational resource data can also include historical data, e.g., identifying suppliers that have operated flights in the relevant location(s) within a configurable period of time prior to the current time. The operational resource data retrieved at block 315 can also, in some examples, identify the affected flights, and define a number of passengers booked in the affected flights.
At block 320, the server 124 is configured to generate an impact magnitude for an extracted event detection record 408, based on the retrieved operational resource data from block 315. While the impact direction mentioned above in connection with block 310 indicates whether an event is expected to have a disruptive or non-disruptive impact on the deployment of operational resources, the impact magnitude determined at block 320 indicates the expected severity of the impact. The server 124 can generate an impact magnitude in the form of a score, for example, based on any combination of the affected location(s) in the record 408, the time period in the record 408, and the affected suppliers and/or passengers in the data retrieved at block 315. For example, events affecting longer time periods can be scored higher, as can events affecting broader geographic regions and events affecting larger numbers of suppliers and/or passengers. The server 124 may store, for example, a decision tree or other ruleset for generating a score according to what event data is available (e.g., whether a number of affected passengers is available).
The server 124 can further be configured to apply one or more thresholds to the score, e.g., to produce a discretized impact magnitude selected from a relatively small set of possible values (e.g., low, medium, and high). The thresholds can be stored as configuration data at the server 124. For example, an event with time and/or location properties corresponding to more than ten thousand affected passengers may be assigned an impact magnitude of “high”, while an event with time and/or location properties corresponding to fewer than one thousand affected passengers may be assigned an impact magnitude of “low”. As will be apparent, a wide variety of other scoring mechanisms and thresholds may also be employed. The impact magnitude generated at block 320 can be stored in the corresponding event detection record 408.
As will be apparent, the diversity of event data sources 122 queried at block 305 can result in multiple event detection records 408 being generated that correspond to the same real-world event. In some examples, at block 320 the server 124 can therefore also aggregate event detection records, e.g., prior to determining the impact magnitude. The impact magnitude can then be determined for the aggregated event detection record, rather than the original event detection records 408.
Turning to
The aggregated record 500 also includes the keywords from the record 408-2 (which are lacking from the record 408-1). In addition, the aggregated record can include an aggregated reliability, e.g., a sum of the reliability of the sources 122-1 and 122-2. That is, the fact that matching events have been reported by more than one event data source 122 increases the reliability of the reports, relative to the reliability of either source 122 in isolation. Various other mechanisms for generating an aggregated reliability value can also be employed. As seen from
Also shown in
Referring again to
The threshold(s) applied at block 325 can be specific to each supplier subsystem 108. For example, the repository 228 can contain notification thresholds for each supplier subsystem 108, such that the determination at block 325 for a given event detection record may be negative for one supplier subsystem 108, and affirmative for another supplier subsystem 108. The determination at block 325 may be repeated for each of a plurality of supplier subsystems 108, e.g., those affected by the relevant event (e.g., as determined at block 315).
When the determination at block 325 is negative, the event detection record can be ignored and/or discarded, and performance of the method 300 can end (for that particular event detection record). In other words, low-impact events, or events from low-reliability sources (that are not corroborated by additional sources) may be ignored, reducing the volume of notifications generated and transmitted by the server 124, as discussed below. When the determination at block 325 is affirmative, however, the server 124 proceeds to block 330.
At block 330, the server 124 is configured to select one or more supplier subsystems 108 according to the magnitude and direction of the event detection record, and optionally according to the profile data in the repository 228. The selection at block 330 is a selection of supplier subsystems 108 for the generation and transmission of notifications, to either or both of the supplier subsystems 108 themselves, or other computing devices associated with the supplier subsystems 108 (e.g., client subsystems 116 corresponding to ticket-holders for flights operated by a selected supplier subsystem 108). For example, the repository 228 can contain, for each supplier subsystem 108, types or categories of events (e.g., identified by keywords or the like) for which notifications are to be generated. Certain suppliers, in other words, can elect to receive notifications for only certain types of events, while ignoring other types of events.
At block 335, the server 124 is configured to transmit a notification to at least one computing device associated with the supplier(s) selected at block 330. The notification includes the event detection record, or data retrieved from the event detection record. The notification can also include, in some examples, an operational resource adjustment generated by the server 124 based on data in the repository 228. For example, the repository 228 can include rules for selecting operational adjustments according to various attributes of the event detection record. In some examples, a supplier subsystem 108 may configure profile data in the repository 228 to select operational adjustments including the suspension of new bookings and the rescheduling or cancellation of existing bookings during the time period of a high-impact disruptive event. A wide variety of other operational adjustments can also be stored in the repository 228, for a wide variety of other event attribute sets.
In other examples, the server 124 can be configured to automatically apply the suggested adjustments, e.g., based on thresholds, event keywords or the like defined in the repository 228. In such examples, the notification 600 can include an indication that the adjustments have been applied.
Referring again to
The feedback data can also indicate, for example, that data from the event detection record extracted at block 310 was inaccurate. For example, the feedback data can indicate that the location in the event detection record was inaccurate (i.e., did not match the actual location associated with the event). The server 124 can, in response to such feedback data, decrease the reliability score associated with the source(s) 122 that contributed to the event detection record. Conversely, feedback data indicating that an event detection was accurate can result in increased reliability scores for the originating sources 122.
In the description above, relational terms such as “first” and “second,” as well as reference numerals with suffixes such as “−1,” “−2” are used to distinguish one entity or action from another entity or action. Such terminology, absent an express indication to the contrary, does not necessarily indicate an actual order or other hierarchical relationship between the entities or actions. Terms such as “comprises,” “comprising,” “has”, “having,” “includes”, “including,” “contains”, “containing” and the like are intended to be open-ended, such that a process, apparatus or the like that comprises, has, includes, contains a list of elements does not necessarily include only those elements, but may also include other elements that are not expressly listed. The terms “a” and “an” are intended to indicate one or more, unless explicitly stated otherwise. Certain expressions may be employed herein to list combinations of elements. Examples of such expressions include: “at least one of A, B, and C”; “one or more of A, B, and C”; “at least one of A, B, or C”; “one or more of A, B, or C”. Unless expressly indicated otherwise, the above expressions encompass any combination of A and/or B and/or C.
The scope of the claims should not be limited by the embodiments set forth in the above examples, but should be given the broadest interpretation consistent with the description as a whole.
